Improving ReplayGain, some ideas for Devs etc Options

[Xenno]

2B > The peak sample value tells you _exactly_ how much headroom the material has - usually none!

...and I am at a loss on how RG actually does this. If I take a 20 kHz sine wave (or whatever that will yield 2 sample points per cycle) and encode at 44.1 kHz, there is no guarantee that the sample points will fall on the amplitude maximums (unless phase locked). They could fall on the x-axis crossing nodes...or anywhere on the waveform up to the peaks. Given my example above, is RG actually reconstructing the wave to determine the peak value...or is it using the data in the file?

xen-uno

[SamK]

2B > The peak sample value tells you _exactly_ how much headroom the material has - usually none!

...and I am at a loss on how RG actually does this. If I take a 20 kHz sine wave (or whatever that will yield 2 sample points per cycle)

in fact 2+epsilon sample points are required by shannon theorem in the case of real valued samples, if you look at it closely enough.
(ie : notice that cos(Wt) = 0.5*(exp(iWt) + exp(-iWt)), and thus its bandwidth is not in [-W,+W[ )

and encode at 44.1 kHz, there is no guarantee that the sample points will fall on the amplitude maximums (unless phase locked). They could fall on the x-axis crossing nodes...or anywhere on the waveform up to the peaks.

on a long enough sequence of such a sine wave, some of the sample points will fall very close to maximums of the continuous wave.
By a quick estimation, 4000 samples are enough to insure that the discrete peak lies within 100/(4000^2) percents of the continuous wave's real peak for high frequencies up to 22.05/(1+1/4000) = 22.044 kHz.
(I'm using 1-x^2/2 as an estimate of the sine wave near the optimums)

Even with only 10 samples, you get 1% peak precision for high-frequency sines up to 20.04 kHz.
(i.e., from 2.2kHz to 20.04kHz. low frequencies are of no interest here, since they don't show much max difference between discrete and continuous signal)

Conclusion : for a sine wave, you don't really have to worry about the difference between the discrete peak and the underlying continuous peak.

Given my example above, is RG actually reconstructing the wave to determine the peak value...or is it using the data in the file?

my opinion is it doesn't matter, even slightly, though I only made my point with sine waves and not the general case of just any sampled sound.

This post has been edited by SamK: Jul 20 2004, 00:58

[SamK]

my opinion is it doesn't matter, even slightly, though  I only made my point with sine waves and not the general case of just any sampled sound.

on top of that, you can consider it's not really clipping as long as the digital signal is conserved.
Then, if the DAC chops of the true peaks of the analog signal due to that kind of issue, I'd say it's his fault.

[2Bdecided]

The RG peak value is the largest absolute value within the digital data.

I'm aware that the true reconstructed peak can be between sample values (and oversampling DACs will often clip this), but isn't the ReplayGain calculation slow enough already - without taking this into account?

It's worth remembering that the people who master squashed CDs don't take this into account either.


The reason I didn't worry about this with ReplayGain is because the highest reconstructed inter-sample value you can contrive is around 1.5x digital full scale. As ReplayGain drops most over-compressed tracks by 6-12dB, you've got more than enough headroom.

I suppose you could store an "analogue" peak value, and use this for clipping prevention. That's a nice project, if anyone wants it!

However, ReplayGain will keep most music away from clipping. If you don't use ReplayGain, simply dropping the gain by 3-6dB will keep everything away from clipping. What's more, the existing peak value is more than good enough in most cases, and leaving an extra fraction of a dB headroom will make it fine in all but contrived cases.

You've got to wonder: if someone puts a signal onto a CD where the analogue peak is at digital full scale plus 50%, maybe the intention is to make the DAC in your CD player clip? Is so, what's the point in de-clipping it?

Cheers,
David.

This post has been edited by 2Bdecided: Jul 20 2004, 13:08

[SamK]

The RG peak value is the largest absolute value within the digital data.

I'm aware that the true reconstructed peak can be between sample values (and oversampling DACs will often clip this)

Are there any DACs that can reconstruct the analog signal with full peak above full-scale ?
I guess DACs can behave very differently on such digital signals.

The reason I didn't worry about this with ReplayGain is because the highest reconstructed inter-sample value you can contrive is around 1.5x digital full scale.

Wow, 1.5x is much more than possible with sine waves..
can you tell how to make such a signal ?
or do you get this value from mathematically bounding the reconstructed signal formula ?

[SamK]

isn't the ReplayGain calculation slow enough already - without taking this into account?

it might be possible to take it into account without much more computations.
From the DCT transform, you can bound the analog peak by adding the moduli of the DCT coefficients.
I don't know how unprecise that can be on real music signals, but my guess is it shouldn't be too bad.

[2Bdecided]

Wow, 1.5x is much more than possible with sine waves..
can you tell how to make such a signal ?
or do you get this value from mathematically bounding the reconstructed signal formula ?

OK, it was 1.41, but it's possible with an 11.025kHz sine wave (44.1kHz sampling)...

http://www.hydrogenaudio.org/forums/index....ype=post&id=818

I'd imagine that's the maximum you can get from a sine wave, but if you drag samples around in Cool Edit you can get bigger peaks between samples. If you drag 2 more samples high in the above example, you can reach 1.78x digital full scale between samples (verified by resampling to 10x the sample rate and checking the middle sample value). The "true" peak will be slightly higher still. I'll leave you to figure out which two samples you have to drag up!

Cheers,
David.

[dev0]

CODE

replaygain_track_gain = -10.99 dB
replaygain_track_peak = 1.647949

Transcoded from a Musepack --standard encode to AoTuV b2 -q 0.

[2Bdecided]

That's different to the latest issue discussed in this thread, because that Peak value is based on actual samples, not inter-sample reconstructed peaks.

However, it illustrates Pio's earlier point very well!

Cheers,
David.

[Kuuenbu]

The peak sample value tells you _exactly_ how much headroom the material has - usually none!

I'm referring more to peak-to-average ratio here. Headroom is a rather vague term that could mean anything, so I probably shouldn't have used it.

If you want a pure RMS measurement, then measure the RMS. It's got little to do with judging or matching loudness, so it's not part of ReplayGain. Sorry!

Yes, but current methods of calculating RMS are rather cumbersome. You have to open up each individual file in a wave editor, run the analysis feature, write the RMS down, and do that over and over again for every track on an album. Plus the RMS scanners in wave editors don't have the "intelligent" calculation factors that ReplayGain uses; it simply averages all the samples in a selection (unless you specify the scanner to ignore everything under a certain level, which alreeady adds work that shouldn't be neccessary for the user). Adding a non-contour feature to ReplayGain would give people a quick and easy way to measure RMS values.

[danbee]

Almost everyone is using a reference level of 89dB, rather than the 83dB in the original ReplayGain proposal. Unless there are any objections, I'll change the official reference level to 89dB.

(It's a pity I didn't stick with the original idea of storing the ReplayGain level in the file e.g. 92dB instead of -3dB, because then the reference level wouldn't matter. Too confusing to change back now I think)

Could this be solved by storing the reference level in the file as well as the replaygain?

Edit: Didn't realise I was such a late comer to this thread!

This post has been edited by danbee: Oct 27 2004, 17:56

[jcoalson]

not a bad idea, e.g.

replaygain_reference_level=90dB

absence of the tag implies 89dB