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

[Ian Nartowicz <[e-mail]>]

On Tue, 9 Sep 2014 03:27:41 +0930
Ron <[e-mail]> wrote:

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

I would be entirely happy if it was recommended that R128 gain values were
stored in their tags and not normally in the output gain field, but I've felt
resistance to that idea before.  The spec itself advised the opposite and
explained the reason: everyone will apply the output gain, not everyone will
apply the tag gain.

Do we agree about this?  Might be best to wait for some other comments.

--ian