LAME Compiles

Topic: LAME Compiles (Read 3669 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

LAME Compiles

2003-04-02 13:30:23

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.

LAME Compiles

Reply #1 – 2003-04-02 13:41:01

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...

LAME Compiles

Reply #2 – 2003-04-02 14:22:22

Slow? You said it, tallness.

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

LAME Compiles

Reply #3 – 2003-04-02 14:57:52

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

LAME Compiles

Reply #4 – 2003-04-02 15:23:55

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

LAME Compiles

Reply #5 – 2003-04-02 15:36:59

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

LAME Compiles

Reply #6 – 2003-04-02 15:39:02

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?

LAME Compiles

Reply #7 – 2003-04-02 15:52:33

[span style='font-size:13pt;line-height:100%']List of Win32 LAME compiles[/span]

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

LAME Compiles

Reply #8 – 2003-04-02 16:19:59

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.

LAME Compiles

Reply #9 – 2003-04-02 16:39:46

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: [Select]

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

LAME Compiles

Reply #10 – 2003-04-02 16:47:47

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?

Immo

Notice