flac dev - Jun 2014 - R128gain & metaflac

On Wed, 18 Jun 2014 16:39:12 -0700
"Timothy B. Terriberry" <tterribe at xiph.org> wrote:
>Ian Nartowicz wrote:
>> The Opus replaygain spec is fundamentally broken, so let's ignore
that for
>> now.  It is discussed ad nauseam elsewhere, but isn't going to
change any
>> time soon.
>
>I haven't seen anyone make any concrete proposals for how it should 
>change. Maybe I missed something.
>
>AFAIK, the only objection to it is that there is no way to distinguish 
>between whether the header gain is also an R128 album gain, or if it has 
>some other semantic meaning. That seems simple to address, not 
>"fundamentally broken".
>
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
unsuited for use in a music player without the sort of overly complex options
I've had to add.  Any half-decent music player allows the user to choose
whether they want album gain, track gain, or neither, and following the Opus
spec doesn't support this.

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.

--ian

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.

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).

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