Attack of the Pod Penguins 5: Normalization

In this installment of the “Attack of the Pod Penguins” series, we’ll move away from the GUI tool Audacity and into the realm of the command-line. While Audacity is clearly a great open source tool with features rivaling that of its proprietary counterparts, it also suffers a bit from attempting to be everything to everyone. It strays a bit from the open source philosophy of creating small tools that do one thing well.

In this installment of the “Attack of the Pod Penguins” series, we’ll move away from the GUI tool Audacity and into the realm of the command line. While Audacity is clearly a great open source tool with features rivaling that of its proprietary counterparts, it also suffers a bit from attempting to be everything to everyone. It strays a bit from the open source philosophy of creating small tools that do one thing well.

Early on in my use of Audacity, I realized that, despite Audacity’s full-featured design, the best way to attack some of the issues of podcasting is still the single-tool approach. While Audacity does some things quite well – visual editing, compression, exporting to a full range of file formats – the end result with other built-in Audacity tools was a little less desirable. Somewhere in the implementation of these single tools within the Audacity interface, they lost a bit of their power and charm. Don’t misunderstand me – my podcasts would be nearly impossible without Audacity. It just doesn’t always offer the polished final product that I’m looking for with The Roadhouse, The ClarkCast and IndieFeed Blues.

Whether you’re interested in a music-format podcast, or one that’s primarily spoken-word, you’ll inevitably run into some vexing issues. The issues always seem to stem from the nature of audio recording and how the raw files at your fingertips, awaiting editing and post-production, can sound so different from what you expect to hear in a final format. Despite great effort to record files of a consistent quality and sound, there’s always a gap between expectations and reality. The problem is the transfer of the sound from a natural holistic medium – sound waves in the air captured by the ear and interpreted by the brain – to one in which software and hardware are an integral part. There’s something about computers that squeezes the natural life out of audio files. Honestly, the same could be said of magnetic tape in the days of reel-to-reel recording, or of cassettes in their heyday. The act of capturing audio in any mechanical or electronic format tends to suck the natural feel right out.

So the primary challenge in processing digital audio files is fundamentally the same as it’s been in any analog medium. It’s the problem of recording a natural sound in a way that only minimally intrudes on the natural qualities, then processing that sound in a way that doesn’t sound processed. When put that way, it seems like a bit of a conundrum. But, take heart. It’s a conundrum that’s been attacked and, to a large extent, solved by the hundred-year-plus history of capturing audio. Some great minds have spent time analyzing the problem and have created and applied solutions — solutions that are available to all.

There’s another issue that’s particularly applicable to podcasting. It’s the revolutionary attitude toward podcasting as citizen media – the Holy Grail in the break from institutional information. It’s the idea that media belongs in the hands of citizens. I couldn’t agree more wholeheartedly with the premise. But, there’s still some difficulty in defining the qualities of that citizen media. Purists would, in many ways, be willing to throw out the baby with the bathwater to achieve a complete break from the mainstream media we’ve all grown up with. In advocating a radical departure in content, mainstream media as a whole is painted with a broad brush. Podcasting purists – those who most vociferously advocate a complete break from corporate media – seem willing to toss out the sound of mainstream media, as well. Forget the contrived formats. Forget the self-obsessed radio personalities. Forget the in-your-face and largely irrelevant pursuit of commerce in the form of advertising. Everyone agrees that those elements of media can go away with little real loss. But, to some, media doesn’t really become citizen media until its physical sound is also radically different.

My premise is proven over and over in thousands of podcasts for which attention to sound quality seems to be a shunned element of the old media. To some, a podcast has to sound unrehearsed, natural and, in many cases, uneven, in order to represent a complete break. In a subtle confusion between content and audio quality, podcasters often seem far too willing to toss aside the careful attention to capturing and processing sound. The revolutionary says, “Podcasting shouldn’t sound like radio.” In terms of content, I’m with the revolutionaries.

But the sound of radio is really, subtly, what we expect, even in a podcast. For all the shortcomings of radio related to content and consumerism, the audio engineers who have brought us to this point in the sound of radio have done very well. We expect a certain level of sound quality – a level established by radio, even in podcasts. That’s because, in large part, radio has solved the conundrum noted above – recording natural audio in a non-intrusive way and processing it in a way that doesn’t sound processed. And, if it does sound a touch processed, we understand it’s radio.

Which brings us back to the original and most fundamental premise of this series of stories: that creating a podcast in Linux makes great use of the “one tool, one job well” philosophy of open source. While you’ll certainly need a framing hammer like Audacity in building your podcast, you’ll also need a level, a plumb bob and a tape measure. Those tools exist in abundance for Linux and other free and open source software platforms. In short, there’s really no reason why your podcast can’t be delivered with the high quality audio most listeners expect, whether or not they realize it’s expected. Individual command-line tools exist to solve all the problems inherent in the audio capture conundrum. For the most part, they offer all the flexibility and control you’d expect from command-line tools and are, with a bit of investigation, very easy to use.

The first of these tools is one best explained by first stating the problem it’s intended to solve. Regardless of the type of podcast you choose to produce, it’s likely that you’ll have more than a single file to edit and include in the show. And, it’s unlikely that you’ll be able to control these files from start to finish. You may choose to include musical transitions in a spoken-word podcast. Or, to improve overall quality, you may have participants in a roundtable format record and submit their parts of a Skype call locally. Even in cases where you control the process start to finish, you’ll likely still find that some elements of the audio are quieter than others. As you’ve seen with Audacity, you can choose to amplify those sections or files by hand. But, that’s a terribly inefficient and time-consuming process. And, it’s unlikely that you’ll be able to make those adjustments seamlessly.

Audio engineering pros have given us a means to maximize the levels of audio files in the form of normalization. Wikipedia defines normalization as:

… the process of increasing (or decreasing) the amplitude (volume) of a digital audio recording. Typically normalization increases the amplitude of the audio waveform to the maximum level without introducing any distortion into the recording.

(A small point of clarification: the process of normalization actually involves raising or lowering the peak amplitude of a waveform without introducing distortion.)

Even with a single audio file, normalization provides great value in transforming the sound to a standardized level. It’s entirely possible that that single file will contain passages that are both quieter and louder than a standard. That value only increases when working with multiple files that may be of varying amplitudes. Normalization makes it possible to “level out” the amplitude of the files and to greatly improve the consistency of the overall sound.

While Audacity has normalization tools built in, I’ve found it better to use the command-line tool normalize-audio. As with other command-line tools, the standalone version offers far more flexibility by way of options, customization and scripting. Additionally, recent versions of normalize-audio work equally well with mp3, ogg or wav formats. Where previous versions needed the specific headers of wav files, current versions are capable of reading and modifying the headers of these other popular audio formats.

That mention of headers lends some insight into how normalize-audio performs its magic. An audio file contains discrete, independent frames of audio information. Each frame contains a header – the metadata about the frame itself. The MPEG audio header, for example, defines such frame parameters as bitrate index, sampling frequency and channel mode (stereo or mono). It also includes an eight-byte header field for Replay Gain. (In practice, mp3 files generally store this metadata as tags in the id3 format, though the Replay Gain standard requires the eight-byte header field.)

Normalization is a two-pass process that first reads the levels of the audio data, then adjusts the levels accordingly. The process leaves the original audio data unmodified, altering instead the Replay Gain header or tag information. This data is then read by the player with adjustments made on the playback side of the equation. Audacity, XMMS and other open source audio tools read and utilize the Replay Gain information.

One drawback to normalization is spurious peaks. Note that the adjustment of the Replay Gain information is based on the peak gain of an audio file. In some cases, a spurious or momentary peak in the audio data can fool the normalization process into adjustments that may not be completely accurate. A closing door or hand clap, for example, may produce such a peak, resulting in an adjustment to the overall gain of the file that doesn’t reflect the actual audio levels contained within. For absolute precision, Dynamic Range Compression is a good alternative, and is used in most professional sound mastering applications.

Normalize-audio utilizes several user-defined modes. In the bare format (without options), it merely adjusts the gain of a single file or batch of files to -6 Db. An example of this usage would be:

normalize-audio sample.wav or normalize-audio *.wav

Normalize-audio also offers two other options for normalizing sets of files. These options create relative gain levels among a group of discrete files.

The Mix Mode option (-m) is used to adjust for a “mix.” This is used when you’d like to adjust the gain of several files to the same level, though it’s not important that that level is the same level you applied in previous mixes. Normalize-audio reads the level of each file, calculates an average, then adjusts the gain of each file to the average.

normalize-audio -m *.wav *.mp3

Batch Mode (-b) takes a bit more subtle approach. Rather than adjusting all the files to the same absolute level, it treats all files as one and calculates the average. Normalize-audio then applies the gain to the individual files relatively. This preserves the original differential between gain levels on, for example, a batch of files ripped from a single CD. Batch mode works on the assumption that the relative difference in volume between files is intentional, and preserves that intent. The loudest file in the batch will be normalized to the maximum level. The others will be adjusted in relation to the loudest.

Normalize-audio also offers options to define the gain level of each file with the --limiter=LEVEL option. LEVEL is the level at which samples in a file are limited. By default (without the --limiter=LEVEL option), samples are limited at -6 Db. --limiter=1 does no limiting above 0 DB, clipping anything beyond that, instead. --limiter=0 limits all samples.

By default, normalize-audio provides verbose output to the terminal. The progress of the read pass is displayed, as is the progress and adjustment to each file in the second pass. It’s always interesting to see how widely the sound levels of a batch of files can vary, with adjustments often ranging from -7 Db to +7 Db.

I use normalize-audio every week in putting together The Roadhouse. My primary goal with a music podcast is to make sure that the volume levels of every included song are the same, or at least perceived to be the same. And, it’s important to me that the overall levels of one show match those of another. For that reason, I use normalize-audio in its bare form, without options. Each individual file is normalized to -6 Db, and that normalization is consistent from one show to the next. As all the music files are from different sources, I also can’t assume that varying levels are intended. The files should be as close to equal in amplitude as possible.

On the other hand, The Clarkcast, as a spoken-word podcast, presents a different set of challenges. I use the mix mode for all files in any given Clarkcast, as the relative levels are important, though it’s less important that one episode of the podcast be of exactly the same level as the next.

If you choose, you can adjust every file included in a podcast using normalize-audio. For months, I did so with The Roadhouse, adjusting all the audio, transition and voiceover files in a single shot. Recently, I’ve turned to hardware solutions to process the voiceover files, leaving only the task of adjusting the audio files to normalize-audio. We’ll look at some of those hardware solutions in a future installment of the series.

Podcasts can be a rich source of compelling content for listeners. They’ll become more important as we begin to make a sharper distinction between information provided by corporations and information provided by folks like ourselves. But the media revolution that’s already underway is about the content and presentation, not about the fundamentals of capturing and processing sound. For that, we’ll still rely on the knowledge passed along by generations of audio engineers to process sound in a way that users find easy to listen to. Open source tools such as normalize-audio clearly advance the parallel goals of empowering citizens and presenting quality audio.

Next in the series: we’ll discuss lame, an invaluable tool for converting your podcast audio to a truly portable format.