Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Oldest version of LAME suitable for 192 CBR encoding? (Read 4667 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Oldest version of LAME suitable for 192 CBR encoding?

Reply #25 –
For me, the most interesting question in this context is, which version creates the "correct" file.
In the end I don't care if it is MSVC, ICL or GCC. This topic seems to be a tricky one. That's why i
did further research. I do not have a working MSVC or ICL environment, so this is limited to GCC only.

Some findings in chronological order:
  • every GCC version from 5.5 to 13.1 creates almost identical files
  • switching off -ffast-math changes very little (file size by 3 bytes, frame rate distribution in some bands by very few frames <0.1%).
    So this negligible. The optimization flags of the source code (makefile.unix) include -ffast-math by default!
  • using floating-point arithmetic -mfpmath=387 does not change anything, so further investigation is discarded
  • SSE2 only or AVX(128) enabled binaries create bit identical output files
    @saratoga: a LAME binary compiled with adjusted CFLAGS already makes quite heavy use of AVX instructions albeit
    the speed increase compared to SSE2 isn't that huge. Some standard flags of the old source code do not make sense
    or even do not exist anymore in current compiler versions

All this did not shed any further light on the matter, so I took a closer look at the mp3 files encoded with ICL vs. GCC.
I suspect I have discovered a possible reason for the differences. According to a bitstream analysis of mp3guessenc,
the ICL version did not use the "nspsytune" model by default whereas GCC does. The reason for this is unknown to me.
That may be another story ;) . The source code i use is from https://sourceforge.net/projects/lame/files/lame/ - unmodified,
except of the CFLAGS.

Probably that's it! A file encoded with ICL and the additional --nspsytune switch gives the expected result with much less
difference to the GCC files. The accuracy of floating point math apparently played only a minor role in this case.

Re: Oldest version of LAME suitable for 192 CBR encoding?

Reply #26 –
Uneducated questions coming up - with no claims to audible differences:

If you repack these mp3s using Mp3packer with the super-squeeze VBR option, do the size differences / frame rate differences increase or diminish (/vanish)? If the differences change at all by repacking all files, that would mean the "lossless part" of the encoding differs.

Also, if you use e.g. foobar2000's bitcompare functionality, what then? You might get an indication whether differences before that stage are just on par with roundoffs.

Re: Oldest version of LAME suitable for 192 CBR encoding?

Reply #27 –
@145dBSPL I have recompiled reverting to the same source that you used and both the VS2015 and ICL 19.0 compiles appear to generate mp3s of the same size and characteristics as the old ICL 4.5 compile. I can only conclude that the source that I first used, above, must have been modified in some way that I don't recall!! Apologies if I have wasted your valuable time. ;) Below is the VS2015 recompile (on the same link as before) as it seems to be somewhat faster than the ICL versions! This one is not XP compatible.

https://www.rarewares.org/files/mp3/lame-3.93.1-win32.zip

Re: Oldest version of LAME suitable for 192 CBR encoding?

Reply #28 –
Quote from: 145dBSPL on
@saratoga: a LAME binary compiled with adjusted CFLAGS already makes quite heavy use of AVX instructions albeit
the speed increase compared to SSE2 isn't that huge.

The compiler can generate AVX instructions, but this is really slow so it isn't ideal compared to updating the intrinsics to use AVX.

Re: Oldest version of LAME suitable for 192 CBR encoding?

Reply #30 –
Quote from: bennetng on
Could be off topic for "old" encoders but tmkk's implementation of the current LAME encoder seems to be quite consistent with the the normal ones, and very fast.
https://hydrogenaud.io/index.php/topic,114777.msg946510.html#msg946510
Read the posts before my post for more info.

Interesting version. Definitely faster.
On i5 8400 I'm getting x77 on standard version and x99 realtime on this "fast" version using V1 preset.
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)