Re: [codec] draft-ietf-codec-oggopus and "album" gain

[Ron <[e-mail]>]

On Mon, Sep 08, 2014 at 04:46:02PM +0100, Ian Nartowicz wrote:
> 
> >But this part:
> >
> >> Encoder authors are advised to
> >> take this into account. For example, it is more robust for a
> >> post-processing application to performing track normalization to update
> >> the 'output gain' field and write a comment 'R128_TRACK_GAIN=0' than to
> >> put the normalization value directly in the comment."
> >
> >Possibly needs to give some slightly different advice, at least for the
> >case where R128 normalisation is something that someone retrofits to
> >a recording that was previously mastered to some acceptable level, to
> >avoid actually losing useful information about the original in that case.
> >
> >Does that seem like it would cover what you're worried about?
> >
> >Do you have some proposed language for what you'd like us to recommend
> >people do if they want to retrofit R128 normalisation to recordings?
> 
> I hadn't considered language that goes any further than leaving the issue
> unspecified.

I don't think we should be leaving it entirely unspecified, that just
guarantees that nobody will get what they wanted from adding the R128
tags in the first place, since everybody will do something different
and in ways that subtly conflict with each other or produce surprising
behaviour in some players.

If we were to go that way, we should just say the header gain is
strictly mandatory and simply remove all reference to any sort of
"normalisation" tags.  But some people wanted us to specify those
tags, precisely to end the random state of madness that currently
exists with them elsewhere.  So if we do that, we should specify
a way that people agree works, and doesn't have obvious problems.


> Actively encouraging encoders not to put R128 gains into the
> output gain field seems to go directly against a key design goal for Opus.

No, I don't think that's the case.  I explained what the header gain
field was designed for, and it has nothing to do with "normalisation",
it's purely to allow *arbitrary* lossless correction where the only
other alternative might be a destructive re-encoding.

The only reason you'd really want to put an R128 correction in there is
if you really *always* wanted that to be the "original level" of the
file.  In a case where that was simply an advisory thing, and preserving
the "original level" of some previous master was also important, then
putting that into the advisory R128 tags seems perfectly correct to me.

I don't really see how that has anything to do with the "design goals"
of Opus, let alone be in conflict with them.


Unless you're going to tell me that I'm still completely failing to
understand what your actual concern is, the only problem I'm seeing
is that we've accidentally entangled an example of how the mandatory
and optional gains interact, in a way that might lead some people to
encode R128 normalisation suboptimally for some cases.

Which is indeed unintentional, and if so we should fix that.

Probably by splitting the example of how gains interact from the
advice we give about how optional R128 normalisation should be
indicated.


> Although I'd be happy to see this particular case recognised,
> do we want to to second-guessing users and filling the spec
> with exceptions?

I don't see where we'd be second guessing anybody, or needing to
make any exceptions at all to clarify this?

The basic rules are simple.

 - Mandatory gain is mandatory.  It's in the header.
 - Optional gain is optional.  It's in the comment tags.
 - Optional gain is always in addition to mandatory gain.

Where we might have made a bit of a mess that needs to be cleaned
up further, is that previously people thought we would only need
one R128 gain tag for TRACK_GAIN, and that "for simplicity" if
people wanted ALBUM_GAIN, they would either set that level while
encoding, or tweak the header gain to retrofit it.

Ultimately, other people made a convincing argument for also
having a separate R128_ALBUM_GAIN tag.  Which really does free
up the header gain to again *only* be used for its original
purpose of "arbitrary lossless correction as a tool of last
resort".

But it appears some of the language from prior to that hasn't
yet completely been untangled, and we're hinting to people that
they might prefer to use the mandatory gain, because it is
guaranteed to be applied and is therefore "more robust", but
we're using R128 gain as an example for that -- when the people
who Really Care about R128 normalisation actually do want that
to remain optional.


It was never the intent here that R128 normalisation should be
in any way mandatory.  The example was just intended to show
clearly how mandatory and optional gain are combined.

What I'm getting from your comments is we need an example that
looks less like advice for how to add R128 normalisation, and
perhaps some better advice for what the best way to add that
really is - something more like "If it's optional, *always*
prefer to put it in the tags, not the header gain".


Am I somewhere close to the mark there?  I *thought* I understood
what you wanted before the first change, but then we accidentally
made you sad trying to clarify that for other concerns too.


> In an ideal world I'd still like to see a solution that produces normalised
> output by default for all players, with sufficient information for more
> advanced players to "de-normalise" out a specific R128 gain when needed.

Well that should be 'easy', you just need to convince the player
authors to support the R128 tags, and turn them on by default
(assuming that doesn't cause their own users to revolt).

Our job here is just to be clear about how you can encode a file
to make that possible, when it is what you desire for that file.

We need the mandatory gain for lossless correction, but that's
an entirely separate issue to providing good advice for how to
make the best use of the optional gain tags for normalisation.

Only specialised editors should be "ignoring" the mandatory gain,
but it seems quite reasonable for an ordinary end user player to
be able to toggle R128 gain at the user's preference.

That's always been the intent.  If that's not what the words say
then we should fix the words so they do.

  Ron