Context | Listening test setup | Listening test 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 simplified frequency spectrum 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-Gesellschaft, the original developers of the MP3 codec (who I will occasionally refer to as FhG), 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. (This was actually much cheaper than the hardware MP3 encoders that existed before this.) Fraunhofer thought only broadcasters would have any interest in anything MPEG, so it was priced like broadcaster gear.
As it turned out, with growing hard drive sizes and a desire for more portable music than a Discman could provide, broadcasters were not the only ones who wanted MP3. These tend to get conflated, including me on a previous version of this page, but there were two prominent thefts of Fraunhofer's encoders and code that saw the mass proliferation of MP3 encoding technology.
- Fraunhofer's own encoders: People began to poke at l3enc's even-more-expensive GUI sibling MP3 Producer ($500 for the "Professional" up-to-128kbps version!) and found that the encoder itself used Windows' Audio Compression Manager framework and had zero limits on its use. The only thing guarded by that price tag was the frontend user interface bit. In 1997, an Australian college student used a stolen credit card to buy MP3 Producer, ripped the ACM backend from it, wrote his own frontend, and uploaded it to an FTP server for all to use. More frontends proliferated, nearly all the targets of legal threats by Fraunhofer.
- The dist10 codebase: Fraunhofer contributed, totally separate from l3enc, to a reference implementation of an MP3 encoder nicknamed dist10—this was meant to be a very rudimentary encoder to show software developers how MP3 encoders were meant to be built. This too was stolen; a Dutch hacker going by the name SoloH took it off a server at the University of Erlangen in Germany, releasing the source online alongside his own compile of and frontend for it called mpegEnc. dist10-based encoders, bad as they were, became very common among tinkerers looking to build their own MP3 encoders. Some rewrote the code to be faster, or to improve quality. Again, Fraunhofer took legal action against them all.
Legal action or not, there was no putting the genie back in the bottle. Illegal, copyrighted MP3s flooded the Internet, leading to the Diamond Rio, Napster, and MP3.com debacles, among others. While Fraunhofer scrambled to reduce the price of their encoders and get slightly more legal encoders into people's hands through MusicMatch Jukebox and similar software, 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 FhG 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, mpegEnc, countless others |
| A custom encoder written in x86 assembly, making it much faster than its contemporaries. None other than RealNetworks (remember RealPlayer? Sorry) 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 (FhG litigation paranoia continues), 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- |
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!