Wavegain vs. MP3Gain, Why the former might be better... Options

[Jebus]

Yes, I know that MP3Gain is lossless. No, I am not talking about how MP3Gain is limited to 1.5dB steps (though this is another reason).
What I am thinking is this:

Psychoacoustic models tend to encode louder signals with more bits, right? This is why remasters (compressed) tend to use higher bitrates than older versions. Correct?

If we are then encoding a VERY LOUD album with LAME -aps for instance, then normalizing it down say 10.5dB (for a really bad one), aren't we wasting bits? Wouldn't we be able to save some bits by normalizing it down to 89dB FIRST, then encoding it?

I know wavegain is NOT LOSSLESS, but I am (incorrectly) assuming that this is just a theoretical lossiness, not a perceptible one. If this is the case, couldn't we argue that wavegained tracks will be of lower bitrates while still maintaining transparency (the goal, afterall, of -aps)?


---------------------------------
| UPDATE (May 21st, 2005) |
---------------------------------

The discussion below basically concludes that running a wavegain analysis, then applying the recommended scalefactor to lame (via the --scale switch) will save bits due to high-frequency bloat inherent in the mp3 format. Lots of people have since chosen to use this method over mp3gain, and in fact it can be automated now from within EAC using Wack, or my own Omni Encoder. Read on!

This post has been edited by Jebus: Jul 18 2006, 14:05

[DickD]

Finally reached the end of this thread (to date), and glad to see that sfb21 has been found to be the culprit, as I'd been starting to suspect. I agree with 2Bdecided about how the sfb21 problem manifests itself. It's a common misperception that the extra bits are wasted as 16kHz+, when in fact they're wasted on <16 kHz content if certain things happen in the 16kHz+ content that requires the workaround to maintain quality.

This is my educated guess as to what's happening:

By chance, john33 picked a track where the sfb21 issue wasn't causing much bitrate bloat in normal APS (without the -Y), so it wasn't much higher in the version with no --scale applied.

Jebus picked an album where the sfb21 issue was causing bloat in APS at full volume, but wasn't at lower volume. As 2Bdecided said, there is no scalefactor for 16 kHz+ (sfb21) so the global scalefactor has to be used. If the scale required to get fine enough quantization in sfb21 doesn't match the existing global scalefactor, the workaround is to adjust the global scalefactor, which then causes more bits to be used to encode all the other spectral bands (sfb0 to sfb20). This forces all other bands to be quantized more finely than the masking threshold requires, so wastes bits in encoding detail in the <16 kHz area that is inaudible. (Encoders like Musepack and Vorbis don't have this sfb21 issue, so there's less difference - perhaps a fraction due to the way the adaptive ATH works).

It so happens that the --scale version doesn't need such a big change in the global scalefactor, so it doesn't get forced to waste bits on masked (inaudible) detail in bands 0-20 just to get the quantization noise in sfb21 low enough to go below the masking threshold.

Probably an analysis with mp3x graphical frame analyzer could help to verify whether this is true or not.

So, providing the psychoacoustics are correct about the masking threshold for <16 kHz components of the signal, the lower bitrate file should sound just as transparent as the high bitrate file that has been mp3gained (or had RG in Foobar2000 or similar).

So, if I'm correct, then only for cases where sfb21 bitrate bloat is happening, one should obtain just as good transparency with the smaller file (much closer to Musepack --standard --xlevel bitrates and APS - Y bitrates) when compared to the original lossless file with replaygain applied (even if played back on a 24-bit system, where the noise floor doesn't rise under ReplayGain, because LAME isn't forced to encode inaudible details just to get around the lack of sfb21 scalefactor.

Mind you, can this be right? If so, it implies that one could obtain just as low a bitrate without affecting the original volume by using, for example, --scale 0.5 to obtain -6.0 dB volume change in the encode step then applying a corrective mp3gain Constant Gain of +6.0 dB after encoding (or use anything else that edits the global gain, like mp3DirectCut) to restore the original volume.

If so, surely Lame APS would already use --scale accompanied with an opposite adjustment of the global gain value, like mp3gain, as a more efficient workaround for the sfb21 issue, and could apply it to individual frames of the MP3 where the bloat occurs.

The only exception is if it doesn't work for changes in 1.5 dB steps, but only happens to work for some values between the steps of the global gain, or that the times when it works can't be predicted by LAME (though LAME is well aware of when the bloat is occuring, because the -Y switch lets it ignore the +16 kHz content at those times instead of implementing the bloat-inducing workaround for the lack of sfb21 scalefactor).

In that case, perhaps some files would become MORE bloated when --scale is applied.

Hmm, I think we need a Lame VBR expert to help here.

Wouldn't it be awesome if full-bandwidth LAME APS could be 20-30 kbps smaller without sounding any less transparent or breaking the MP3 standard! I'm just suspecting there's something to stop it working like that, or it would have been done before.

This post has been edited by DickD: Jun 25 2003, 15:12