IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
LAME 3.97: different binaries produce differente results!, bizarre: different LAME 3.97 binaries produce differente results!
Adriano
post Oct 4 2006, 02:33
Post #1





Group: Members
Posts: 1
Joined: 4-October 06
Member No.: 35932



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
Go to the top of the page
+Quote Post
saratoga
post Oct 4 2006, 04:13
Post #2





Group: Members
Posts: 4922
Joined: 2-September 02
Member No.: 3264



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.
Go to the top of the page
+Quote Post
john33
post Oct 4 2006, 10:03
Post #3


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
db1989
post Oct 4 2006, 10:54
Post #4





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



Out of interest, what is the "reference" version, if such a thing exists; is it the one on your Rarewares MP3 page?
Go to the top of the page
+Quote Post
john33
post Oct 4 2006, 10:57
Post #5


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (dv1989 @ Oct 4 2006, 10:54) *
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!! blink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
kwanbis
post Oct 4 2006, 13:42
Post #6





Group: Developer (Donating)
Posts: 2362
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (Mike Giacomelli @ Oct 4 2006, 03:13) *
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?


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
kjoonlee
post Oct 4 2006, 14:03
Post #7





Group: Members
Posts: 2526
Joined: 25-July 02
From: South Korea
Member No.: 2782



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.


--------------------
http://blacksun.ivyro.net/vorbis/vorbisfaq.htm
Go to the top of the page
+Quote Post
Gabriel
post Oct 4 2006, 14:50
Post #8


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



QUOTE (kjoonlee @ Oct 4 2006, 15:03) *
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.

QUOTE
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)
Go to the top of the page
+Quote Post
kwanbis
post Oct 4 2006, 19:17
Post #9





Group: Developer (Donating)
Posts: 2362
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (Gabriel @ Oct 4 2006, 13:50) *
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?


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
saratoga
post Oct 4 2006, 20:56
Post #10





Group: Members
Posts: 4922
Joined: 2-September 02
Member No.: 3264



QUOTE (kwanbis @ Oct 4 2006, 05:42) *
QUOTE (Mike Giacomelli @ Oct 4 2006, 03:13) *

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.
Go to the top of the page
+Quote Post
Gabriel
post Oct 4 2006, 21:30
Post #11


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



QUOTE (kwanbis @ Oct 4 2006, 20:17) *
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)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th August 2014 - 14:27