High Bit Rate MP3s: Are they Necessary?

O'Reilly editor and author Mike Loukides is an accomplished classical pianist who records with the MP3 format. He's recently been experimenting with high-bit-rate recordings. Here are his findings ... and while you read, enjoy a piece of his music.

Up until now, I've been making MP3 files with the 128kbps rate. That was completely adequate for my needs, and I tended to dismiss the statements of people like Tord Jannson (author of BladeEnc), who insisted that 160 and 256kbit rates provided significantly better sound quality. After all, the audio world has always been full of people who have insisted that they could hear things that other people couldn't, usually with no basis at all--remember CD "greening" (the idea that CDs sounded better if you made a circle around the edge with a green magic marker)?

However, I've just done some experiments that proved to my satisfaction that the higher bit rates are not only better for encoding CD audio, they're essential.

The Problem

As part of a project (building a Linux-based home recording studio), I recently installed a professional audio card on my PC. (For those interested in the details, the PC is an HP Vectra 350Mhz Pentium II; the audio card is an RME Digi96/pad; I'm using the commercial version of the OSS drivers.) As soon as I got the card working, I tried listening to some of the MP3 files I had generated from. As is common in the audio world, upgrading one part of your system makes you realize the rest of the system isn't as good as you thought it was, and this was no exception. I've found most of my MP3 files unlistenable. The sound was basically good, but there were intolerable very high frequency artifacts coming from somewhere. They weren't something you could ignore.

There were three possible explanations for these artifacts:

• The RME card could be defective--I obviously had to figure this out while I still had time to return it.
• The CD ripping could have introduced errors. I used Galette on Solaris to do the ripping, and it's nowhere near as sophisticated as cdparanoia. And I have been suspicious that the CD drive on my Solaris machine is on its way out.
• They could be artifacts introduced while converting the wav files produced by Galette into MP3. I used the BladeEnc (0.82) encoder at 128kbits.

The first hypothesis was unpleasant--I didn't want to return the card, though clearly, I'd have to if its results were unacceptable. At the same time, I had played a number of MP3 files--including some of my own recordings--that weren't encoded from CDs, and hadn't noticed this problem. And I also didn't notice the problem when I played unencoded wav files.

The last two hypotheses assume that the artifacts were present all the time and I didn't hear them either because of the limitations of my previous sound card (a SoundBlaster 16) or the internal sound on a Sun workstation. I was prepared to believe this, but a little suspicious. The SoundBlaster was clearly not good at playback, but the Sun sound was surprisingly decent. (That's another story.)

The only way to test these hypotheses was to start with ripping again. This time, I used cdparanoia, which didn't find any errors. This surprised me, but it meant that I now knew I had clean wav files. It was time to go to the next step: generating MP3 files (now using BladeEnc 0.91--time had passed). I first tried 128kbits, to see if this solved the problem. It didn't; the artifacts were as bad as before. Next, I tried 256kbits. The artifacts were gone completely.

Conclusions and Recommendations

So the conclusion was clear. The problem wasn't in my sound card; it was in the MP3 conversion. I was unable to hear the artifacts because of the limitations of my previous sound card, but they must certainly have been there. I'm now convinced that there are problems with 128kbits for encoding CD sound. This isn't a subjective "Gee, I like this one better than that"; you could actually see the artifacts on the MP3 player's scope.

There are a few remaining questions:

• As I said, I used BladeEnc, which is a great piece of software. However, the question remains: Would the artifacts be there if I used a different encoder?
• I didn't try 160kbits; it's an interesting question whether 160kbits is adequate.
• I haven't tried other MP3 players (I was using XMMS).

My recommendations: MP3 files are large enough. It's hard for me to recommend seriously that people encode at 256kbits. That requires about 2Mb/minute of playing time, and that's a lot of disk space to chew up to avoid audio problems that you may not be able to hear. It is worth listening critically to your MP3s and deciding whether or not it would be worthwhile re-encoding them at a higher bit rate. If you're contemplating a high-end sound card, I'd certainly recommend starting to use the higher rates now.

An Addendum: Mike Continues to Push the MP3 Envelope

Since I first wrote this article, I've had time to experiment with two more MP3 encoders: L.A.M.E. and Fraunhofer. Like BladeEnc, L.A.M.E. is an open-source product; Fraunhofer is a commercial product, and is not available on Linux as far as I know. L.A.M.E. is particularly interesting because it supports variable bit rate encoding, and implements a number of "psycho-acoustic enhancements."

I took one of my audio files that was showing artifacts when encoded with BladeEnc, and generated 15 different MP3 files, using the different encoders at bit rates. Here's a quick summary of the files I generated:

BladeEnc: 112, 128, 160, 192 kbit
L.A.M.E.: 112, 128, 160, 192 kbit
L.A.M.E. with VBR: 112, 128, 160, 192 kbit
Fraunhofer: 112, 128, 160 kbit

(L.A.M.E. has many settings that you can fiddle with; aside from enabling VBR, I made all the recordings at the "highest quality" setting, and otherwise used the defaults. When you're using L.A.M.E. with variable bit rate, the encoding rate represents the minimum resolution the encoder will use.)

I haven't even listened to all the files yet. But I can summarize what I've heard so far. The artifacts are worst with BladeEnc--on the recording I used, audible up to 160kbit. L.A.M.E. was significantly better, the artifacts were noticeable at 112, barely noticeable at 128 (arguably not there), and not noticeable at 160. Fraunhofer gave the best results; the artifacts weren't noticeable at any resolution that I tested.

I was surprised that enabling variable bit rate didn't have a noticeable effect on the artifacts. Whatever triggers the higher bit rates appears to be unrelated to this artifact problem.

Recommendations Reconsidered

First, ask yourself "Do I care?" These artifacts are really annoying to me when I listen on a pair of good headphones. I'm using a Sony MDR-7506 model. But headphones place a really good tweeter a half inch away from your ear. If you're playing recordings through a regular loudspeaker system, you might not be able to hear them. I've yet to run a cable from my computer to my stereo (which is at the other end of the house), and the speakers currently attached to my computers are really poor. I've asked a number of people whether or not they can hear the artifacts on their speakers, and the answer so far is "no."

If you decide that you do care--and I think you should, regardless of your speaker system--what should you do? On Linux, I strongly recommend using L.A.M.E. Although I'm nervous about software that tries to "enhance" what's already there, I have to agree that the L.A.M.E. encoding sounds good--their enhancements, whatever they are, don't seem to interfere with the sound quality. I would still recommend generating 160kb MP3 files to avoid the possibility of artifacts. Variable bit rate doesn't help much, but it doesn't hurt much, either; the files are only a couple percent larger than they would be otherwise. VBR definitely won't let you get away with a 128k bit rate.

If you need to generate the smallest MP3 files possible without artifacts, I think you'll have to go to Fraunhofer. You can probably get decent results with bit rates as low as 128k, but I wouldn't recommend going below 128k.

Related Reading MP3: The Definitive Guide By Scot Hacker

Sponsored by: