Attack of the Pod Penguins 7: Encoding with lame

In the opening piece of the “Attack of the Pod Penguins” series, I mentioned my friend Justin, the carpenter. In his line of work as a builder, he carries a tool belt containing everything he’ll need to complete a job – hammer, nails, speed square, tape measure, pencil and a load of other assorted hand tools. The podcasting tool belt isn’t so different from that worn and shiny fold of leather slapping against Justin’s hip. The point is to provide every tool you’ll need to complete the podcasting job.

Throughout this series, we’ve started to fill that belt, both with actual tools and with knowledge that will allow you to use those tools in a powerful and effective way. We spent a few installments looking at the inner workings of Audacity, the 16-oz framing hammer of open source podcasting. It allows you to capture and edit the source audio files for your podcast – like driving nails into the initial structure of a 2×6 pine board. We’ve examined the inner workings of normalize, a planer, if you will, for fitting all the discrete pieces of that podcast perfectly together edge to edge. We’ve also been to podcasting carpentry school, filling in the important details of how air pressure works on the human ear. We’ve discussed the carpenter’s level of the psychoacoustic model, the theoretical tool that allows you to reduce file sizes while maintaining maximum perceptual sound quality. In short, you now have some tools and background knowledge that will allow you to produce a podcast with open source tools that, from a sound quality perspective, nearly all listeners will find enjoyable. In other words, you have many of the tools you’ll need to make the focus of your podcast the content, rather than the sound quality.

In this installment of “Attack of the Pod Penguins,” we’re working toward hanging the sheet rock on the walls of the podcast we’ve built in the previous installments. Framing in a house is nice, if not exactly beautiful. It needs some additional work to allow you hang pictures in the living room. You need a medium for those nails or picture hangers, and a foundation into which to sink them. Painting the walls is also essential, but you’ll need the sheet rock in a finished form prior to applying the colors. That’s where we’re heading in this installment of this series.

As we discussed in the previous installment, the only widely accepted format for delivering your finished audio files is the mp3 format. Though it might not fit nicely into the licensing view of open source advocates, it’s become the standard for podcast delivery. All major audio players in Linux support the mp3 format. By the terms of the mp3 license itself, a demand for royalties appears to be limited only to those business entities generating more than $100,000 from use of the codecs. The royalties have, by quiet agreement, been unenforced as they apply to open source-based software players. And, if you’re using an audio hardware device that supports the mp3 format, as most do, the manufacturers have passed along their own licensing costs in the cost of the player.

Importantly, mp3 usage in Linux has taken an interesting turn in the month since the last installment of this series. Fluendo has announced a decoder licensing deal for both Windows and Linux-based software mp3 players. In the Linux world, Fluendo plans to work closely with GStreamer, offering licensed plugins for such players as Totem, Rhythmbox and the Banshee player. Though the announcement doesn’t explicitly address encoders, it does move Linux another step closer to a full and official mp3 implementation.

With those concerns behind us, let’s take a detailed look at lame, the great and powerful command-line tool to convert your podcast to a Web- and user-friendly mp3 format.

Lame began life with a name that complied perfectly with the wry Unix recursive acronym naming tradition. Originally, lame stood for “Lame Ain’t an MP3 Encoder,” though it was clearly exactly that. The changelog for lame stretches back to Setpember 1998, when all the previous changes were incorporated into a single log entry. It’s a bit difficult to know for sure when the lame project started for that reason, as all changes and releases prior to 1998 are contained in a single changelog entry with the heading “Up to September 1998.”

In any event, lame development continued at a brisk pace, with version 3.59 beta released 16 months later, in January 2000. By May 2000, the original ISO source code had been completely replaced, and lame was recognized both by the public and its developers as ” … the source code for a fully LGPL’d MP3 encoder, with speed and quality to rival and often surpass all commercial competitors.” According to the lame web site, lame today is ” … an educational tool to be used for learning about MP3 encoding. The goal of the LAME project is to use the open source model to improve the psycho acoustics, noise shaping and speed of MP3.” It’s interesting, in at least a passing way, that one of the core goals of the lame project involves the improvement of the psycho-acoustics, the topic of much of our last installment. The application and refinement of those principles is central to the purpose of lame.

Let’s start this exploration of lame at the high level. You’ll need to make several decisions when using lame, all centered around these high-level functions.

For now, let’s put aside the question of the specific bitrate and sampling rate at which you’ll encode your file, though both are easily managed by lame. A higher-level decision is whether to use Constant Bit Rate (CBR) versus a Variable Bit Rate (VBR) for your file. At this point, the details of the rates themselves are less important than an understanding of the differences between these high level options.

In podcasts that are primarily voice driven – news, opinion and information podcasts, for example – the amount of audio data in each frame will not likely vary much from frame to frame. The human voice is a very limited instrument with a very narrow range of frequencies. While the spectrum is larger when considering both female and male, young and old voices, the range is still quite narrow compared with the data contained in music or other more natural sounds. That fact alone will tell you that for voice podcasts, you’re in comfortable territory to choose a CBR option when encoding in lame. CBR, by the way, is the default setting for lame. To use the VBR options, you’ll need to explicitly require them in your command-line options.

For music podcasts, or others with broad dynamic and frequency ranges, you should consider using the VBR options in lame. This process, again, contains a direct reference to the psycho-acoustic model that is so integral to the core purposes of lame. When using the VBR options in lame, each frame is checked for the amount and quality of the associated audio data, with adjustments to the bitrate made to balance the fine distinction between file size and perceived quality. In those frames containing more audio data, or a broader dynamic range, for example, lame will utilize the VBR model to increase the bitrate according to the general principles of the psycho-acoustic model. While this occurs on a frame-by-frame basis, you’ll often see the adjustments displayed in a software player over several seconds of a file. It’s rare that only a single frame of audio data requires a bitrate adjustment.

So, there’s your first general rule when using lame to encode your podcast. For voice-only podcasts, the default CBR configuration should be fine. If your file contains a broad frequency and dynamic range, you’re better off using the VBR encoding routines. Using psycho-acoustics, the file size of these dynamic files will still be minimized while maximizing the sound quality.

In general, you can apply the same principles to the choice of bitrate and sampling rate for your final file. To reiterate, the frequency and dynamic ranges of the human voice are very narrow. Additionally, the sonic subtleties between voices are more in the realm of nuance than, say, the differences between a tuba and a flute. In other words, you can use a broader brush to paint those differences when your source is primarily voice. In the constant push and pull between quality and file size, you can safely encode podcasts that are primarily voice at both a lower bitrate and and a lower sampling rate. You won’t need as many pieces of the original source (sampling rate) nor the resolution (bitrate) to reproduce the natural sound digitally. Reducing these pieces will considerably reduce the size of your final file.

Conversely, music podcasts by their nature require much greater attention to the source and the final output. Masking the tight range of the human voice with lower bitrates and sampling rates won’t work with the dynamic and frequency ranges of music. Music podcasts encoded at sampling rates lower than 44.1KHz or bitrates lower than 96KBps sound compressed and lose much of the important distinguishing range, both dynamically and in their frequencies. The end product is likely to be a mass of midrange, lacking any dynamic coloration. While the file size will certainly be smaller, that really defeats the point of presenting music which, by its nature, requires maximum clarity and sonic range.

Here are a few command-line suggestions for encoding the various types of files you may deliver as a podcast, culled both from experience and the lame man pages.

For a voice only podcast, perhaps with some short transitional music pieces, try:

$ lame -b 64 -m s input_file.wav output_file.mp3

This will set the constant bitrate (the lame default) of the output_file.mp3 to 64Kbps (-b 64), disabling the default joint stereo encoding and downlsampling to a mono file (-m s). The result is a considerably smaller file size that will still maintain a reasonable voice sound quality.

For a podcast that’s primarily music with some voice interaction between the cuts:

$ lame --vbr -b 128 -B 192 -s 44.1 input_file.wav output_file.mp3

This option set utilizes the lame VBR model (–vbr), defining the minimum (-b) and maximum (-B) bitrates, and assuring that the overall sampling rate (-s) will be at 44.1KHz. While the file size will be considerably larger, the gain in that increase is a much broader frequency range and dynamic response. The subtleties of the music will not as devastated as those in the file created in the previous command-line example.

Like any good application, lame also contains some broad shortcuts for achieving the sound you’re looking for in your final file. In lame, these come in the form of presets that can be easily implemented on the command line. If you’re willing to sacrifice some of the control over file encoding, you can apply these presets in an effort to save keystrokes. The presets in lame are actually broken out into sub-categories as follows:

Speed presets: normal (default) and fast

Bitrate presets: vbr (default) and cbr, with additional bitrate options Quality presets: standard (default), extreme and insane

It’s a good idea to apply the presets in the above order on the command line. So, for example, a voice-only podcast might be encoded with the following preset options:

$ lame --preset cbr -b 64 input_file.wav output_file.mp3

A music podcast, on the other hand, might utilize the following preset options:

$ lame --preset fast extreme input_file.wav output_file.mp3

This example will encode the output_file.mp3 using a variable bitrate between 128Kbps and 320Kbps, with a 44.1 sampling rate – much better quality with fewer keystrokes. However, the “fast” preset may result in a small amount of signal degredation due to the faster encoding passes. If you’re looking for the absolute best quality from the presets, always use the “standard” option. Note, also, that the bitrate presets cannot be used in conjunction with the speed and quality presets. The bitrate preset stands on its own, while the speed and quality presets can be combined.

Lame is rich with options other than simple bitrates and sampling rates. If, for example, you’ve used normalize to adjust the gain in each file individually, or to adjust the gain of the file as a whole, you may want to utilize the “noreplaygain” option. This overrides the default gain adjustment of -3 Db applied by lame, preventing multiple gain adjustments that may negatively impact overall sound quality.

$ lame --vbr -b 128 -B 192 --noreplaygain input_file.wav output_file.mp3

Lame also accepts input from STDOUT. This can be very useful for scripting, especially when batch output from a collection of files is desired.

$ lame cat input_file.wav | lame --preset fast standard - > output_file.mp3

lame also includes a full set of options for writing id3 tags on the fly, as part of the encoding process. The allowed tags include title, artist, year, genre, comments, and album title, among others. These are applied utilizing –t[x] options, where x denotes the specific id3 tag.

Finally, lame provides the ability to further tweak the psycho-acoustic model algorithms in an individual file by the use of a -q value option. This option sets the highest possible value (best quality) as 0, with 9 effectively disabling the psycho-acoustic model algorithms altogether. 5 is the default -q value setting. Increasing the value by reducing the n argument with the -q n option in the command line can make a discernible difference in the overall quality of the file, without further increasing the size of the file itself. While values of 0 and 1 are nearly indistinguishable, the difference between a -q 0 and a -q 5 is clear to most listeners.

By way of a real-world example, here are the options I use for encoding the Roadhouse Premium each week:

$ lame -b 160 -q 0 --noreplaygain --tt "Roadhouse Premium 105" --ta "Tony Steidler-Dennison" --tl "The Roadhouse Premium" --tc "Roadhouse Premium 105 - Strong, Lean and Broad" --ty 2007 roadhouse_premium_105.wav roadhouse_premium_105.mp3

As always, its a good idea to dive into the lame man page for the full scope of usage options, including some clear practical examples. With a history approaching 10 years, the main page is both detailed and thorough. You’ll undoubtedly find it as useful as I have in your own implementation of lame for podcast encoding.

So, we’ve built the frame, hung the drywall, taped and plastered the seams, applied a finish and painted the walls. In the next installment of “Attack of the Pod Penguins,” we’ll pick out the finishing nails to hang the pictures. Those will include a discussion of some GUI-based id3 tagging applications for Linux, and an understanding of the critical RSS file that announces to your listeners that a new edition of your podcast is available. Looking further down the road, we’ll wrap the series with installments on hardware and on the critical issues of music licensing facing any podcaster.

Until next month, I hope to see you in The Roadhouse or IndieFeed Blues.