LAME 3.97: different binaries produce differente results!, bizarre: different LAME 3.97 binaries produce differente results! Options

[Adriano]

Hi.

I was VERY surprised to find out that different binaries for LAME 3.97, namely Rarewaves [1] and Mitiok [2], produce differente results, i.e, different mp3 files.

[1] http://www.rarewares.org/dancer/dancer.php?f=109
[2] http://mitiok.maresweb.org/dancer/dancer.php?f=3

Maybe that has something to do with "Recompiled to include mp2 decoding which was omitted, in error, in the original compile", which relates to Rarewaves link? Well, anyway it's not how it was supposed to be. I am currently using Mitiok binary, which is smaller and seems to be slightly faster.

Any clarification is very welcome.

Regards,
Adriano


Only to exemplify...

Mitiok:

CODE

LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav
to Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav.mp3
Encoding as 44.1 kHz VBR(q=2) single-ch MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
2846/2846 (100%)| 0:03/ 0:03| 0:04/ 0:04| 18.884x| 0:00
32 [ 6] *
40 [ 0]
48 [ 0]
56 [ 11] *
64 [ 63] ****
80 [ 697] **************************************
96 [1264] ********************************************************************
112 [ 551] ******************************
128 [ 162] *********
160 [ 90] *****
192 [ 2] *
224 [ 0]
256 [ 0]
320 [ 0]
-------------------------------------------------------------------------------
kbps mono % long switch short %
98.1 100.0 91.4 3.3 5.3
Writing LAME Tag...done
ReplayGain: -3.4dB

vs. Rarewaves:

CODE

LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav
to Fil¾ Machado - Tema pro Macumbinha [116-1100 Hz].wav.mp3
Encoding as 44.1 kHz VBR(q=2) single-ch MPEG-1 Layer III (ca. 7.3x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
2846/2846 (100%)| 0:03/ 0:03| 0:03/ 0:03| 18.656x| 0:00
32 [ 6] *
40 [ 0]
48 [ 0]
56 [ 10] *
64 [ 60] ****
80 [ 696] **************************************
96 [1272] ********************************************************************
112 [ 549] ******************************
128 [ 163] *********
160 [ 87] *****
192 [ 3] *
224 [ 0]
256 [ 0]
320 [ 0]
-------------------------------------------------------------------------------
kbps mono % long switch short %
98.1 100.0 91.4 3.3 5.3
Writing LAME Tag...done
ReplayGain: -3.4dB

This post has been edited by db1989: Sep 8 2011, 15:39

Reason for edit: adding codeboxes

[saratoga]

This is normal. Different compilers and settings produce different output on some FP code, so you get slightly different output. Quality should be the same though unless something is broke.

[john33]

The difference is, as already indicated, in the compilers used.

CODE

F:\Testdir>lame -V 3 --vbr-new 10.wav 10.mp3
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 17960 Hz - 18494 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9784/9784 (100%)| 0:12/ 0:12| 0:12/ 0:12| 19.779x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 14] *
112 [ 79] %*
128 [ 270] %****
160 [4239] %%%%%%%%%%%%%%%%%%%%%***********************************************
192 [3703] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*****************************
224 [ 775] %%%%%%%******
256 [ 581] %%%%%%%***
320 [ 122] %%
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
183.5 42.0 58.0 78.3 13.2 8.5
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\Testdir>lame -V 3 --vbr-new 10.wav 10.mp3
LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 17960 Hz - 18494 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=3) j-stereo MPEG-1 Layer III (ca. 8.2x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9784/9784 (100%)| 0:13/ 0:13| 0:13/ 0:13| 19.565x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 15] *
112 [ 79] %*
128 [ 267] %****
160 [4250] %%%%%%%%%%%%%%%%%%%%%***********************************************
192 [3691] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*****************************
224 [ 772] %%%%%%%******
256 [ 588] %%%%%%%***
320 [ 121] %%
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
183.5 42.0 58.0 78.3 13.2 8.5
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\Testdir>

The encode at the top is using the Rarewares version (MSVC8/ICL9.1), and the one at the bottom is compiled with MSVC6 and ICL4.5. The differences are of a similar order to those shown at the top of this thread. I'm fairly certain that Mitiok's compile will have been produced using ICL4.5. I moved from using ICL4.5 to 9.1 with the latest releases following the suggestion from the lame-devs that it did not seem sensible to continue to use obsolete compilers. The more recent compiler also creates a larger executable.

To my knowledge, no one has yet been able to differentiate, via abx or audibly, output from any versions of the encoder compiled with different compilers.

This post has been edited by db1989: Sep 8 2011, 15:38

Reason for edit: code→codebox

[db1989]

Out of interest, what is the "reference" version, if such a thing exists; is it the one on your Rarewares MP3 page?

[john33]

Out of interest, what is the "reference" version, if such a thing exists; is it the one on your Rarewares MP3 page?

A fair question, but I don't have the answer!!

[kwanbis]

This is normal. Different compilers and settings produce different output on some FP code, so you get slightly different output. Quality should be the same though unless something is broke.

Why should be normal? And why should the quality be the same, if say, compile1 uses 30 192 kbps frames, and compile2 uses 10?

[kjoonlee]

Because it happens all the time with floating-point calculations and nobody is complaining, usually?

Look at the real results. 3703 vs. 3691 192kbps frames.

[Gabriel]

Look at the real results. 3703 vs. 3691 192kbps frames.

Remember that because fo the bit reservoir, using a 192kbps frame does not mean that you are using the full space of such a frame. It's a matter of combination between the current bit allocation and previous bit allocations.
You can try comparing decoded samples from both versions, it's quite likely that there will not be that many different samples.

Why should be normal?

It's because of different floating point calculations reordering dony by compilers, which are producing slightly different results. Floating point only has a limited precision, and there is often some approximations in the result compared to the theorical formal result.
You could also try disabling some vectorial computations , it's likely that the result will also differ (--noasm mmx/3dnow/sse)

[kwanbis]

It's because of different floating point calculations reordering dony by compilers, which are producing slightly different results. Floating point only has a limited precision, and there is often some approximations in the result compared to the theorical formal result.
You could also try disabling some vectorial computations , it's likely that the result will also differ (--noasm mmx/3dnow/sse)

The question then, is, with what compiler options are the LAME devs using. I don't think i can hear any diference, but just to be safe. Or shouldn't we worry?

[saratoga]

This is normal. Different compilers and settings produce different output on some FP code, so you get slightly different output. Quality should be the same though unless something is broke.

Why should be normal?

Because floating point is only approximate within certain limits imposed by IEEE754, and beyond that different compilers are free to give different results. If you need exact results, use integer.

[Gabriel]

The question then, is, with what compiler options are the LAME devs using. I don't think i can hear any diference, but just to be safe. Or shouldn't we worry?

You should not worry, as the differences are very small (unless something is broken, but then it's a different matter)