Opus and Replaygain peak tag.
Reply #4 – 2012-10-09 21:30:13
It's my impression from reading a number of questions on these forums as well as screen-grabs of fb2k setups that use of clipping prevention in players like fb2k is commonplace, more so than use of a limiter to maintain loudness. I can't point to a body of statistical evidence.
Perhaps a poll (worded plainly without any leading questions) would be a reasonable way of gathering evidence for or against my impression of real user behaviour, albeit in the odd world of Hydrogenaudio readers (from both pragmatic and idealistic ends of our spectrum), not the general public. If there is some demand for an implementation, and if anybody caves into that demand without a specification suggesting how, it's a recipe for potential fragmentation, which I think is a bad thing. I completely agree with you, NullC, that "Apply Gain but prevent clipping according to peak" is not the most sensible approach (not quite so bad on a per-album basis as per-track). However, the EBU PLOUD group, specifying R128 does specify True Peak programme value (on a sensible intersample basis) and I think this has potential merit from an engineering perspective to ensure there is sufficient headroom in both the digital and analogue domains. It could also be useful to suggest to users a suitable "Replay Gain pre-amp" type of setting that would keep their whole collection of music reasonably within the linear range of their analogue reconstruction device (DAC), but I'm sure this is a marginal, relatively pointless use case. In unfiltered output, Anyone applying digital EQ or other DSP will clearly break any peak value, and that's a very valid point well made. The oversampling approach at least gives a good idea for high fidelity uses (which wouldn't include decoding OPUS below 48kHz) and a little engineering margin (or gradual onset of distortion) would at least be possible, or the software could be forewarned about potential clipping. So, what's the best way forward? If we were to agree that there's enough demand to cause implementations including some kind of R128 PEAK statistics that might implement it differently or we simply wanted to foster a sensible approach to loudness normalization among developers, then I'd suggest that the Ogg Opus spec should make the case by stating something like: Storage of peak level metadata:- it is most sensible that target loudness be the primary aim of a playback loudness normalization system such as R128 (implemented by digital scaling or by a software-adjusted analogue volume control), and that use of a limiter, while it might not eliminate intersample overs and clipping distortion completely, is likely to mitigate clipping distortion while preserving the desired programme loudness. - allowing per-track PEAK values in metadata to over-ride target loudness is likely to cause annoying volume jumps between tracks, and the use of per-track or per-album PEAK values in this way can make some tracks or albums excessively quiet due to an unusually extreme peak value. In the event that EQ, filtering or DSP is performed, the peak values will no longer be valid. In addition, Opus decoders are not bit-accurate, so actual peak values may still exceed values stored in metadata. - we thus recommend that PEAK values be ignored or at most be used to select the most appropriate limiter parameters. - there may still be very limited use cases where PEAK values are useful. To prevent ad-hoc implementations from fragmenting machine-readable comment metadata, we recommend that R128 True Peak values (oversampled to 192kHz sampling rate) be stored in the following number format (e.g. specify same as Vorbis Comments Replaygain Peak values, whatever encoding that is) in a User Comment Field entitled R128_TRACK_PEAK or R128_ALBUM_PEAK as required. What do you think?