Hello

In the last few days I was dealing with LAME v3.90.3, different compilers, different systems and so on. These are my results:

First of all, I have used the following 3 files for my work:

LAME v3.90.3modified, 'official' windows compile (using ICL 4.5?), obviously one of the most used binaries (compiled by dibrom?):
1) http://rarewares.soniccompression.com/file...0.3modified.zip

Its source code (modifications done by dibrom?):
2) http://rarewares.soniccompression.com/file...modifiedsrc.zip

The original source code, without those 'modifications':
3) http://rarewares.soniccompression.com/file...3-linux.tar.bz2


A short overview what it's all about: The 'official' binary from 1) is compiled with Intel's C Compiler, it generates different MP3 files using "alt-preset standard", than a binary compiled from 2) using MS VC 6.0 compiler or gcc. The difference looks like this:



As you can see in the above example the bitrates are different by using the SAME source code and settings (alt-preset standard, no additional switches!).

The MP3s encoded using the Intel binary are always ~3-4% larger, the bitrate arrangement however differs much more.

Of course the same wave file was used during all tests, (Beatles - Back In The U.S.S.R, 2min:42sec, ripped from an original CD).


I have tried to compile 2) with MSVC6, cygwin+gcc, linux+gcc, MacOSX+gcc and Intel C++ Compiler v8.0 (I don't have v4.5 yet):

Only ICC8 compiled a binary which encoded the file at 225.3 kbps.
ALL other compiles end up in a binary which encodes this wave at the SAME bitrate: 219.2 kbps!

The ICC8 compiled binary however still produced a different MP3 compared to the one encoded with 1) - its not byte-identical. I guess I need ICL v4.5 to achieve a 1:1 compile as in 1).


I also discovered: changing the MS VC 6.0 optimization flags (O1=size, O2=speed, O3=project default) would result in byte-different MP3 files - however the bitrate stays equal! Changing from "NASM" to "no ASM" didn't seem to have any impact on the encodes, just as changing the optimization in ICC8 from OPT=ULTRA to OPT=NORMAL.

It appears also, that binaries compiled with gcc and MSVC6 create again different encodes - however the bitrate stays identical!


Compiling the original LAME v3.90.3 source "not modified" as in 3) with MSVC6 and ICC8 leads to the same results, however with no "preset tag" in the header (which is what the modification is all about).


My conclusion:
As C source code usually should result in a deterministic binary... There must be either a problem with the Intel compiler and LAME v3.90.3, or a problem within the LAME v3.90.3 source code.

The higher bitrates might be a result of the Intel compiler behaving different and even "wrong" with some of the LAME source code, I would suspect the floating-point parts to be the criminal.

I assume LAME development is using mainly gcc for their work, thus I believe the resulted encodes achieved with Intel binary from 1) are "wrong" from their viewpoint.


In first place, I would like to know WHY Intel compiler behaves that much different.
Secondly, I would like to know, if the bitrate difference is hearable to any of the ultra-ears in here with their ultra-soundsystems (as I have none of those) :)


Some of my compiled binaries:
http://balder.prohosting.com/2lame/LAME.v3...VC6-O1-NASM.zip
http://balder.prohosting.com/2lame/LAME.v3...efault-NASM.zip
http://balder.prohosting.com/2lame/LAME.v3...efault-NASM.zip
(That free-hosting sucks, so try a couple of browsers if it doesn't work for you.)

It is not very hard to compile LAME v3.90.3, so I recommend you to compile it on your own and see for yourself, if you doubt about my results :)



Many thanks for reading and enlightening...

This is a well known issue from quite some time ago. However, the tuning for the alt-presets in 3.90.x were done (by me) using ICL. This was before it became well known that some of the ICL flags used (which I believe were introduced into the files by mitiok before I even started developing) were problematic. You can find discussions about this using the forum search.

If you want to use 3.90.3 (with the alt-presets) the way it was designed, you need to use the official ICL compiled builds.

The bitrate difference actually comes from some compiler flags which change the behavior of floating point calculations to a somewhat non-standard (though faster) method. As far as I know, these flags have been removed from the makefiles for the lame source for versions affter 3.90.3.

Thanks for the quick answer, Dibrom...

Sorry, I did search the forum before, and all I found was: http://www.hydrogenaudio.org/forums/index.php?showtopic=3022 - Correct me if I'm wrong please...


Well, what does this mean for MacOSX or Linux users? They of course can't use ICL, especially Mac systems. So the encodes done with "alt-preset standard" and non-ICL binaries are faulty? I would be surprised if they are still "good" ...


How is it possible anyway, that compiler optimization flags have such a big influence on the resulting encode, and yet it seem not to be documented anywhere.

The source code includes MSVC and unix project/make files, so I would assume these are the development and testing environments for this project, not ICL.

There were other threads too I believe, but I don't remember them since it was so long ago...



Short answer is that it means they are screwed. Well, at least Mac OS X users are. There is an ICL for Linux, but I have no idea what the output for it is like. But at any rate, OS X users are kind of screwed as it is since LAME is so very poorly optimized for that platform anyway... I recently looked into trying to remedy this, but because of the state of the codebase, I decided it was not worth the effort.. now I am working on mpc instead.

For what it's worth, I am a Mac user now myself. However, I gave up developing LAME a long time ago (and don't use it anymore anyway) and for anything related to quality, I doubt I will ever become involved again. Besides, 3.90.3 will quite soon be obsoleted by 3.97 (or so I gather), so it will be a non-issue at that point.

The non-ICL compiled versions of 3.90.3 aren't necessarily "faulty", but they aren't as well tested. The output isn't garbage, but on borderline problem cases, they may perform differently -- possibly better or possibly worse.



The compiler flags which change floating point behavior were clearly pointed out in the ICL docs when I last looked. The reason that they made their way into the LAME makefiles in the first place is because of the poorly organized and decentralized nature of it's development, and the fact that there was no strong regression testing at the time.

For what it's worth, it's not entirely uncommon for different compilers and different cpus to produce different results for floating point code, especially when using various optimization flags or when relying on clever hacks to improve speed (both of which LAME does). Of course, usually the results are nowhere near as different as in this particular case, but as I already said, the cause of the difference is known.



The development and "testing" environments for LAME pretty much boil down to whatever the coder working on the source at one particular point in time feels like using. Because of the lack of structure behind LAME development that I just pointed out, and the lack of strong regression testing, there was not a strong emphasis on making sure output was identical in all cases. FWIW, when I was working on the alt-presets, I was working pretty much on my own, and although I did my best to try and assure quality, there were some things that I wasn't able to cover. As a result, the scope of the problem with the compile flags fell through the cracks.

I believe things might have improved somewhat in this regard since, but I don't pay attention to LAME development anymore so I can't really say for sure.

Thank you for answering all my questions!

I might come back to this subject in a few days when I'm back, if I find any more detail questions.


So far, have a nice week-end and stuff :)

ah funny.. exact similar i found these days.. any ideas ? :

http://www.hydrogenaudio.org/forums/index....showtopic=34346

;-)