Re: [codec] draft-ietf-codec-oggopus: R128_TRACK_GAIN units

[Ron <[e-mail]>]

On Thu, Sep 11, 2014 at 12:00:39PM -0400, Calvin Walton wrote:
> On Mon, 2014-09-08 at 13:11 -0700, Timothy B. Terriberry wrote:
> > As an individual...
> > 
> > Mark Harris wrote:
> > >  output gain field of the Ogg Opus header.  Is it expected that 
> > > these
> > >  units would be adopted by other codecs?
> > 
> > I can't speak for anyone else, but if _I_ were making a new codec, I
> > wouldn't see a need to innovate here. This design has the lessons of
> > doing this for 15+ years baked into it.
> > 
> > >  concerned that if Ogg Opus uses 1/256 LU units, and another 
> > > format or
> > >  codec uses the much more obvious LU (dB) units, then someone may 
> > > be in
> > 
> > Then they should pick a different tag name.
> > 
> 
> Just to comment on this:
> 
> The format of the "vorbiscomment" fields is very similar between at 
> least Ogg Vorbis, FLAC, and Ogg Opus. As a result, the tags are often 
> copied verbatim between the three formats during transcoding, and the 
> interpretation of tag meaning based on name is usually shared between 
> all three codecs in parsing code.
> 
> 
> As a result, without explicit code in the parser to e.g. reject or 
> interpret differently this tag between different formats, a player 
> that implements the R128_*_GAIN fields will as a side-effect add 
> support for the same tag in FLAC and Ogg Vorbis.
> 
> (This is the same reason that some players - at least gstreamer-based 
> players, rockbox, and foobar2000 - currently accept and use 
> REPLAY_GAIN tags in Ogg Opus files)

This is of course one of the perils of people implementing 'generic'
code with no sanity checking.  I believe there are libraries which
will happily try to force almost any codec into almost any kind of
container, whether that is well defined and well behaved or not.

Code reuse is great.  Code without sanity checking gets to keep
all the pieces.  There's not much we can do about that except
continue to remind people of the damage that blind application of
the 'be liberal' principle does.


Which isn't to say that FLAC and Vorbis and other Ogg mappings
shouldn't ever recognise these tags, but that's a discussion for
somewhere other than here right now.  This group isn't responsible
for decisions relating to those, nor have we been asked to be.


> Since this tag format is defined/specified in the Ogg Opus 
> specification, it might make sense to use a prefix on the tag name - 
> e.g. OPUS_R128_TRACK_GAIN - if the intent is that this tag is to be 
> used only in the Ogg Opus format. This would reduce the likelihood of 
> conflicts in the mostly-unregulated vorbiscomment namespace.
> 
> If the intent is that the R128 tags are intended to be used also in 
> FLAC and Ogg Vorbis then I think it would be best for it to be defined 
> outside of the Opus specification, somewhere that developers can 
> reference independently. In particular, care would be needed to 
> describe interactions with the REPLAY_GAIN tags that are still used in 
> these other formats.

I think Tim already covered this when he said:

    It's also got two years of deployment at this point, so there's
    now non-trivial costs in changing it. If we had a good reason,
    we could change it.  But "reduced confusion" is not a good
    reason. Changing now will only increase confusion (another
    lesson I've learned from letting people talk me into such
    changes in the past): people will be required to support both
    formats forever, despite the fact that one would be "standard"
    and the other wouldn't be.

There's no inherent reason these tags need to remain Opus specific,
this is just the first place they've been defined.  If nothing else
ever picks them up, that's probably not a big deal, if other things
do, they can copy or reference the definition here, just as we have
referenced the VorbisComment specification.

  Ron