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

[Ian Nartowicz <[e-mail]>]

On Mon, 25 Aug 2014 16:11:21 -0700
Ralph Giles <[e-mail]> wrote:

>On 2014-08-15 9:01 PM, Ron wrote:
>
>> So the patch applied for this part is now:
>> 
>>> - If an encoder wishes to use R128 normalization, and the output gain is not
>>> - otherwise constrained or specified, the encoder SHOULD write the R128 gain
>>> - into the 'output gain' field and store a tag containing
>>> "R128_TRACK_GAIN=0".
>>> - That is, it should assume that by default tools will respect the 'output
>>> gain'
>>> - field, and not the comment tag.
>
>I agree this part is confusing. I think it's too terse to offer good
>guidance.
>
>>>   If a tool modifies the ID header's 'output gain' field, it MUST also
>>> update or remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if
>>> present.
>
>This seems helpful in avoiding broken files.
>
>>> + An encoder should assume that by default tools will respect the 'output
>>> gain'
>>> + field, and not the comment tag.
>
>I read this as a non-normative should. Would it be better:
>
>"By default, implementations of this specification MUST respect the
>'output gain' field, but MAY NOT respect the comments. Encoder authors
>are advised to take this into account. For example, to produce R128
>normalized files it's more reliable for post-processing application to
>update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
>than to put the normalized value directly in the comment."
>
>This removes the normative suggestion of 'should' while maintaining the
>suggestion and rationale.
>
> -r

This seems like a step backwards to me.  That MUST is a requirement
that wasn't present before.  An earlier statement is "Virtually all players
and media frameworks should apply it by default.", which I think is the
appropriate guidance.

>I'd be inclined to drop the "By default" there, unless we're going
>to expand on what the exceptions to the 'default' might be.

I agree with Ron that saying "By default" and "MUST" in the same sentence is
confusing, but I think the solution is not to say MUST.  There are exceptions
to the default.  Trying to specify them all here would seem an impossible feat
of guesswork, but since they exist then MUST is too strong.

>Is there a reason we shouldn't just have two examples?
Possibly, but if you start down that path you need more than two examples.
Either tag or both may be present, with or without a pre-existing output gain
value.

The intention of this change, after much discussion, was specifically not to
constrain how an encoder should split an R128 gain between the output gain
field and the tags.  Hence: advice rather than normative language.  Part of the
reason is quickly apparent in the discussion of whether to place the track gain
or album gain in the output gain field, and the answer was not to specify.

--ian