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: Lame 3.99.5 -b320 -q0 (Read 6780 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame 3.99.5 -b320 -q0

Greetings!

Can anyone suggest a rational explanation why there's a considerable packed (with same Winrar version) file size difference between the same track encoded with the same Lame 3.99.5 ("regular"/rarewares' build for Win) with -q0 and -q1 switches (CBR 320 kbps)? As I figured out from LAME Q Switch topic and Detailed command line switches description the only difference between these noise shaping & psycho acoustic algorithm presets is "full outer loop search" being used in -q0 (that's supposed to give equal or better quality for the same bitrate) and dropped in -q1.

I.e.:
  • Unpacked mp3 file size (bytes) =  20 724 938
  • Packed mp3:
    • Lame 3.99.5 -q0 =  20 246 666
    • Lame 3.99.5 -q1 =  20 604 920
    • Lame 3.99.5 -q2 =  20 417 417
    • Lame 3.99.5 -q3 =  20 664 618
       
    • Lame 3.98.4 -q0 =  20 451 824
    • Lame 3.98.4 -q1 =  20 451 824
    • Lame 3.98.4 -q2 =  20 181 750
    • Lame 3.98.4 -q3 =  20 614 887
Same tracks encoded with Lame 3.98.4 with -q0 and -q1 switches give very close (sometimes completely identical) audio spectrums while in Lame 3.99.5 case -q0 gives noticeably "poor" visual in 16-20 kHz frequencies' range (similar to the difference between Joint mode and forced L/R/Simple Stereo mode). Ofc it's not essentially a sign for being better or worse quality-wise (the difference is probably completely unaudible), maybe -q0 algorithm just more favors towards sub-16 kHz (usually more audible/important) range and doesn't sacrifice bitrate from it for high frequencies' transparency than -q1.
I'm just confused about this file size difference between Lame versions (builds' history/"what's new" log doesn't say anything about CBR algorithm changes between 3.98.4 --> 3.99.5). Maybe it's "safer" to stick to -q1 (it's closer to default -q3) for Lame 3.99.5 or even get back to Lame 3.98.4 with -q0?

Lame 3.99.5 -b320 -q0

Reply #1 –
The final stage of mp3 encoding is lossless compression. This lossless compression is not state-of-the-art relative to something like Winrar, so it is generally possible to suck a few extra bytes out by further compression. The amount of improvement should be fairly random and not at all related to audio quality.

Lame 3.99.5 -b320 -q0

Reply #2 –
As pdq pointed out, even the slowest lossless compression settings in lame are not all that powerful relative to something like rar or lzma, so you'll generally get some further compression.  How much depends on how hard the compressor tries to pack the already packed bitstream and is fairly random in my experience.  I wouldn't read too much into it.

Lame 3.99.5 -b320 -q0

Reply #3 –
Thanks for swift response

It's a CBR issue here which means despite of obvious room for randomness and how hard this internal mp3 compressor succeeds/fails to pack audio data at the final stage of mp3 encoding - the result file size is always the same. Which means the more work external compressor finds for himself afterwards (less chaotic/more predictable patterns) - the less bitrate was used for actual audio data (like null samples used in CBR track upscaled from lower bitrate). Which is not a good sign, as I understand. Tried packing several tracks encoded with Lame 3.99.5 from several genres with all compressions methods of Winrar5/7-Zip - the results are the same: -q0 packed file size is always ~99,1% of -q1.
What could possibly have changed between the version upgrades, could it be some flaw in this "full outer loop search" implementation in Lame 3.99.5? Maybe, dunno, it's still experimental/not quite tested/stable and is not actually one of those "can possibly save bitrate/improve quality but definitely can't harm" routines?
At the same time Lame 3.98.4 keeps producing very close, almost identical packed (with and external compressor afterwards) file sizes for -q0 and -q1. Maybe "full outer loop search" routine wasn't actually yet enabled back then in Lame 3.98.4? But afaik it was already there in the source code and there doesn't seem to be any changes in -q number "hierarchy" of scalefactors and enabled/disabled noise shaping settings...

And it's not only file sizes, Lame 3.99.5 -q1 (vs. -q0) tracks' audio spectrums look more "favorable" (closer to lossless source) in 16-20 kHz range. But then again -q3 looks even more favorable (itunes' M4A/AAC 256 kbps VBR "mimic" lossless audio spectrums, in terms of gradient smoothness, even better) - so it's probably not quite a reliable sign to theorize about actual quality..

Lame 3.99.5 -b320 -q0

Reply #4 –
Quote from: Naphemil on
It's a CBR issue here which means despite of obvious room for randomness and how hard this internal mp3 compressor succeeds/fails to pack audio data at the final stage of mp3 encoding - the result file size is always the same. Which means the more work external compressor finds for himself afterwards (less chaotic/more predictable patterns) - the less bitrate was used for actual audio data (like null samples used in CBR track upscaled from lower bitrate).


At 320 CBR you generally have more available bitrate then data to pack, so this isn't really a big deal.   

Quote from: Naphemil on
What could possibly have changed between the version upgrades


Looking at the logs, quite a lot was changed.

Quote from: Naphemil on
Maybe "full outer loop search" routine wasn't actually yet enabled back then in Lame 3.98.4?


Yes, I don't think that was enabled until more recently. 

Quote from: Naphemil on
And it's not only file sizes, Lame 3.99.5 -q1 (vs. -q0) tracks' audio spectrums look more "favorable" (closer to lossless source) in 16-20 kHz range.


I think this probably means as little as the compression differences.

Lame 3.99.5 -b320 -q0

Reply #5 –
As far as spectral information in the 16-20 kHz range, the only valid relation to quality is that by retaining too much information in this inaudible range, you decrease the number of bits available for lower frequencies, possibly resulting in decreased overall quality.

I have never used the -q0 switch since it slows down compression and does not guarantee any improvement in quality. In fact, there was a time when it actually worsened quality. I have always preferred to use the default quality value since that has received almost all of the testing and is much less likely to be buggy.

I'm sorry that you are not satisfied with my very simple explanation of why your concerns over compressability are misplaced. There is a much more convincing argument, but it is very involved and I don't have the time to put it into words, so you can take my word for it, or not...

Lame 3.99.5 -b320 -q0

Reply #6 –
No-no, thanks a lot for your time, pdq and saratoga  I perfectly understand it's a bit too much to write walls of texts for some casual guy about an issue that is hardly can be known for sure and with such a negligible quality impact.
If there were examples of -q0 producing actually worse results than default settings, if it is possible that this "loop search" wasn't yet working in Lame 3.98.4 then I guess the suggestion to play it safe and stick to default settings (as they are the most optimal/tested ones) is wise.
 

Lame 3.99.5 -b320 -q0

Reply #7 –
AFAIK the bug with -q0 was fixed long before version 3.98, but my concern of lack of testing remains.