TheEC: IP Audio Codecs

Providence, RI – This time on the Engineer's Corner let's talk about CODECS. Short for "encoder / decoder," codecs are a fact of modern life; used in cellphones, digital cable TV, digital television, the internet, you name it! Anywhere there's data, there's probably a codec involved.

Today, as befitting a radio station, we'll talk about audio codecs. You've almost certainly used one before: any time you've listened to an MP3, you've listened an audio file encoded with the MPEG-1 or -2 Audio Layer III (hence "MP3") file codec. If you've listened to RIPR's webcast, you've heard the streaming version of the MP3 codec. Or perhaps you've listened to "M4A" files from iTunes? That's the MPEG-4, Part 14 wrapper around an Advanced Audio Coding (AAC) codec. Or if you've talked on a cellphone, you've heard a given codec (they tend to be proprietary to the wireless carrier). Or used Skype, which uses their own "SILK" codec.

Or if you were listening to WELH 88.1FM in Providence over last weekend, you heard the Comrex B.R.I.C. codec we used while our main studio/transmitter audio link was being repaired (the main was having repeated, intermittent dropouts). Didn't hear the difference? GOOD! You're not supposed to! :-) Ideally, a codec is "transparent," meaning you can't really hear the difference. Achieving transparency is usually a tricky balance between audio fidelity and latency/delay.

Usually, the more delay you introduce with a codec, the more time its algorithms have to examine the audio, decide which bits must be saved and which can be "safely" discarded, and the more time the far end of the connection has to "buffer" against the inevitable loss of data especially across the public internet. So the more delay, the better the sound and/or the more reliable the connection.

But not every application has the "luxury" of long delays. Cellphone conversations, for example, need to keep that delay to a few hundred milliseconds. So their codecs are designed to sacrifice audio fidelity to maintain low delay and reliable connections.

Broadcast applications, though, often don't have that luxury either. They need low delay, reliable connections, AND broadcast-quality audio. The secret in that is the codec must be designed especially for those traits. Such codecs are only *required* by a comparatively small population so they tend to be pretty expensive. The Comrex B.R.I.C.-Link device RIPR employs run about $1300 each, and you need one at each end of the connection! And even then, there's not always a free lunch but broadcast devices like Comrex's are designed to automatically adjust the fidelity and delay "on the fly" to adapt to changing network conditions. So maybe not quite a free lunch, but it's getting free double meat on your grinder.

Mmmm time for lunch! See you next time!