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 4664 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 #1 –
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).
Error 404; signature server not available.

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

Reply #2 –
Every version is suitable, what's this question about?
Opus VBR 256 + SoX

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

Reply #3 –
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.



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

Reply #4 –
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?

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

Reply #5 –
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.

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

Reply #6 –
Quote from: ClearSky on
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.

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

Reply #7 –
I have these older versions precompiled:
Code: [Select]
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. ;)

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

Reply #8 –
Quote
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.    Of course, not all revisions/updates are related to sound quality.

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

Reply #9 –
Quote from: shadowking on
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.

Quote from: john33 on
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?
gold plated toslink fan

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

Reply #10 –
Quote from: Markuza97 on
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. :)

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

Reply #11 –
Why 192 CBR?

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

Reply #12 –
Quote from: Markuza97 on
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

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

Reply #13 –
Quote from: ClearSky on
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.

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

Reply #14 –
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

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

Reply #15 –
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.

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

Reply #16 –
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.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

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

Reply #17 –
The "Intel 2023" compiler is a LLVM/Clang variant, but 19.0 and 19.2 are the more recent versions of the "Classic" compiler.

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

Reply #18 –
Thanks, i am not very familar with the intel versions.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

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

Reply #19 –
Quote from: john33 on
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!

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

Reply #20 –
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:
Code: [Select]
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/

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

Reply #21 –
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

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

Reply #22 –
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!!

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

Reply #23 –
Quote from: 145dBSPL on
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.

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

Reply #24 –
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.