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

[Ron <[e-mail]>]

On Wed, Aug 27, 2014 at 11:54:38PM +0100, Ian Nartowicz wrote:
> <snip>
> 
> >I thought the only confusion there was "how do I turn off album gain
> >if there isn't an explicit album gain tag?" - given that you MUST NOT
> >disable the output_gain, which may or may not have been calibrated to
> >R128 album gain levels.
> >
> >You still MUST NOT turn off output gain, even if R128_ALBUM_GAIN=0
> >is explicitly specified, since the raw file still could be at "I'm
> >50 meters from ground zero of an atomic test" levels.  That still
> >doesn't imply *anything* about what the output_gain is or means.
> >
> >But we've given you an explicit album gain tag now that you can
> >switch on or off if it's not zero.  I'm not sure what the remaining
> >confusion really is, but indeed, let's find it and clear it up.
> >
> >  Cheers,
> >  Ron
>
> And so we're back to square one.

Well, if you think that, then maybe it's *you* not making your case
clearly to us :)

> There's no confusion here.  I have pointed up a perfectly reasonable and
> widespread requirement to sometimes, at the user's choice, play back music *as
> encoded* (and sometimes normalised to R128).

The output_gain is part of the encoding (not a tag that can be freely
stripped away or ignored).  If you want to play the music *as encoded*
that includes the hardware gain.

If it doesn't, and that isn't "guaranteed", then you've basically made
that useless to anyone mastering a recording, and their only option
for robust behaviour in the face of people who insist on making players
that ignore it is to completely re-encode it from scratch.

Which leaves us not only back with the original problem that this was
designed to solve, but with a worse than useless field in the header
that nobody will actually know how it really behaves in the real world.
And you don't get what you want from it either, because the person who
mastered it, irretrievably destroyed that information when they made
their track "guaranteed to work on broken players too".
Everyone loses if you add uncertainty here.

There is one gain knob that is entirely at the discretion of the person
mastering the recording.  We've now given you two that users and players
can fiddle with to their heart's content.

Why do you need yet another one, and why should people making masters
not have one they can rely on to be an integral part of the encoding?


> You don't accept that this is a legitimate requirement, even making up
> bizarre examples to somehow refute real things that are happening in
> real software.

The only requirement that you made clear to me was you wanted a
separate, clearly defined R128_ALBUM_GAIN as well as the track gain.

We've given you that.

If you're going to handwave about other "perfectly reasonable and
widespread requirements", you're going to have to actually give some
examples to make that case.  Especially if it comes at the cost of
the perfectly reasonable requirement for people mastering tracks to
be able to losslessly fix something that was originally (and quite
possibly accidentally) recorded at an entirely unlistenable and
unreasonable level.

We've given you examples of the originally intended use.  You can
brand them bizarre if you like, but badly captured original
recordings that need level adjustment to be actually useable are
hardly something unheard of.  Why force people to re-encode a live
opus capture to make it useable, when they can trivially correct
it instead?

What specific counterexample do you have that is so important it
should make that effectively impossible to do reliably?

  Ron