LAME 3.96 Builds Differ In Size, Mitiok's build bigger than Rarewares |
  |
LAME 3.96 Builds Differ In Size, Mitiok's build bigger than Rarewares |
 Apr 15 2004, 00:08
Post
#1
|
|
|
Group: Members Posts: 352 Joined: 25-January 04 From: USA Member No.: 11500  |
I downloaded Mitiok's build of LAME 3.96 when it was released and the file size of the EXE is 197KB. I just downloaded the Rarewares compile and it is 186KB. Should I be concerned that there is a problem with one of these builds due to the file size difference?
|
 |
 
|
|
Apr 15 2004, 00:16
Post
#2
|
|
 Group: Members Posts: 599 Joined: 9-October 03 From: ZZ 9 Plural Z Alpha Member No.: 9230 |
Generally, there is no cause to be concerned. I think Mitiok and John33 used a different compiler or different compiler setting, hence the difference.
There might be a problem with any of the files, but this is not simply due to the exe sizes. I think (though I might be wrong) that these two lame.exes should give bit-identical mp3's (or at least the decompressed wav's should be bit-identical). Maybe someone with more knowledge will come to our aid 
This post has been edited by kalmark: Apr 15 2004, 00:17 -------------------- Life is Real...
(But not in audio :) ) |
|
|
|
|
Apr 15 2004, 00:23
Post
#3
|
|
 Group: Members Posts: 597 Joined: 15-February 04 From: Venezia, Italia Member No.: 12025 |
... I don't think so... just two different compiles. The one at Rarewares is made by John33 using ICL4.5, the one at Mitiok is made (I presume) by Dimitry Kutsanov using MSC. There is another floating around compiled by Gabriel Bouvigne and probably many others home brewed versions.
I think you can pick the one you love the best. They could also generate slightly different files due to different math libraries. At one point I used to think that Mitiok compiles could be considered as the "unoficial reference" ones, but I'm not sure about that anymore. Maybe a lame developer could shed some light on that... Sergio Edit: oops.. I'm a slow typer... kalmark got first! 
This post has been edited by smz: Apr 15 2004, 00:25 -------------------- Sergio
Revox B150 + (JBL 4301B | Sennheiser HD430) |
|
|
|
|
Apr 15 2004, 02:51
Post
#4
|
|
 Group: Members Posts: 72 Joined: 11-November 01 From: Hong Kong Member No.: 437 |
Does anyone know why John33 compiled lame.exe and lame_enc.dll with ICL 4.5 but lameACM.acm with ICL 7.1?
|
|
|
|
|
Apr 15 2004, 09:32
Post
#5
|
|
 xcLame and OggDropXPd Developer Group: Developer Posts: 3708 Joined: 30-September 01 From: Bracknell, UK Member No.: 111 |
QUOTE (jkml @ Apr 15 2004, 01:51 AM) Does anyone know why John33 compiled lame.exe and lame_enc.dll with ICL 4.5 but lameACM.acm with ICL 7.1? Because the ICL4.5 compiler does not produce a viable ACM compile. This is nothing to worry about as the 4.5 and 7.1 compiled encoders produce bit identical results, it's just that the 4.5 compiler generates slightly faster code. -------------------- John
---------------------------------------------------------------- My compiles and utilities are at http://www.rarewares.org/ |
|
|
|
|
Apr 15 2004, 11:22
Post
#6
|
|
|
Group: Members Posts: 11 Joined: 28-January 04 Member No.: 11583 |
QUOTE (john33 @ Apr 15 2004, 12:32 AM) Because the ICL4.5 compiler does not produce a viable ACM compile. This is nothing to worry about as the 4.5 and 7.1 compiled encoders produce bit identical results, it's just that the 4.5 compiler generates slightly faster code. I suppose you meant to say it generates the code slightly faster. Else, how could one of two bit identical codes be faster? greets Tz |
|
|
|
|
Apr 15 2004, 11:46
Post
#7
|
|
 Moderator Group: Members Posts: 1434 Joined: 26-November 02 Member No.: 3890 |
QUOTE (profichiller @ Apr 15 2004, 12:22 PM) QUOTE (john33 @ Apr 15 2004, 12:32 AM) Because the ICL4.5 compiler does not produce a viable ACM compile. This is nothing to worry about as the 4.5 and 7.1 compiled encoders produce bit identical results, it's just that the 4.5 compiler generates slightly faster code. I suppose you meant to say it generates the code slightly faster. Else, how could one of two bit identical codes be faster? greets Tz "the code is faster" = "the program build with compiler X needs less time for the same job then the same program build with compiler Y". The result is identical, i.e the mp3s encoded with both encoders are (should be) bit-identical. -------------------- Let's suppose that rain washes out a picnic. Who is feeling negative? The rain? Or YOU? What's causing the negative feeling? The rain or your reaction? - Anthony De Mello
|
|
|
|
|
Apr 15 2004, 12:04
Post
#8
|
|
|
xcLame and OggDropXPd Developer Group: Developer Posts: 3708 Joined: 30-September 01 From: Bracknell, UK Member No.: 111 |
I should probably have said "generates slightly faster executables".
-------------------- John
---------------------------------------------------------------- My compiles and utilities are at http://www.rarewares.org/ |
|
|
|
|
Apr 15 2004, 14:19
Post
#9
|
|
|
Group: Members Posts: 84 Joined: 1-December 02 Member No.: 3951 |
I have compiled 3.96 on Mac OS X yesterday. A "make test" shows me 7694 diffs from the testfile. Is this not a little bit to much? On Linux i got 400 diffs. But 7694 on Mac OS X....
BadHorsie |
|
|
|
|
Apr 15 2004, 19:25
Post
#10
|
|
 Group: Members Posts: 265 Joined: 15-December 03 Member No.: 10452 |
Having done some limited encoding with both builds using --preset standard, I found the output to be bit for bit identical, but John33's build to be about 9% faster on a P4.
|
|
|
|
|
Apr 15 2004, 20:36
Post
#11
|
|
 Group: Members (Donating) Posts: 799 Joined: 12-September 03 Member No.: 8821 |
Here, on AthlonXP, LAME from Mitiok's web-site is a bit faster, output is bit-identical.
EDIT: Oops, it's not bit-identical, but the differences seem to be in mp3 header only... This post has been edited by rutra80: Apr 15 2004, 20:49 |
|
|
|
|
|
Lo-Fi Version | Time is now: 22nd May 2013 - 03:27 |
