Help - Search - Members - Calendar
Full Version: LAME Compiles
Hydrogenaudio Forums > Lossy Audio Compression > MP3 > MP3 - General
feces1223
Why is LAME making compiles that have worse and worse quality? It doesn't make sense they should've stopped at 3.92 and admitted that their compiles are about as good as possible from the format. 3.93 and 3.93.1 were awful quality when i tried them a while back and i hear 3.94 is trying to clean it up but still is incomparable to Dibrom's compile of 3.90.2. So my question is why are they going in bad directions why don't they just stop making compiles before they go down in history making major mistakes? *They have won many awards for earlier compiles and i'm beginning to think that they don't deserve it anymore with the way they are handling "upgrading" their compiles.
yourtallness
Hey man, I kinda agree with what u r sayin' but I think u should cut them some slack.
Trying to improve something may often result in poorer results, take Formula 1 as
an example: a team may set out to build a new and improved car for the new season,
and end up making a really slow one, before tuning it up to decent levels...
Immo
Slow? You said it, tallness. smile.gif

I was just thinking - why is LAME 3.93.1 so much slower than 3.91? After all, the first thing listed in the version description of 3.93.1 is "Many improvements in quality in speed."

It may well be that quality is improved in some way, I won't judge about that, but speed is really significantly worse.

If it wasn't for the slowness, the new --preset medium would be an excellent choice for me.

Maybe I've got the wrong compile?

Immo
Gabriel
I would be interested by a real report of 3.93.1 beeing of "awfull quality".

If speed decreased between 3.91 and 3.93.1, it means that you are using compiles produced by different compilers. 3.93.1 is really faster than 3.91
Immo
Gabriel: phew, it means it's just a question of a slow compile.

I downloaded my binary from mp3-tech.org. May I ask if anybody knows the location of another compile?

Thanks,

Immo
Gabriel
Binaries from mp3-tech are compiled with visual c++. They are slower than icl compiles, but you are sure that they will work on every computer (icl compiles sometimes have problems with Via processors)

You can download icl compiles from mitiok.free.fr
DigitalDictator
I'm just thinking here... perhaps the code itself has improved a bit since 3.91 (or 3.90.2) but the presets just haven't been tuned as thoroughly. So theoretically, you have the goods to come up with better presets than 3.91, it's just a matter of tweaking.

Furthermore, the plain cbr 128, 160, 192 etc. should sound a bit better with 3.93.1 than 3.91. Dibrom never super duper tweaked those modes as he did with the presets, right?
dev0
List of Win32 LAME compiles

HA.org/Dibrom
Version: 3.90.2
Compiler: ICL4.5
Additions: modified lame_enc.dll
Comment: HA approved version; best tested

Rarewares/John33
Version: 3.90.2, 3.91, 3.92, 3.94alphas
Compiler: ICL4.5/6
Additions: lame_enc.dll, modified lame.exe, lamedropXPd, ACM codec
Comment: clean 3.90.2 compile with Dibrom's options and ICL4.5, latest alphas, some interesting modifications of the original lame.exe

Mitiok
Version: 3.93.1
Compiler: ICL4.5
Additions: lame_enc.dll, ACM codec
Comment: Probably the most used LAME compile

MP3-Tech.org/Gabriel
Version: 3.93.1
Compiler: VC++ 6
Additions: RazorLAME
Comment: Clean VC++ compile of the latest stable lame version (ICL causes problems on some systems)

Other Packages
EasyLAME - Installer bundle of Dibrom's 3.90.2 and RazorLAME preconfigured for --alt-presets (similiar to MP3-tech package / point newbies there!)
winLAME - Vorbis/LAME frontend, which uses libvorbis.dll (1.0) and nLAME.dll (3.92), includes transcoding options with tag copying (use with care!) and libmad based decoding (great tool)
NotLame - collection of Linux compiles of LAME for various distributions
freshrpms - RedHat optimized RPMs of lame and other multimedia applications missing in the stock distribution
Immo
Thanks, Gabriel and dev0!

Surprisingly, the speed issue wasn't solved. I didn't yet compare the two different compiles of 3.93.1, but I did compare the Mitiok compile and the 3.91.

I encoded the same track with both versions, without any commandline parameters or switches, which means 128kbps cbr q2.

LAME 3.91:
01:37

LAME 3.93.1 Mitiok:
01:58

My machine is quite a historical one - Celeron 400@500MHz, Intel 440BX, but there's nothing abnormal with this configuration.

How is this to be explained?

Immo

EDIT: v3.91 compression time from 1:13 to 1:37. I found out that 3.93.1 uses -q 2 by default, whereas 3.91 uses -q 5.
dev0
I can't verify the difference in speed. There's a small difference in file size as there has always been between 3.93.1 and 3.90.2, but that's all.

CODE

LAME 3.90.2 (DIBROM)
D:\tobias\projects\audio\lame_versions>lame3.90.2-ICL\lame --alt-preset standard
test\slr.wav test\slr-3902-dibrom.mp3
LAME version 3.90.2 MMX  (http://www.mp3dev.org/)
-- Compiled at http://www.hydrogenaudio.org
-- Check this website for up to date information on the --alt-presets

CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding test\slr.wav to test\slr-3902-dibrom.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8105/8107  (100%)|    0:45/    0:45|    0:45/    0:45|   4.6899x|    0:00
32 [  96] %**
128 [  27] *
160 [ 467] %%%%********
192 [1497] %%%%%%%%%%%%%%***********************
224 [2732] %%%%%%%%%%%%%%%%%*************************************************
256 [2339] %%%%%%%%%%%%%%%%%%%%%%%%%%%******************************
320 [ 949] %%%%%%%%%%%%%%%%*******
average: 232.3 kbps   LR: 3128 (38.58%)   MS: 4979 (61.42%)

Writing LAME Tag...done

LAME 3.93.1 (MITIOK)
D:\tobias\projects\audio\lame_versions>lame-3.93.1\lame --alt-preset standard te
st\slr.wav test\slr-3931-mitiok.mp3
LAME version 3.93 MMX  (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass  filter, transition band: 18671 Hz - 19205 Hz
Encoding test\slr.wav to test\slr-3931-mitiok.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
   Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 8105/8107  (100%)|    0:46/    0:46|    0:46/    0:46|   4.5437x|    0:00
32 [  96] %**
128 [  42] *
160 [ 713] %%%%%%%**********
192 [1815] %%%%%%%%%%%%******************************
224 [2881] %%%%%%%%%%%%%%%%%%%***********************************************
256 [1948] %%%%%%%%%%%%%%%%%%%%%%%%%********************
320 [ 612] %%%%%%%%%%*****
average: 223.4 kbps   LR: 3062 (37.77%)   MS: 5045 (62.23%)

Writing LAME Tag...done
Immo
I found out that 3.93.1 uses -q 2 by default, whereas 3.91 uses -q 5.

With -q 2, the difference is still there: 1:58 vs 1:37

I'll try and compare 3.90 and 3.93.1.

Immo

EDIT: Tried 3.90 vs 3.93.1:

3.90
01:33 (even faster)

3.93.1
01:57 (average from 2 trials)

Maybe the difference shows on longer files?

Is it possible that older machines prefer older codecs? biggrin.gif

Immo
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.