[flac-dev] R128gain & metaflac

[Ian Nartowicz]

On Wed, 18 Jun 2014 17:56:01 -0700
"Timothy B. Terriberry" <tterribe at xiph.org> wrote:

>Ian Nartowicz wrote:
>> It is certainly the biggest issue.  Sure it should be simple to address, but
>> nobody seems willing to do so.  The only response I've had so far is that the
>> output gain should *always* be applied, yet it *might* be an album gain.  It
>> can't be both and there is no way to tell which.  Sorry, but that makes it
>
>Well, make a proposal on the IETF list that addresses this (the FLAC 
>list probably isn't the right place for this discussion). So far the 
>only discussion there has been "I think this is broken but I don't know 
>what to do," and, "I don't think the IETF should be allowed to say what 
>goes in the tags of an Ogg Opus file."
>
>This could be as simple as just adding another tag which says whether or 
>not the header gain is an album gain.
>
I'd be entirely comfortable with an additional defined tag for an R128 album
gain, but doesn't it mostly defeat the point of the output gain field in the
first place?  Output gain would now, in most cases, be zero, and replaygain
would no longer be applied by default by all decoders.

>The issue the header gain was trying to solve is that something close to 
>half of all software that plays Vorbis completely ignores replaygain 
>tags. So if you tag a file you have literally no idea what volume a 
>player will play it back at compared to an untagged file.
>
>> The second issue is the lack of defined peak tags.  I could care less, but
>> some people care deeply and it is a relatively standard feature of music
>> players. The Opus spec doesn't define such tags, but it does explicitly say
>> not to use the REPLAYGAIN* tags.  Again that's just not viable.
>
>The only usage we could find of the peak tags in the wild was people 
>doing crazy things, like limiting the gain they applied so the peak 
>could not go above 1.0 (which makes the actual gain stored in the file 
>useless, and, like above, destroys the predictability about what volume 
>a file will be played back at, since very little software looks at these 
>tags at all). If you do any kind of resampling they're not reliable 
>anyway, so there did not seem to be any point to add them (and adding 
>them seemed actively harmful).

I'm certainly no huge fan of the peak scaling approach, not least for the
reason you describe of destroying the normalisation, but it is widely used,
widely supported, and a requested feature.  That is really the only end use for
peak tags, but it is quite common.  I think you are too harsh in describing the
playback volume as unpredictable. I'm not aware of any tool that plays back
with gain scaled down to avoid peak clipping without the user having control
over that, and virtually always it is off by default.  A common alternative in
many gain calculation tools is to reduce the gain tag if clipping is detected,
but that seems to me an even worse solution in destroying the normalisation
while giving the end user no choice. Possibly the biggest problem occurs when a
music player attempts to scale to avoid clipping without there being peak tags,
that is just nasty.  Again, if Opus doesn't offer support then people who want
it will just keep using the evil REPLAYGAIN* tags, and probably their
associated gain tags, and probably keep asking me to turn off the Opus gain.

--ian