What would you say is the oldest version of LAME that is still suitable for encoding music in CBR mode at 192 kbps?
Why it has to be oldest?
I wouldn't go older than 3.96 or 3.97 (which was, as I read, just had re-added mp2 decoding).
Every version is suitable, what's this question about?
The latest version 3.100.1 ;
CBR
-b192 -f
--preset cbr cd -f
Very fast and -f will often improve tonality issues . You can go further and resample to 48k to improve pre echo.
Just curious.
Before VBR encoding became popular, what was the most popular version of LAME used for encoding music in CBR mode at 128/160/192 kbps?
Does anyone remember?
Was there a go-to version that was considered the best?
it was up to v 3.93. From 3.90 - 3.93 you could have 2 psymodels. --preset used nyspytune and -b xxx used the older
GYPSYCHO model. JohnV said nyspytune was more suited to vbr (kind of makes sense).
From v 3.94 onward GYPSYCHO was removed and only nyspytune (--preset system) is used for all modes (--preset, --abr, -b and -V) .
So v 3.93.1 was the last version with the deprecated GYPSYCHO using -b 192 , While you could also use --preset cbr 192 that used NSPYTUNE .
It was said that the older model was better at times with pre echo but worst in other aspects..
Also the last version of GOGO encoder is based on lame 3.88 and so uses GYPSYCHO .
That said, @ 192 cbr its expected that you will get excellent results no matter which way you go. At least for not very difficult
samples.
Just curious.
Before VBR encoding became popular, what was the most popular version of LAME used for encoding music in CBR mode at 128/160/192 kbps?
Does anyone remember?
Was there a go-to version that was considered the best?
Versions 3.90 to 3.93.1. The scene then was a mix of new vbr enthusiasts and old CBR diehards.
I have these older versions precompiled:
lame-3.90.2
lame-3.90.3
lame-3.93.1
lame-3.95.1
lame-3.96
lame-3.96.1
lame-3.97
lame-3.99
lame-3.99.5
and the source for many others, if required. ;)
Just curious.
Before VBR encoding became popular, what was the most popular version of LAME used for encoding music in CBR mode at 128/160/192 kbps?
Does anyone remember?
Was there a go-to version that was considered the best?
As far as I know it was in continuous development-improvement. "Quality" depends on the program content and the lister's ability to hear compression artifacts so there is no "white line" where it becomes good-enough, or transparent, etc.
I had heard some poor-quality MP3s and I had a bad impression of it, but by the time I started using it, it was good enough for me (and I just chose a "high quality" setting and I never bothered with ABX tests).
Here's the LAME change log (https://svn.code.sf.net/p/lame/svn/trunk/lame/doc/html/history.html). Of course, not all revisions/updates are related to sound quality.
The latest version 3.100.1 ;
CBR
-b192 -f
--preset cbr cd -f
Very fast and -f will often improve tonality issues . You can go further and resample to 48k to improve pre echo.
You have done lots of testing with MP3.
I am curious what are your preferred encoders (LAME/Helix/Fraunhofer and their versions) and parameters for:
VBR 256
VBR 192
CBR 192
CBR 128
I am simple guy. I always use John's latest compiles with -b xxx and -V x.
I have these older versions precompiled:
Is 3.93.1 on ReallyRareWares (EXE date 07.12.2003.) latest compile that you have or you have something newer?
Is 3.93.1 on ReallyRareWares (EXE date 07.12.2003.) latest compile that you have or you have something newer?
I'll see if I can compile with a more recent compiler. I'll let you know on here. :)
Why 192 CBR?
Is 3.93.1 on ReallyRareWares (EXE date 07.12.2003.) latest compile that you have or you have something newer?
Here is an ICL19.0 compile for win32 - xp compatible:
https://www.rarewares.org/files/mp3/lame-3.93.1-win32.zip (https://www.rarewares.org/files/mp3/lame-3.93.1-win32.zip)
Before VBR encoding became popular
VBR was popular at least since around the year 2000, when the --r3mix preset was introduced.
And even more after mid 2001, when the founder of this forum, Dibrom, intruduced his --dm-preset scheme which mutated into the -V quality settings.
Just out of curiosity i compiled the 3.93.1 source code with a current GCC by myself.
After encoding i discovered that the result differs by a fair amount from John's executable. But in a way i would
not have expected between ICL andf GCC compiles. It not only differs in slight variations of the frame distribution
but also in the resulting bitrate and LR/MS ratio. Current LAME versions do not show such a behaviour.
Altering of optimization flags (CFLAGS) in GCC did not change the result (e.g. omiting the use of -ffast-math).
Next, i encoded with a executable from 2003/05 i found in my collection (origin unknown, probably also from John).
Weird! This differs to the others by a fair amount as well.
The questions are - which is "correct" and why do they vary that much?
Does anyone have an idea?
For a better understanding - the encoding screenshots attached.
#1 Version of 2003
#2 ICL 19 version of John
#3 GCC 13.1 version by myself
Interesting. I did a couple of test encodes myself, just using a basic "-V 1" and the result using the older encoder was approx. 10% higher bitrate. Having said that, I can't discern any audible difference in the resulting mp3s but I've always made a point of NOT listening for artefacts. ;) If memory serves me, the older compile would have likely been ICL 4.5. I'm not surprised that there would be differences as a result of using different compilers - that was always the case and I don't think anyone ever managed to ABX differences - but the difference using ICL 19.0 is larger than I would have expected.
Isn't the newer intel compiler using Clang? Clang uses flags like -fallow-store-data-races by default while GCC
sets this particullar flag only for -Ofast. So most likely many differences exist.
Compilers these days do many things.
The "Intel 2023" compiler is a LLVM/Clang variant, but 19.0 and 19.2 are the more recent versions of the "Classic" compiler.
Thanks, i am not very familar with the intel versions.
Interesting. I did a couple of test encodes myself, just using a basic "-V 1" and the result using the older encoder was approx. 10% higher bitrate. Having said that, I can't discern any audible difference in the resulting mp3s but I've always made a point of NOT listening for artefacts. ;) If memory serves me, the older compile would have likely been ICL 4.5. I'm not surprised that there would be differences as a result of using different compilers - that was always the case and I don't think anyone ever managed to ABX differences - but the difference using ICL 19.0 is larger than I would have expected.
Thanks John. I'm aware of the variations different compilers produce. To my exprience with current LAME versions this is limited
to slight frame distribution differences only. But not to that extend - as you also noted. That's why i turned off the ffast-math switch,
which weakens exact math rules/specifications, for testing purposes. This did not change anything. Using only SSE2 functions was
ineffective as well.
So i suspect math-is-math, whatever compiler is used, and therefore the various optimization switches/instruction sets should not
alter the calculations of mp3 encoding models in such a way i discovered.
Please correct me if this an incorrect assumption!
I've found in my archives the original download of LAME 3.93.1 from 2002, I think it was from mp3dev.org site, if anyone is interested.
With everything inside the archive, lame_enc.dll, lameACM.*, HTML help and BAT+VBS script encoders.
EDIT:
From the "About" file:
This file was downloaded from
http://mitiok.cjb.net/
mirrors:
http://mitiok.ma.cx/
Compiled with icl 4.5 & nasm
Please do not delete this file.
exe & dll were compressed with
UPX executable packer
http://upx.sourceforge.net/
Thank you Brazil2. This is quite useful.
The results of further testing:
"Original" version (ICL 4.5) and my builds (from GCC 5.5 to 13.2) all yield the same bitrate (--r3mix used),
identical LR/MS ratio and only slight deviations in the frame rate distribution (only a few). The ICL19 version
shows a completely different behaviour. It seems that the ICL19 does things differently compared to its
elder brother and to GCC.
Attached the encoding log:
#1 "Original" version (ICL 4.5)
#2 ICL19 version
#3 GCC 13.1 version
Just to throw another spanner in the works, a compile using Visual C from VS2015 generates output mp3s that are identical to the Intel compiles!! Neither of these compiles use anything other than most basic speed optimisations. I agree with your earlier comments, but cannot really shed any great new spark of light on this!!
So i suspect math-is-math, whatever compiler is used, and therefore the various optimization switches/instruction sets should not
alter the calculations of mp3 encoding models in such a way i discovered.
Please correct me if this an incorrect assumption!
Your assumption is incorrect. Compilers are actually pretty bad at doing floating-point math consistently. The "fast math" optimizations are ones that decrease precision, but it's a bit more difficult to turn off optimizations that
increase precision.
If you tell the compiler to use SSE(2) instead of x87 for floating-point math, there will be less additional precision, and results should be more consistent between compilers.
LAME has some ancient 32 bit ASM as well as some slightly less ancient SSE2 intrinsics (in addition to plain c), so depending on what you are compiling for you may be hitting different code paths.
FWIW it would be nice to go through and modernize at least the SSE2 intrinsics to use AVX.
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.
Uneducated questions coming up - with no claims to audible differences:
If you repack these mp3s using Mp3packer (https://wiki.hydrogenaud.io/index.php/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.
@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 (https://www.rarewares.org/files/mp3/lame-3.93.1-win32.zip)
@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.
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.
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.