The Levelator™ Loudness Algorithms

Over on the discussion mailinglist from AIR (The Association of Independents in Radio), we’re revisiting the recurring discussion about RMS levels in spoken-word audio files. Two days ago Gregg McVicar asked: “So what was the RMS value that you found to be the sweet spot for podcasts?”

Unfortunately, it’s a very complex answer. I’m not trying to be elusive or secretive. It really is complex. There isn’t a single value that works for even two different audio-editor applications let alone all of them. If I posted a realistic spoken-word .wav file and said, “this is standard,” and then you measured the RMS level of that track in various apps such as Pro Tools, Sound Forge, Soundtrack Pro, etc., each app would give you a different value. (Try it!)

The reason is ‘silence’. Each application has a different way of excluding segments of silence from the RMS calculation. In fact some of the most-expensive utilities don’t exclude silence at all, rendering them virtually useless for this aspect of spoken-word processing. (Is one recording half as loud as another because the speaker in the first one pauses twice as long between words?)

So the answer to Gregg’s question is that The Levelator adjusts speech to -18.0dB RMS, but that isn’t a value you can plug into any other program. If you are looking for an answer relative to your audio-processor of choice, the best way is to run a real-world program through The Levelator then measure the resulting RMS level using your software. The level your application reports as the RMS level is *your* answer to what we’ve found to be the sweetspot for podcast RMS levels.

Personally, I love the discussion of RMS levels, particularly because it’s so full of prejudices and misinformation. But I’m sure it’s not as interesting to many other people. It’s a problem I’ve worked on personally for some time, and I continue to geek out on it. If you share my passion on the topic, or if you want to know more about how The Levelator deals with RMS levels, you may enjoy a page I just posted entitled The Levelator™ Loudness Algorithms.  I would have posted this earlier, but I wanted to first run it by Bruce Sharpe, our resident math professor and designer of The Levelator’s algorithms. I’m just the concept guy on this one. 🙂


The greatest challenge in keeping running on a daily basis is dealing with rogue RSS feeds. We’ve got a bit over 3,000 feeds at the moment, most of which are being scanned every hour. But I just checked the admin report, and 27 feeds (nearly 1%) have been disabled for one reason or another.

For those of you in control of your feeds, here are some of the problems we encounter on a regular basis.

  • HTTP 404 errors. If your server isn’t accessible, we can’t read your feed.
  • Invalid characters. One bad character in your feed keeps our parser from reading the whole thing.
  • Missing GUIDs. Globally Unique IDs (GUIDs) are very important.
  • Duplicate GUIDs. (They’re supposed to be Unique!)
  • Incorrect MIME types. Should be:
    • application/rss+xml
    • application/atom+xml
    • application/xml
  • The following are common, but they’re wrong:
    • text/xml
    • text/plain
    • text/html

The GUID issues deserve more discussion. When you rescan feeds every hour, one of bigest challenges is to figure out if an <item> is old, new or modified. Here’s our logic:

  • If we’ve never seen this GUID before, we assume it’s a new <item>.
  • If we’ve already ingested an <item> with this GUID, we check all the pertinent elements and attributes for changes.

The GUID allows you to make changes like correcting a spelling error in a title. We see the unchanged GUID, notice that the title has changed, and just replace the title. Without the GUID, we have a helluva time trying to figure out whether an <item> with a one-character change in its title is just that or a whole-new program. We want you to be able to correct your titles, descriptions and media URLs without our system creating a duplicate program. Only your proper use of GUIDs makes that possible.

Once you assign a GUID to a program, never change it. That means never. And make sure your GUIDS are truly globally unique. Using a unique URL from your site as a GUID is a good way to do this. No other site is likely to include http://yourdomain in their GUIDs. And never, never, never reuse a GUID for another program. You’d be amazed at the number of feeds that include the same GUID for more than one <item>. I’ve designed our system to immediately disable any feed in which a duplicate GUID is detected.

As a somewhat defensive move, but also to help those who submit RSS/Atom feeds to, I’ve added code that runs submitted feeds through the W3C RSS Validator. We’ll accept Warnings, but if your feed generates Errors from the validator, we will reject it. My next step is to likewise call the W3C validator when we encounter a problem and to after-the-fact disable feeds that don’t validate.

Fresh Hot Radio Replaces Muzak

Okay, so Lucas is gonna kill me for the comparison, but is it just coincidence that only three weeks after Muzak filed for bankrupcy, Lucas Gonze launched his new site, Fresh Hot Radio? I think not. Lucas is one of those true web pioneers who’s always a few steps ahead of the rest of us, so I’m not sure I yet understand all the implications of his new site. It’s subversively simple. Open it in a web browser tab or new window and listen to the music. That’s it. Options? Nope. It’s not a stream — all the files are played using Flash from their original locations — but it plays like one, except you can pause and skip. It’s Lucas’ personally curated music. There’s no social-networking facility. It’s just for you. You can, however, click through to the source of each song to explore further. Think of discovering new up-tempo music and he artists who create it.

I look forward to the day when all elevators are playing Fresh Hot Radio instead of that Muzak stuff.