Good coverage, there, Kureg.

I'm currently re-evaluating my encoding options, and looking at Fraunhofer, LAME, and Xing (Audiocatalyst).

I spent a lot of time with two different versions of the Fraunhofer command-line encoder, and for me, they did the best job at fixed bitrates. Unfortunately, they don't do VBR, so it's into the bitbucket with them.

Now the race for me is between LAME and Xing. Both encoders have had recent improvements which significantly improve their sound quality. I have personally verified that Xing badly mangles an 18khz sine wave, so the complaints that Xing discards high frequencies sound valid. However, almost all MP3 encoders discard frequencies above 16k, with only LAME claiming to handle those high frequencies at all. Even if LAME does reproduce those high frequencies, can it possibly be doing them accurately? Maybe there's a reason the other encoders discard them.

The only thing about LAME which scares me is an admitted flaw that can be found in its own documentation:

Note: VBR is currently under heavy development. Right now it can
often result in too much compression. I would recommend using VBR
with a minimum bitrate of 112kbs. This will let LAME increase
the bitrate for difficult-to-encode frames, but prevent LAME from
being too aggressive for simple frames.

This means that I have to specify a "bitrate floor" of 112kbps in the command line. Which, although understandable, means that I'm not getting the full bang-for-the-buck out of the VBR format. In other words, why go to the trouble of doing VBR if you can't have it compress the simple frames below 112? The result is larger file sizes, and the whole point of VBR was to get smaller file sizes.

As far as encoding speed, the LAME encoder, although slower than Xing, is much faster than Fraunhofer. So I'm considering doing some long-term testing with LAME. In fact, I've just added some encoder presets to my Jack program to support LAME. We'll see how it goes.

___________
Tony Fabris