Linux Switch: Encoding Audio

Putting out a podcast in multiple formats can sometimes be a bit of a drag. Under OS X, I would send a finished episode to iTunes twice, once each for MP3 and AAC, and send it an additional time to disk as raw audio. For the two iTunes encoded formats, I had to manually add in the genre field since GarageBand doesn’t include anything of the sort in its limited metadata. For the MP3 format, iTunes also didn’t bring over the cover art from GarageBand. Rather than set it when I filled in the missing genre field, I used an ID3 tagging application, called unimaginatively enough ID3 Editor, to add the missing cover art and to populate the copyright field which iTunes doesn’t expose.

For the two open formats I produce, I used the flac and vorbis-tools packages from MacPorts. For the metadata in the Ogg Vorbis file, I cobbled together an AppleScript that copied metadata from one of the files in my iTunes library and pushed it through calls out to the vorbis-tools comment utility.

This hodge podge of tools isn’t very elegant but it got the job done. Bear in mind that I added each of the four formats I produce at different times. There was never any one time I sat down and thought about how I might take a single, raw audio input and mechanize turning that into four formats with as complete metadata as possible.

There wasn’t, any way, until now. Under the auspices of moving my podcast production completely to Linux, I had to re-build my encoding work flow entirely from scratch. Further, I had to find replacements for all the just-so tooling I had accumulated in cruft-wise fashion under OS X.

For flac, I still use the flac package but dug into the documentation much further. I realized that flac supports metadata just as well as any other format, including cover art. Once I cut over on the 3rd, anyone enjoying the full quality audio in flac will see that all of the usual fields are now populated.

In reading up on the vorbis-tools in that same spirit of improving what I had been doing previously, I realized encoding from flac would automatically copy most of the metadata data from the source flac file. It doesn’t save me any time, it actually takes a bit longer to encode from flac, probably because it has to decode back to raw in memory before running the lossy encoding for Ogg Vorbis. It does make my script tidier and all but guarantees that the flac and Ogg Vorbis metadata will be entirely consistent.

The cover art is the only field that oggenc doesn’t copy over from flac, probably because the conventions for attaching pictures to Ogg Vorbis files recently changed. The folks at Xiph have standardized on a base 64 encoded version of how flac packs in images. Using metaflac, it is trivial to read out the binary block from the flac file, base 64 encode it, and set it as an appropriately named comment on the Ogg Vorbis file. Only newer players will support this means of adding images but the Xiph documentation was clear this is now the standard.

The AAC format has proved especially challenging to figure out under Linux. Early on a listener thankfully recommended faac, which is available in the Ubuntu repositories. faac is pretty comparable in the options it takes to lame, the most popular MP3 encoder under Linux. It take a little trial and error to get the quality, bandwidth and bit rate arguments set right (100, 44100, and 96 respectively) to get the resulting file to match the quality/compression result iTunes produces. faac can add all the metadata that used to flow from GarageBand to iTunes, everything except the chapter marks.

I had resigned myself to just dropping the chapter marks, arguably the most valuable aspect of offering an AAC version of the show. As I mentioned in my update to the changes that will go live on the 3rd, my friend Jay clued me in to a set of tools, mp4v2, for working with AAC files. That includes a little utility called mp4chaps. The documentation is non-existent and the text file it takes has a hard coded name and a just-so format. In the end it was pretty easy to figure that all out with Jay’s help and add appropriate logic to the new shell script I’ve put together to drive encoding.

Lastly MP3 presented some surprising challenges. There are a couple of choices for ID3, namely v1 and v2 (technically three as there are two common versions of v2), so it took some examination to figure out which version iTunes was and was not setting. The Linux version of lame has no way to set the cover art of the resulting file. There is some version, somewhere, that has a flag for it (–ti), but not the version that comes with Ubuntu. None of the ID3 utilities I initially found in the Ubuntu repositories could set cover art either. Finally I found eyeD3, arguably the most capable dedicated ID3 tagger. It not only let me set the cover art but with the Wikipedia entry for ID3 in hand, I figured out how to set the copyright field from the command line, something none of the other tools even hinted was possible.

The end result is a shell script that tops out at just over one hundred lines, including comments, that runs out all four formats I am already producing from a single WAV file input. The audio quality should be the same and the metadata on each encoded file an improvement over my old tools. Better yet, there are no manual steps whatsoever. Under OS X there were about a half dozen things I needed to do, from start to finish, at various points across all four files. Now it is a single command line invocation then on to my upload step.

This shell script lives in the same git repo where I developed my feed management script. If anyone is interested in seeing either script, let me know and I’ll clone the project to github and post a separate announcement when that is available. Like the feed script, it has hard coded values for my own use but it would be trivial to fork and customize as needed for your own purposes.

4 Replies to “Linux Switch: Encoding Audio”

    1. I went ahead and cloned my repo to github. http://github.com/commandline/autocast I went through all my scripts to make sure they had explanatory comments. As I said, for now it should be easy enough to fork and customize. I could, however, easily imagine pulling the hard coded material into separate, non-version controlled files that other folks could edit to suit without having to tweak the scripts themselves.

      I’ll publish a full post later today for anyone else interested in this repo.

  1. I’d also be interested in seeing your scripts. I have a pile of them myself I’ve been thinking about doing the same. If you think the eyeD3 command line tool is powerful, you can do even more with the API directly.

Leave a Reply

Your email address will not be published. Required fields are marked *