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

[Ron <[e-mail]>]

On Mon, Sep 08, 2014 at 07:19:32PM +0100, Ian Nartowicz wrote:
> 
> 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 original push-back as I recall it was against the idea of needing
a separate R128_ALBUM_GAIN tag at all -- since the original thinking
was header gain could be used for that, if it wasn't already done
during the initial encode, so only a separate R128_TRACK_GAIN was
needed for "alternative normalisation".

But now that we've also added R128_ALBUM_GAIN, it would be silly not
to recommend using it in the way that the people who wanted it, wanted
to be able to use it.

I think any remaining language that indicates otherwise is mostly an
oversight, partly because the people who proposed the changes to the
text weren't the people who pushed to have this added, and partly
because it was done by making minimal changes to the existing text.

"We knew what we meant", but if it doesn't actually say that to others,
then yes we ought to fix that.  This is the problem with being too
close to your own writing :/


> The spec itself advised the opposite and explained the reason:
> everyone will apply the output gain, not everyone will apply the
> tag gain.

Right, but that's only a reason to do it that way if it's important
to you that *everyone* always applies the gain you set.  Which is an
important use case, but not the one you've been concerned about.

In the case where the gain you are indicating really is advisory,
as you've said you really want the R128 normalisation to be (and
which it makes sense to me that in many cases they should be),
then it's absolutely appropriate to only use the tags for that.

The spec doesn't currently say you *can't* do that, or even that
you SHOULD NOT do it, but I agree the example given might mislead
some people into doing that when it's probably not what they really
wanted, or what's best for the case you describe.


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

I think Ralph now also sees this in a similar way, and I think I
can fairly safely say without fear of contradiction that it was
never intended for R128 normalisation to be mandatory.

It just took us a while to convert the Solution you were proposing
into an actual Problem we could wrap our heads around, since we
were reading the text as already allowing you to do this, and blind
to the example's urging that maybe you shouldn't - so we couldn't
see what your objection to the header gain MUST really was.

I think mostly now someone just needs to proofread the troublesome
bits again, and propose some text that more plainly says what we
mean, what is required and why, and gives some better guidance as
to what Best Practice for optional normalisation tags should be.

When we can agree on that, we'll know we're really all on the same
page about all of this :)

  Thanks!
  Ron