Difference between revisions of "Convert Flac to Mp3"

From ArchWiki
Jump to: navigation, search
m (Usage: clarity)
(47 intermediate revisions by 17 users not shown)
Line 1: Line 1:
[[Category:Development (English)]]
+
[[Category:Audio/Video]]
[[Category: HOWTOs (English)]]
+
[[Category:Scripts]]
[[Category:Package management (English)]]
+
{{Article summary start}}
{{i18n_links_start}}
+
{{Article summary text|Converting audio formats}}
{{i18n_entry|English|The_Arch_package_making_HOW-TO_-_with_guidelines}}
+
{{Article summary heading|Related}}
{{i18n_entry|Русский|The_Arch_package_making_HOW-TO_-_with_guidelines(russian)}}
+
{{Article summary wiki|Convert Any To Mp3}}
{{i18n_entry|简体中文|The_Arch_package_making_HOW-TO_-_with_guidelines(Chinese)}}
+
{{Article summary wiki|Convert any Movie to DVD Video}}
{{i18n_links_end}}
+
{{Article summary end}}
  
这个文档 [[ABS_-_The_Arch_Build_System | ABS - The Arch Build System]] 提供了一份良好的用于制作和修改 Arch Linux 软件包所需工具和文件的总览。如果你只想要定制或重新编译一个已经存在的软件包,这里应该已经提供了足够的信息。但是,如果你想要制作一个新的软件包,你还需要一些额外的指南。这个文档假定你已经事先阅读并掌握了 ABS 的描述。
+
Here are a few scripts and tools that facilitate converting FLAC to MP3.
 +
 +
==Introduction==
 +
For more information on LAME switches/settings such as V0, visit the [http://wiki.hydrogenaudio.org/index.php?title=LAME Hydrogenaudio LAME Wiki]. V0 is roughly equivalent to ''--preset extreme'' which results in a variable bitrate usually between 220-260. The audio of a V0 is transparent, meaning one cannot tell the difference between the lossy file and the original source (compact disc/lossless), but yet the file size is a quite reasonable.
  
==准备文件==
+
More information on FLAC: [http://wiki.hydrogenaudio.org/index.php?title=Flac FLAC]
所有用于制作一个软件包所需的信息放在 <code>PKGBUILD</code>  文件中。当你运行 <code>makepkg</code> 命令,它将在当前工作目录中寻找 <code>PKGBUILD</code> 文件,然后根据 <code>PKGBUILD</code> 文件中的指令编译软件的源代码。当编译成功后,得到的二进制代码,包括诸如包版本和依赖等meta-信息将封装在名叫 <code>name.pkg.tar.gz</code> 的软件包中,你可以使用 <code>pacman -Up <package file></code> 命令将其安装。
+
  
<code>PKGBUILD</code> 文件包含 '''所有''' 用于制作一个软件包所需的指令,这些指令以能够被 bash 识别的的格式存在(don't worry if that little tidbit of clue doesn't help you)。[[ABS_-_The_Arch_Build_System | ABS]] 条目中描述了这里使用的变量,但是最重要的也是最让人迷惑的变量在这里recapped。为了开始制作一个新的包,你应该首先创建一个空的目录,最好取名为 <code>/var/abs/local/<PKGNAME></code>。这样的话,它可以很好的统一到统一的 ABS 树,但如果你没有同步该树的话,cvsup 不会接触(touch)它。进入你新建的目录,创建 <code>PKGBUILD</code> 文件,你可以直接从 <code>/var/abs/PKGBUILD.proto</code> 复制虚构的原型,也可以复制其他软件包的 <code>PKGBUILD</code> 。如果你不需创建一个全新的文件,而只需修改其中的编译选项的话,后者是非常合适的选择。
+
==Scripts==
  
无论你用那种方式,总之你需要一个 <code>PKGBUILD</code> 文件。
+
In these two examples, the FLAC files in a directory are read, decompressed to WAV, and streamed into the MP3 encoder, LAME. Both scripts pass the ID3 tags from the FLAC files to the resulting MP3 files, and encode to MP3 V0.
  
==编辑变量==
+
The original .flac files are not modified and the resulting .mp3s will be in the same directory. All files with extensions not matching {{Ic|*.flac}} in the working directory (.nfo, images, .sfv, etc.) are ignored.
  
现在打开它,根据你构建的包的情况设置各个变量的值:
+
===With FFmpeg===
<br /><br />
+
*'''pkgname:''' 将这个变量设置为你的包的名字。按照惯例,你应该使用小写字母。最好包的名字与你所在的工作目录的名字相同,当然也与你将要下载的包含源程序的 tar.gz 文件名相同,但这并不是必须的。
+
  
*'''pkgver:''' 设置包的版本。它可以包含字母、数字和点,但不能有连字符。它由你打包的程序使用的版本系统决定(主版本.次版本.漏洞修复版本、major.日期等)。另外,在大多数情况下,你可以遵循源代码包的文件名的一部分的版本,以便后续步骤变得更为简单和灵活。还要注意:如果包的作者在其版本编号方案中使用了短横,请用下划线替代它。('0.99-10'  =>  '0.99_10')
+
Chances are, your system already has {{Ic|ffmpeg}} installed, which brings in the {{Ic|flac}} and {{Ic|lame}} packages. FFmpeg has all the encoding and decoding facilities built in to do the job.
  
*'''pkgrel:''' This should be incremented each time you release a package, starting with 1. Its purpose is to differentiate consecutive builds of the same version of a package. Occasionally the first release of a package contains a problem or misfeature. When you make the second release, you increment the <code>pkgrel</code> variable so that pacman knows it needs to be reinstalled. When a new '''version''' of the package is released, you reset the <code>pkgrel</code> variable to 1.
+
<pre>
 +
#!/bin/bash
  
*'''pkgdesc:''' This should contain a short, usually less than 76 characters, description of the package. Usually it is not needed repeating the program name. <code>OpenGL accelerated X server</code> is better than <code>xgl is a OpenGL...</code>.
+
for f in *.flac; do
 +
  ffmpeg -i "$f" -qscale:a 0 "${f[@]/%flac/mp3}"
 +
done
 +
</pre>
  
*'''arch:''' This should contain an array of architectures, usually 'i686', that describes where the PKGBUILD file can be used. You can access this value with the variable <code>$arch</code> during the build.
+
===Without FFmpeg===
  
*'''url:''' This should contain the address of the official site of the program where who is interested can find more informations.
+
If for some reason you have something against ffmpeg, you still need to have {{Ic|flac}} and {{Ic|lame}} installed. Here, the tagging process is more explicit, using the metadata utility that comes with {{Ic|flac}}, and passing the information to {{Ic|lame}}
  
*'''license:''' The type of license, if you do not know it please write down 'unknow.'
+
<pre>
 +
#!/bin/bash
  
*'''depends:''' This should contain an array of package names that need to be installed before this program can be run, separated by spaces. The names can optionally be enclosed in single quotes (apostrophes) to prevent possible shell quoting problems, and the array should be enclosed in round brackets. Sometimes a program requires a minimum version of a dependency; In that case, you might want to use the mathematical "larger or equal than" operator, and enclose the whole construct in quotes. Here's an example to add a dependency on the glibc package, and the slang library of at least version 1.8.0: '''<code>depends('glibc' 'slang>=1.8.0')</code>'''
+
for a in *.flac; do
 +
  # give output correct extension
 +
  OUTF="${a[@]/%flac/mp3}"
  
*'''makedepends:''' This should contain an array of package names that are needed only during the build, but that are unneeded for *using* the package after install. Example: <code>unarj</code> used in a build to unpack some patches.
+
  # get the tags
 +
  ARTIST=$(metaflac "$a" --show-tag=ARTIST | sed s/.*=//g)
 +
  TITLE=$(metaflac "$a" --show-tag=TITLE | sed s/.*=//g)
 +
  ALBUM=$(metaflac "$a" --show-tag=ALBUM | sed s/.*=//g)
 +
  GENRE=$(metaflac "$a" --show-tag=GENRE | sed s/.*=//g)
 +
  TRACKNUMBER=$(metaflac "$a" --show-tag=TRACKNUMBER | sed s/.*=//g)
 +
  DATE=$(metaflac "$a" --show-tag=DATE | sed s/.*=//g)
  
*'''provides:''' This should contain an array of package names that become unneeded with described one since it gives at least the same features.
+
  # stream flac into the lame encoder
 +
  flac -c -d "$a" | lame -V0 --add-id3v2 --pad-id3v2 --ignore-tag-errors \
 +
    --ta "$ARTIST" --tt "$TITLE" --tl "$ALBUM"  --tg "${GENRE:-12}" \
 +
    --tn "${TRACKNUMBER:-0}" --ty "$DATE" - "$OUTF"
 +
done
 +
</pre>
  
*'''conflicts:''' This should be an array of package names that if installed with the described one will give problems.
+
===Usage===
  
*'''replaces:''' This should be an array of obsolete package names that are replaced by the described one.
+
For ease of use, add the script to your {{Ic|PATH}}. Open up a terminal, {{Ic|cd}} to the directory of FLAC files that you wish to convert, and invoke {{Ic|flac2mp3}} (or whatever you named the script). You'll see the verbose decoding/encoding process in the terminal which may take a few moments. Done!!! At this point, it's trivial to {{Ic|mv *.mp3}} all your new MP3s wherever you wish.
  
*'''source:''' This must be an array of files which are needed to build the package, containing at least the location of the program source, which is in most cases a full HTTP or FTP URL enclosed in double quotes. The prototype <code>PKGBUILD</code> shows how you can use the previously set variables for package name and version effectively here. If you find you need to supply files which are not downloadable on the fly, for example self-made patches, you simply put those into the same directory where your <code>PKGBUILD</code> is in, and add the filename to this source array. Any  paths you add here are resolved relative to the directory where the <code>PKGBUILD</code> lies. Before the actual build process is started, all of the files referenced here will be downloaded or checked for existence, and <code>makepkg</code> will not proceed if any are missing.
+
A useful extension of the above scripts is to let it recurse into all subdirectories of the working directory. Replace the first line ({{Ic|for .... do}}) with
  
*'''md5sums:''' An array of md5 checksums for the source files, space seperated and enclosed in quotes. Once all files in the source array are available, an md5 hash of each file will be automatically generated and compared with the values of this array, '''in the same order they appear in the source array'''. Whilst the order of the source files itself does not matter, it's important that it's coherent with the order of the md5sums, as <code>makepkg</code> won't guess which md5sum belongs to what source file, and will happily start spewing errors if they don't match to prevent download errors or manipulations. You can generate the md5sums array quickly and easily using the command <code>makepkg -g</code> (after the source array has been properly set up) in the directory that contains the <code>PKGBUILD</code>. <code>makepkg -g >>PKGBUILD</code> will generate the sums and append them to the end of the <code>PKGBUILD</code>, from whence you can move the line(s) into the proper position of the file.
+
<pre>
 +
find -type f -name "*.flac" -print0 | while read -d $'\0' a; do
 +
</pre>
  
So far you've only been setting up meta-information about the package; Where to get the sources, what the name of the package shall be, etc. The next step is supplying instructions on how to actually ''compile and install'' the program you're intending to pack up.
+
==Packages==
  
==Using the source==
+
* {{AUR|whatmp3}} A small Python script that accepts a list of directories containing FLAC files as arguments and converts them to MP3 with the specified options.
Now you should download the source tarball, extract it, and note all commands needed to compile and install it. The contents of the <code>build()</code> function in your <code>PKGBUILD</code> will do nothing but run exactly these steps again, with a little glue to pack everything up once compilation is done.
+
* {{AUR|flac2all}} Audio converter of FLAC to either Ogg Vorbis or MP3 retaining all tags and metadata
 +
* {{AUR|flac2mp3-bash}} Bash script to convert Flac to Mp3 easily
  
Now you probably need to edit the contents of the build() function in the <code>PKGBUILD</code>.  This function uses common shell commands in the bash syntax.  The basic purpose of this function is to automatically compile the programs and create a <code>pkg</code> directory to install the program to, allowing <code>makepkg</code> to pack it all up easily without having to pick all interesting files from your "live" filesystem.
+
==Related Links==
===The build() function===
+
* https://www.xiph.org/flac/
Usually the first step in the build function is to change into one of the directories created by uncompressing the source files.  You can use the <code>$startdir</code> variable to do this (it refers to the directory that contains the <code>PKGBUILD</code>). You may also use the $pkgname and $pkgver variables that you set earlier. For example, depending on the name of the directory that was uncompressed by makepkg, the first command in your build function might be <code>cd $startdir/src/$pkgname-$pkgver</code>, which happens to be a very common case unless the program's author is a very, very evil person.
+
* https://en.wikipedia.org/wiki/FLAC
 
+
* http://lame.sourceforge.net/
Compiling the programs is the more difficult part. I will assume you managed to compile the program successfully "by hand" here, as all imaginable steps to do this cannot possibly be covered here. That's what the program's author is supposed to write README and INSTALL files for after all.
+
 
+
Now that you are in that directory, you need to issue whatever commands it takes to compile the files. In simple cases, you may simply use <code>./configure; make</code>, although there are dozens of variations including <code>ant build</code> or issuing the actual <code>gcc</code> commands to compile the packages.
+
 
+
Good thing is, if you already managed to compile the package manually, you basically only need to list the commands you used here, and things should work out just fine. Since many packages like to install their files relative to the <code>/usr/local</code> directory, but Arch Linux prefers using just <code>/usr</code>, you probably want to supply a parameter to the configure script or the make command to take care of this. The prototype <code>PKGBUILD</code> serves as an example for that. It might work differently, though; Again, your mileage may vary.
+
 
+
The next step in the <code>build()</code> function is to put the compiled files in a place where <code>makepkg</code> can scoop them up to create a package. This directory is the <code>pkg</code> directory. It is supposed to imitate the root of your filesystem to the program's installation procedure. Any files that should be installed in a directory in the root of your filesystem should go in the <code>pkg</code> directory under the same directory structure (ie. if you want to install the file <code>myprog</code> in <code>/usr/bin</code>, it should be placed in <code>$startdir/pkg/usr/bin</code>). Fortunately, only a few programs require the user to copy dozens of files manually, but they supply some kind of installation procedure instead which is supposed to do that automatically, often invoked by running "make install". It's '''critical''', however, that you find out how to tell this installation procedure that it's supposed to stuff all it's nifty files '''not''' into your /, but into <code>$startdir/pkg/</code> instead! Otherwise you'll end up with an empty package file, and the binaries of the program you installed "correctly" added to your system already. Most of the time you'll have to supply the prefix parameter to the "make install" call as shown in the prototype, but it's very well possible that the program you're packaging expects an altogether different approach, but here are some hints:
+
 
+
* Sometimes the <code>configure</code> script accepts a prefix property that tells where the files should be installed. You might use <code>./configure --prefix=$startdir/pkg/usr</code> in such configuration, for example.
+
 
+
* Sometimes there is a <code>PREFIX</code> option to append to a <code>make install</code> command. This is sometimes set as a variable, and sometimes set in the command. In worse cases you have to edit the Makefile(s) (or ant build/properties files if the project uses ant) with sed or a patch you'd have to create yourself.
+
 
+
* There might be other sorts of install scripts that allow you to specify where the program should be installed.
+
 
+
* In some cases, the program expects to be run from a single directory.  Often it is wise to simply copy these to <code>$startdir/pkg/opt</code>.
+
 
+
As you might have guessed already, that's the part where actual knowledge and experience becomes a necessity. It helps a lot if you browse over the <code>PKGBUILD</code> files in the ABS tree, as those are tested and contain a few tricks that might prove valuable.
+
 
+
More often that not, the installation routine of the program will take care to create any subdirectories below the <code>pkg/</code> directory. If it does not, however, you'll get a lot of errors during the install stage as files are copied to nonexistent subdirectories. In that case you'll have to create the needed subdirectories by adding the appropriate <code>mkdir</code> commands in the <code>build()</code> function before running the installation procedure. The actual directory structure is package dependent, of course; some programs need to place files in <code>/etc</code> or <code>/usr</code> while others might need to use <code>/bin</code> or <code>/opt</code>.  Most will need to create several directories.  You can do all of this with the <code>mkdir -p $startdir/pkg/OTHER/DIRS/AS/NEEDED</code> command, where OTHER/DIRS/AS/NEEDED represent directories at the root of the filesystem.
+
 
+
==Testing the PKGBUILD==
+
 
+
As you are writing the <code>PKGBUILD</code>'s <code>build()</code> function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the <code>makepkg</code> command in the directory containing the <code>PKGBUILD</code>. With a properly formatted <code>PKGBUILD</code>, this will create a package, but with a broken or unfinished one it will throw an error. Hopefully it will be a descriptive error!
+
 
+
If running <code>makepkg</code> finished successfully, it will place a shiny new file called $pkgname-$pkgver.pkg.tar.gz in your working directory. This is a pacman package and can be installed with the <code>pacman -U</code> and <code>pacman -A</code> options, or added to a local or web based repository.  Note that just because a package file was built it doesn't mean it works!  It might conceivably contain only the directory structure and no files whatsoever if, for example, you specified a prefix improperly. You can use pacman's query functions to display a list of files contained in the package and the dependencies it requires, and compare those with what you consider as correct. "pacman -Qlp <package file>" and "pacman -Qip <package file>" do the trick.
+
 
+
If the package looks sane, that's all you need to do. However, if you plan on releasing the package or PKGBUILD, it is imperative that you check and double check and re-double-check the contents of the depends array. This should contain a list of all packages that need to be installed in order for your package to work. You only need to list first level depends in the depends array. That is, you do not need to list packages that your program depends on if other packages that your program depends on are already listed.
+
 
+
For example, <code>gtk2</code> depends on <code>glib2</code>. Like most open source C programs, it also requires <code>glibc</code> to be installed. However, <code>glibc</code> does not need to be listed as a dependency for <code>gtk2</code> because it is a dependency for <code>glib2</code>, and <code>glib2</code> is already listed in <code>gtk2</code>.
+
 
+
There are some tools you can use to check dependencies, including Jason Chu's famous <code>namcap</code> program (<code>pacman -Sy namcap</code>), and the more arcane <code>ldd</code> program.  Check the man pages for these programs and the links at the end of this document for more information.  You should also scour the program's documentation and website (some nice developers have a page called "dependencies" that helps a lot).
+
==Testing the package==
+
Also make sure that the package binaries actually ''run'' flawlessly! It's really annoying to release a package that contains all necessary files, but dumps core because of some obscure configuration option that doesn't quite work well with the rest of the system. If you're only going to compile packages for your own system, though, you don't need to worry too much about this quality assurance step, as you're the only person suffering from mistakes after all.
+
 
+
==To sum it all up==
+
* Download the source tarball of the program you want to package up
+
* Try compiling the package and installing it into an arbitrary directory
+
* Copy over the prototype <code>/var/abs/PKGBUILD.proto</code> and rename it to <code>PKGBUILD</code> in a temporary working directory
+
* Edit the PKGBUILD according to the needs of your package
+
* Run <code>makepkg</code> and see whether the resulting package is built correctly
+
* If not, repeat the last two steps
+
 
+
==Useful links==
+
* [[ABS_-_The_Arch_Build_System | ABS - The Arch Build System]]
+
* [http://www.archlinux.org/pacman/makepkg.8.html makepkg man page]
+
* [http://bbs.archlinux.org/viewtopic.php?t=4 about dependencies]
+
* [http://bbs.archlinux.org/viewtopic.php?t=1590 makepkg tutorial]
+
* [[PKGBUILD help|PKGBUILD Help]]
+
* [[Arch CVS & SVN PKGBUILD guidelines]]
+
 
+
==Warnings==
+
* Before you can automate the package building process, you should have done it manually at least once unless you know ''exactly'' what you're doing ''in advance'', in which case you would not be reading this in the first place. Unfortunately, although a good bunch of program authors stick to the 3-step build cycle of "./configure; make; make install", this is not always the case, and things can get real ugly if you have to apply patches to make everything work at all. Rule of thumb: If you can't get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you don't even need to try packaging it. There isn't any magic pixie dust in <code>makepkg</code> that makes source problems go away.
+
* In a few cases, the packages are not even available as source and you have to use something like <code>sh installer.run</code> to get it to work. You will have to do quite a bit of research (read READMEs, INSTALL instructions, man pages, perhaps ebuilds from gentoo or other package installers, possibly even the MAKEFILEs or source code) to get it working. In some really bad cases, you have to edit the source files to get it to work at all. However, <code>makepkg</code> needs to be completely autonomous, with no user input. Therefore if you need to edit the Makefiles, you may have to bundle a custom patch with the <code>PKGBUILD</code> and install it from inside the <code>build()</code> function, or you might have to issue some <code>sed</code> commands from inside the <code>build()</code> function.
+
* Note that just because a package file was built it doesn't mean it works!  It might conceivably contain only the directory structure and no files whatsoever if, for example, you specified a prefix improperly. You can use pacman's query functions to display a list of files contained in the package and the dependencies it requires, and compare those with what you consider as correct. "pacman -Qlp <package file>" and "pacman -Qip <package file>" do the trick.
+

Revision as of 21:29, 8 July 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary end

Here are a few scripts and tools that facilitate converting FLAC to MP3.

Introduction

For more information on LAME switches/settings such as V0, visit the Hydrogenaudio LAME Wiki. V0 is roughly equivalent to --preset extreme which results in a variable bitrate usually between 220-260. The audio of a V0 is transparent, meaning one cannot tell the difference between the lossy file and the original source (compact disc/lossless), but yet the file size is a quite reasonable.

More information on FLAC: FLAC

Scripts

In these two examples, the FLAC files in a directory are read, decompressed to WAV, and streamed into the MP3 encoder, LAME. Both scripts pass the ID3 tags from the FLAC files to the resulting MP3 files, and encode to MP3 V0.

The original .flac files are not modified and the resulting .mp3s will be in the same directory. All files with extensions not matching *.flac in the working directory (.nfo, images, .sfv, etc.) are ignored.

With FFmpeg

Chances are, your system already has ffmpeg installed, which brings in the flac and lame packages. FFmpeg has all the encoding and decoding facilities built in to do the job.

#!/bin/bash

for f in *.flac; do
  ffmpeg -i "$f" -qscale:a 0 "${f[@]/%flac/mp3}"
done

Without FFmpeg

If for some reason you have something against ffmpeg, you still need to have flac and lame installed. Here, the tagging process is more explicit, using the metadata utility that comes with flac, and passing the information to lame

#!/bin/bash

for a in *.flac; do
  # give output correct extension
  OUTF="${a[@]/%flac/mp3}"

  # get the tags
  ARTIST=$(metaflac "$a" --show-tag=ARTIST | sed s/.*=//g)
  TITLE=$(metaflac "$a" --show-tag=TITLE | sed s/.*=//g)
  ALBUM=$(metaflac "$a" --show-tag=ALBUM | sed s/.*=//g)
  GENRE=$(metaflac "$a" --show-tag=GENRE | sed s/.*=//g)
  TRACKNUMBER=$(metaflac "$a" --show-tag=TRACKNUMBER | sed s/.*=//g)
  DATE=$(metaflac "$a" --show-tag=DATE | sed s/.*=//g)

  # stream flac into the lame encoder
  flac -c -d "$a" | lame -V0 --add-id3v2 --pad-id3v2 --ignore-tag-errors \
    --ta "$ARTIST" --tt "$TITLE" --tl "$ALBUM"  --tg "${GENRE:-12}" \
    --tn "${TRACKNUMBER:-0}" --ty "$DATE" - "$OUTF"
done

Usage

For ease of use, add the script to your PATH. Open up a terminal, cd to the directory of FLAC files that you wish to convert, and invoke flac2mp3 (or whatever you named the script). You'll see the verbose decoding/encoding process in the terminal which may take a few moments. Done!!! At this point, it's trivial to mv *.mp3 all your new MP3s wherever you wish.

A useful extension of the above scripts is to let it recurse into all subdirectories of the working directory. Replace the first line (for .... do) with

find -type f -name "*.flac" -print0 | while read -d $'\0' a; do

Packages

  • whatmp3AUR A small Python script that accepts a list of directories containing FLAC files as arguments and converts them to MP3 with the specified options.
  • flac2allAUR Audio converter of FLAC to either Ogg Vorbis or MP3 retaining all tags and metadata
  • flac2mp3-bashAUR Bash script to convert Flac to Mp3 easily

Related Links