On Wed, 2012-11-07 at 19:46 +0000, Gregory Maxwell wrote:
> Calvin Walton [calvin.walton@kepstin.ca] wrote:
> > While I don't see any technical problems with R128 - it is a good volume
> > normalization scheme - the issue is that it is a *different*
> > normalization scheme from the replaygain tags that are supported in
> 
> Replay gain does not specify a method for measuring the level. The
> R128 measurement technique is, in fact, being used in place of te
> older replay-gain in many places and I wouldn't be surprised if it
> were actually the most popular of the two then.   With that in mind
> the only difference between the two values is the specified meaning
> and a constant scaling factor for the different reference levels.   So
> it's trivial to make software that that can play a mixture of OggOpus
> and replaygain vorbis with the expected constant levels.

Hmm? Replaygain does specify a method. They go into a lot of details on
http://www.replaygain.org/ to describe the loudness filter used, the
method for calculating RMS power levels afterwards, the histogram-based
statistical processing, and how to calibrate the gain level to the -83dB
reference with a pink noise signal.

I agree that it would be possible to write a program that would support
playing back files with either R128 or replaygain values reasonably well
by adjusting the gain to compensate for the different reference points.

> > other audio formats - it gives different results, and isn't directly
> > interoperable, and isn't supported by many existing players.
> 
> Replaygain itself has very spotty support.
> 
> This means that if you create a file with replaygain tags it will have
> _wildly_ different playback levels depending on which player you use.
> So any content distributor can simply not use it if they care about
> things working consistently at all.  The only place it works reliably
> is on your own files... and well, if thats all you care about
> interoperability isn't much of an issue.

> One of the major motivations behind how this this is address in
> OggOpus is that we have the gain header field that gives a default
> playback gain. This works in all existent players... and it allows
> consistent behavior.  And it is supported by every single existing
> decoder that I'm aware of.

Yes, having the standard gain header that is supported by all decoders
is nice - except for the case of playback of mixed file formats,
particularly by an application that doesn't understand the gain tags in
other formats. In those cases, the Opus files will be significantly
quieter (assuming modern pop mastering...) than the other files, making
them sound "worse" than files without gain applied.

> > I've done a survey of existing player applications with Ogg Opus
> > support. All of these players:
> > * Rockbox (development version with Opus support)
> > * GStreamer-based (e.g. Rhythmbox)
> > will use the REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags (as
> > specified in Vorbis) to apply replaygain to Opus tracks. Both Rockbox
> 
> Can you give me a link to a test file— I tried and it isn't for me.

I can do that; here's the CC attribution, non-commercial, share-alike
track "Discipline" by Nine Inch Nails, with vorbis-style replaygain tags
added, no r128 gain tags present, and opus header gain set to 0. It is
representative of how I've been doing music in my collection:
http://www.kepstin.ca/dump/nin-discipline.opus (~4.1MB, ~128kbit stereo)

Note that both Rockbox and Rhythmbox ship with replaygain correction
turned off by default; it must be manually enabled (It's in the playback
options in Rockbox, and in the Plugins menu in Rhythmbox).

An example gstreamer pipeline for this is
$ gst-launch-1.0 -t filesrc location=nin-discipline.opus \! decodebin \! rgvolume \! pulsesink

(remove the rgvolume element to get the track without replaygain applied)

> > and Gstreamer-based players will first apply the stream header's output
> > gain field prior to applying the replaygain correction; I haven't
> > checked foobar2000 on that point.
> 
> Well thats good.
> 
> > Of the players in that list, only foobar2000 supports the R128 gain tag.
> > I am not sure what happens if both tags are present.
> 
> Thats not correct. The way the spec is constructed and apps are
> implemented gain works fine _without_ supporting the tag.  It
> basically make it work by default. And I think this is a massive
> improvement which would be broken by reintroducing the widespread
> inconsistency of replaygain.

The issue I see here is that the normalization method used for the value
in the opus header output gain field is *not specified* currently. An
application can put any value in that field, and a player cannot assume
that the value is relative to any useful reference point. The only
supported place currently to get a gain with a useful reference point is
the R128_TRACK_GAIN tag.

If a player blindly applies only the header output gain value, it has no
knowledge of whether the output is loudness normalized or not.

-- 
Calvin Walton <calvin.walton@kepstin.ca>