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

[2Bdecided]

In most of this thread, the real problem is only just hinted at.

Don't worry about what replay gain is doing or what scale is doing - you're not losing anything at all here when using the calculated value to set --scale in lame. Also, don't worry about what happens at the very limit: --scale 0.0 isn't possible - it's silence, and it's infinite attentuation. --scale 0.0 is less than -50dB, less than -100dB, less than -200dB, - it's -infinity dB! As such, it's misleading and irelevant. Take -100dB as the limit case: perfectly possible without loss in 32-bit floating point calculations. So, no need to worry there.

We're left with two worries: what lame does, and what happens at the 16-bit output when decoded. OK, forget the second one of these - this is always an issue with Replay Gain, and was discussed before there was even any RG software available (thanks for the quote Hanky!).


So, we have one, and only one issue: what does lame do? IIRC It supposedly looks at the "loudness" of the signal, makes some assumptions from this, and enforces a sensible absolute threshold of hearing. This is most critical for quiet tracks - if it assumed that you will never turn up the volume to hear them, then most of the audio signal is way below hearing threshold, and can be discarded. This used to happen, but people often turn up the volume, and heard problems: so (again, IIRC) for a few years now, lame has taken this into account, and shifted the ath down for quieter tracks. There's a time constant involved, and it may not be a linear process - this is why changing the volume before encoding can change the output file size. If lame were adjusting everything immediately and linearly, scaling a file in the floating point domain would make no difference at all to the resulting filesize.

There are probably other factors at work here. What worries me slightly is that lame --aps has been tuned with tracks ripped from CDs. Not with tracks ripped from CDs and then dropped by 10dB. If you get a smaller file, then by ddefinition it has less information in it. Something has been lost. The question is what? and does it matter?


Maybe it's possible to tell lame that the file has been replay gained, and that you will be listening to this track at a particular loudness - that then fixes the ath. It would be interesting to do this, so fixing the ath at the "correct" value, to see what kind of bitrates this yields.

Replay gain originally targetted 83dB. This calibration assumes that a full scale sine wave will give 103dB SPL. Most of the current implementations target 89dB. This calibration assumes that a full scale sine wave will give 97dB SPL.

I bet that lame is guessing that a full scale sine wave would give about 85-90dB SPL for highly compressed tracks. What switches can people use to turn off lame's automatic ath adjustment, and to enforce it at a level which makes sense if a full scale sine wave = 97 dB SPL?

(I'm assuming that no one will listen louder than this, and that listening quieter than this will not break the psychoacoustics. Both these assumptions are false, but so are any assumptions that assume how loud people will listen - including the current automatic one in lame - so I'm hoping this doesn't cause any problems).


John - is Wavgain using 83 or 89dB target?

Lame experts - which switches can fix the ath where we want it?

Jebus - can you try whatever gets suggested with your test track and report back please?

Dibrom/other devs = if you're reading this, can you see any way in which this would break --aps or lame in general?

Cheers,
David.