lame v3.81 and 3.87 beta mp3 decoding quality test results

lame 3.87

Decoder Source:	The Lame Project http://www.sulaco.org/mp3/ (Open Source Community) Source code, Executables.
Version:	v3.87 BETA (MMX) Windows binary from here.
Price:	free
Settings:	`lame --decode input.mp3 output.wav`
Similar products:	Lame uses mpglib from mpg123 to decode mp3 files. Can use RazorLame - the graphical front-end
Verdict:	Excellent
VBR:	All
Full file:	Nearly Always
Major Flaws:	None
Minor Flaws:	Start of BladeEnc encoded mp3s clipped unless specified
Output level:	correct
1-bit relative accuracy:	Excellent
1-bit absolute accuracy:	Excellent

Lame is (or isn't!) an mp3 encoder - for more details, see the version 3.81 BETA review.

There have been three changes which may affect decoding since the previous test of lame. Firstly, MMX optimised binaries are now available for windows, in addition to the standard windows 9x version, and the Windows NT compatible version. In our tests, the MMX and non-MMX versions gave identical decoding output, including the last bit.

Secondly, the bug in the wav writing routine of version 3.81 has been fixed, and lame now writes .wav files correctly.

Thirdly, lame now compensates for the mp3 encoder delay. All mp3 encoders and decoders introduce a small delay (typically 1000-2000 samples). This is encoder dependent. Lame now removes its own 1105-sample encoder delay from every file it decodes. This means that mp3s both encoded and decoded via lame incur no overall delay. Most other encoders introduce more delay than lame, so there are still blank samples at the start, even after lame has removed 1105 samples. However BladeEnc introduces only 1057 samples delay, so by removing 1105 samples, lame actually clips the start of BladeEnc encoded files upon decoding.

I raised this issue with Mark Taylor, and he implemented a new option from version 3.88 onwards. If you wish to decode BladeEncoded files, or preserve the delay when using lame to decode mp3s, you should use this option: lame --decode --decode-mp3delay -529. See the table of encoder delays below for more possibilities.

Aside from this issue, lame passes all our tests, and is recommended. Try it with RazorLame - a windows interface for Lame.

Encoder Delays

With the option to compensate for various encoder delays, the following table may be useful. The encoders listed yield the following encode/decode delays, in samples, for 44.1kHz files encoded at CBR 128kbps or VBR default.

Encoder	Overall Delay	Encoder Delay	Decoder Delay	VBR header
FhG l3enc 2.72	1393	864	529
FhG mp3 Prod Pro 1.1	1393	864	529
FhG mp3 Prod Pro 2.1	1393	864	529
FhG mp3enc3.1	1688	1159	529
FhG FastEnc CBR	1201	672	529
FhG FastEnc VBR	2353	672	529	1152
Lame CBR	1105	576	529
Lame VBR	2257	576	529	1152
BladeEnc	1057	528	529

When decoding mp3 files with lame, to ensure Lame does not remove any samples from the start, thus giving the same delays as every other encoder, use: lame --decode --decode-mp3delay -529

If you know which encoder generated an mp3 file, you can remove the correct delay by using: lame --decode --decode-mp3delay x, where "x" is the value in the "Encoder Delay" column of the above table.

When decoding VBR files, Lame automatically detects and removes the VBR header from its own files, but not from those generated by CEP. When decoding VBR files, CEP automatically detects and removes the VBR header from its own files, but not from those generated by Lame!

UPDATE: The figures in the first column were measured directly. The other three columns suggest the possible sources of the measured overall delay. Where "VBR header" has contributed to this, the reference decoder did not skip the header, but decoded it as silent audio, so adding to the overall delay. Thanks to Robert for pointing this out. He also suggested that the mp3enc values looks wrong. It does, it's what I measured - suggestions?

Finally, here's a word from Mark Taylor to clarify the separation of the overall delay into encoder and decoder, and why this isn't a simple issue:

One point that needs to be decided is the split between encoder and
decoder delay, as there was some debate about this in the past.

Here's a simpleminded definition I use:

Total encode+decode delay: (These numbers are measured delay in samples, and not up for debate)
forward+backward polyphase filterbank transform: 481 
forward+backward MDCT transform: 576

Then we can just split them equally between encoder and decoder: 528.5
delay for foward polyphayse+MDCT (used by encoder), 528.5 delay for
backward polyphase+MDCT (used by decoder). To align the psycho
acoustics with the MDCT window, LAME adds exactly 48 samples of
padding for a total encoder delay of 576.5.

Mark

I've rounded the decoder delay up to 529 because this is what Lame does in its delay calculation.

Return to the list of decoders.

lame 3.81

Decoder Source:	The Lame Project http://www.sulaco.org/mp3/ (Open Source Community) Source code, Executables.
Version:	v3.81 BETA Windows binary from here.
Price:	free
Settings:	`lame input.mp3 output.wav --mp3input --decode -h` (does -h effect decoder? doubt it!)
Similar products:	Lame uses mpglib from mpg123 to decode mp3 files. Can use RazorLame - the graphical front-end
Verdict:	Excellent
VBR:	All
Full file:	Always
Major Flaws:	None
Minor Flaws:	None
Output level:	correct
1-bit relative accuracy:	Excellent
1-bit absolute accuracy:	Excellent

Lame is (or isn't!) an mp3 encoder, being developed as a joint, open effort by a group of programmers (anyone can contribute). The reason "Lame Ain't an MP3 Encoder" is that it is distributed as source code only - you have to compile it for yourself. This (possibly) avoids FhG's patents on parts of the mp3 encoding algorithm, which they have begun to enforce rigorously in some countries. Certain individuals don't worry about this, and compile the source, and make the resulting executable binaries (that's a DOS program to you and me!) available. Though lame is evolving rapidly, the documentation states that the decoding algorithm is sourced from mpg123.

The performance of lame in decoding mp3 files was faultless during these tests. Lame is highly recommended. Try it with RazorLame - a windows interface for Lame.

NOTE: The version tested here decoded to raw .pcm files, due to a bug in the .wav header writing routine. This has now been fixed. Newer versions also compensate for lame encoder delays - this has not been tested.

Screenshots

lame in use

Return to the list of decoders.