Skip to main content
Topic: [TOS #8] From: WHY a particular LAME version (Read 1283 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[TOS #8] From: WHY a particular LAME version

I've compared different versions of LAME on their sound quality and their "lossless-recompression" filesize, for 320kbps 44100Hz MP3s (may be applicable on 48000Hz SR). I used versions of 3.90.3, 3.92, 3.93.1, 3.96.1, 3.98. And I used the commandline as below:
Versions of 3.90.3, 3.92, 3.93.1: "-b 320 -h -m j -q 2 --noath -k";
Versions of 3.96.1: "-b 320 -h -m j -q 0 --noath -k";
Versions of 3.98, for the command "--noath" and "-k" is already obsolete, as the LAME 3.97 does, and the lowpass filter is forced open and set to the highest value of 20627Hz for 44100Hz SR or 20903Hz for 48000Hz SR, so I can only set the parameter to "-b 320 -h -m j -q 0 --lowpass 25" to make a compromise.

P.S. To use "--noath" is better if you encode a piece of a wide range of audio level, "--noath" does help you to preserve more detail when the level is rather low, but I haven't made tests to see whether it does on 24bit audio (below -96dB).


After having encoded with different encoders, I use the "mp3packer" tool (-b 0 -t -s -z -a "-vbr") to losslessly recompress the MP3, to see how much space is saved -- as compressing the WAVs into FLAC, APE, or so. The more space is saved from the original 320kbps CBR MP3, the worse quality this MP3 has -- I believe that the more real space used by a lossily-compressed audio, the better quality the audio has.

I made sure there's not so many empty positions to make disguise, because it may influence the output filesize. And it's sure the "recompressed" MP3 by "mp3packer" is bit-compared identical to the 320kbps CBR ones.

Results:

LAME 3.90.3 - umcompressed 320K, 9,902,497 B, & 9,834,496 B w/ NTFS compression - compressed, 313kbps, 9,686,616 B, & 9,682,944 B w/ NTFS compression
LAME 3.92    - umcompressed 320K, 9,902,497 B, & 9,834,496 B w/ NTFS compression - compressed, 313kbps, 9,686,339 B, & 9,682,944 B w/ NTFS compression
LAME 3.93.1 - umcompressed 320K, 9,902,497 B, & 9,830,400 B w/ NTFS compression - compressed, 310kbps, 9,603,880 B, & 9,601,024 B w/ NTFS compression
LAME 3.96.1 - umcompressed 320K, 9,902,497 B, & 9,830,400 B w/ NTFS compression - compressed, 316kbps, 9,791,133 B, & 9,785,344 B w/ NTFS compression
LAME 3.98    - umcompressed 320K, 9,902,497 B, & 9,830,400 B w/ NTFS compression - compressed, 293kbps, 9,179,842 B, & 9,179,136 B w/ NTFS compression

See the difference? I didn't give up VBR V0 encoding until I found the audio quality of 320kbps CBR is much better than I use VBR V0. (with LAME 3.92, -h -m j --noath -q 2)

Personally, it's happy to see that LAME 3.96.1 still wons the 1st place, but it's a pity that the performance on high frequency (>15.6kHz) is so bad, and so does the LAME 3.98... So I finally choose LAME 3.92, because it is said to be a stable version, and it encodes much faster than LAME 3.96.1 -- 7.5X faster!!! But, of course, I'll take 3.90.3 into considerations sometimes.

Of course, at lower bitrates, newer version always stands beyond old ones. There's been a long time that I use LAME 3.97, beta 2, 3 and retail versions to encode 96kbps MP3s, and it does sounds much better than using LAME 3.93.1 -- the first version of LAME that I have ever used.

[TOS #8] From: WHY a particular LAME version

Reply #1
Quote
The more space is saved from the original 320kbps CBR MP3, the worse quality this MP3 has

Nonsense.  Please re-read TOS#8.

[TOS #8] From: WHY a particular LAME version

Reply #2
Quote
The more space is saved from the original 320kbps CBR MP3, the worse quality this MP3 has

Nonsense.  Please re-read TOS#8.

Oh well, I guess I still have to use ABX -- Always trust my own ears... Thanks after all for it...

 

[TOS #8] From: WHY a particular LAME version

Reply #3
Quote
So I finally choose LAME 3.92, because it is said to be a stable version, and it encodes much faster than LAME 3.96.1 -- 7.5X faster!!!

That's because LAME 3.96.1 treats "-b 320" as "--preset 320" (that is also equal to "--alt-preset 320" for 3.96.1). That's not the case for 3.92 so you should use "--alt-preset 320" for 3.90.3, 3.92 and 3.93.1. This will make them much slower.

So if you want to use 3.92 at 320kbps please stick with "--alt-preset 320" (without other switches).


Quote
-b 320 -h -m j -q 0 --noath -k

-h is the same as "-q 2" so you have two -q options in the command line. One of them is obviosly redundant.

 
SimplePortal 1.0.0 RC1 © 2008-2020