Climbing the Family Tree of MP3

Context | Listening test setup | Results

It's been a recurring fascination of mine, that being data compression. It's what makes the modern internet possible at all. Only recently have we been able to share multi-gigabyte files quickly and fairly cheaply. In the 90s? There was no question that whatever you uploaded need to get squished somehow.

MP3s are second only to JPEGs in ubiquity, and with both patent-free by this point, I doubt we'll ever be rid of them. But once upon a time, that wasn't quite the case! MP3 encoders were, in fact, fiercely guarded by big corporations—leading to knockoffs with wildly different resulting MP3s, even if they were all identically playable.

I've got five different "families" of MP3 encoders, from different origins and built of different code, and I thought it'd be fun to take some songs and compare the quality and speed differences. I've even got a robot listening buddy on board!

How can there be any different-sounding encoders out there, let alone five?

So the very basic gist: MP3 is a lossy compression scheme. It tosses out audio information to make a smaller file, the goal being that it's data you can't hear or don't mind if it's gone. An encoder splits audio up into a series of frames and 22 bands of frequencies in each frame, and then determines which bands in each frame are the most audible and which ones get covered up by other bands, the latter of which get encoded with lower accuracy. It's actually not far off from how JPEG works, splitting your image up into 8x8 blocks and converting each one into a lower-accuracy frequency as opposed to raw pixel data.

The funny part about MP3s is that the specification is far less strict about how the encoders work than how the decoders work. So long as the end result is a validly-structured MP3, it can output what sounds like your song, bleeps and bloops, or pure noise, and all is kosher. Fraunhofer, the original developers of the MP3 codec, figured that later encoder developers would find better ways to trim away audio in the coming years, leading to better-sounding MP3s that still played on all existing players.

They'd be right, as you'll soon learn.

Stolen code and healthy competition

Fraunhofer released l3enc, the first software MP3 encoder, in 1994 for an eye-watering $250 (or equivalent in 1994 Deutsche Mark). Most people did not pay that. In 1997, an Australian college student stole l3enc, along with the "dist10" reference implementation (a much more rudimentary MP3 encoder than l3enc), and released both on FTP for the world to use. There was no putting the genie back in the bottle; not only did illegal, copyrighted MP3s flood the internet (leading to the Diamond Rio and Napster debacles), but hobbyists started tinkering with the dist10 code, earning Fraunhofer's ire in the process.

While Fraunhofer scrambled to reduce the price of their encoders and get slightly more legal encoders into people's hands through MusicMatch Jukebox, other companies began developing perfectly compatible MP3 encoders from the ground up, using none of the stolen code (and thus being legally much less risky). Some hobbyist projects were a little smarter and developed as patches off the dist10 source that the user would have to provide separately, also being untouchable (and leading to LAME, but hold that thought).

All of these output completely different sounding MP3s, all identically playable on all players (barring what settings you used), but all being noticeably different in their sound quality and resulting artifacting. By the time the (tech) world was moving on from MP3 in the mid-2000s, five families of encoders had emerged:

Family Origins Encoder examples
Fraunhofer-based Officially developed by Fraunhofer and available for inclusion in applications for a fee. If you've ever encoded an MP3 in iTunes or Adobe Audition, you were using a Fraunhofer encoder. l3enc, mp3enc, fastenc
dist10-based The MPEG reference implementation, meant as example code for how an encoder should function in a product. Rudimentary and low-quality. Most encoders were straight compiles of the code, but a few projects intended to improve quality or speed the code up. 8hz, Blade, Plugger, SoloH,
countless
others
Xing A custom encoder written in x86 assembly, making it much faster than its contemporaries. None other than RealNetworks bought Xing and continued its development as Helix, later making it open-source altogether. Xing, Helix
LAME The big one! LAME started as a dist10 patch from an 8hz developer, but by LAME 3.81, it was all custom code. It's become so finely tuned that quality now surpasses Fraunhofer's encoders in listening tests. LAME is only distributed as source code (ongoing Fraunhofer litigation paranoia), but unofficial binaries proliferate. LAME, Gogo
Shine Effectively a modern-day dist10, Shine was developed by LAME's Gabriel Bouvigne as a simple reference for new encoder projects as opposed to being fast or high-quality. It's also the only open-source encoder available in a fixed-point math version. Shine

On the following pages, we're gonna set up our encoders, configure the robot listening buddy, pick some songs to test these with, and give you the results of it all. Hope you enjoy audio nerd stuff!

< Back to the index | Listening test setup >