Subject: [codec] OggOpus: Rational for excluding replaygain tags?

From: Calvin Walton <[email-masked]>
Date: Wed, 07 Nov 2012 12:03:14 -0500

Hi everyone,

I've been going through draft-terriberry-oggopus-01, and I'm wondering
why this section is present:

   To avoid confusion with multiple normalization schemes, an Opus
   comment header SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN,
   REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or
   REPLAYGAIN_ALBUM_PEAK tags.

As an end-user, I'm considering using Opus for part of my music
collection. The rest of my collection (a mix of file formats including
MP3, Vorbis, FLAC, AAC) is all normalized using the replaygain standard.

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
other audio formats - it gives different results, and isn't directly
interoperable, and isn't supported by many existing players.

I've done a survey of existing player applications with Ogg Opus
support. All of these players:
* Rockbox (development version with Opus support)
* foobar2000
* 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
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.

Of the players in that list, only foobar2000 supports the R128 gain tag.
I am not sure what happens if both tags are present.

I would suggest that instead of simply saying that the OggOpus file
SHOULD NOT contain the replaygain tags, it should say that they MAY be
present, and should specify how they are interpreted and applied (This
mainly would concern their relation to the stream "output gain").

I would however recommend that the files still SHOULD NOT have the
REPLAYGAIN_{TRACK,ALBUM}_PEAK tags, as Opus does not have a bit-accurate
decoder specified, and the peak values will also vary based on the
sample rate selected for decoding.

I'd appreciate any comments you have, I'm really curious as to why the
draft is recommending against the use of replaygain tags.

-- 
Calvin Walton <[email-masked]>

---

From: Ralph Giles <[email-masked]>
Date: Wed, 07 Nov 2012 09:22:02 -0800

> mainly would concern their relation to the stream "output gain").

I think the idea was to encourage adoption of the R128 methods along
with Opus, since R128 is both technically superiour and more officially
standardized. I agree it would be useful to describe what to do if
multiple tags are present, even if it remains SHOULD NOT.

I would say, "The R128 tag overrides any REPLAYGAIN tag which is
present. Player MAY choose to apply REPLAYGAIN values, combined with the
output gain from the OpusHead packet, if no R128 tag is present."

> sample rate selected for decoding.

That's a useful distinction to maintain. I agree.

The other issue is what encoders are doing. Are any of the applications
you tested *setting* REPLAYGAIN tags on files they encode? Or is it just
that you want some level equalization and your player doesn't currently
support the R128 scheme during playback? The question is whether we have
some hope of acheiving compliance with the idea as opposed, or if it's
too late for that already.

 -r

---

From: Calvin Walton <[email-masked]>
Date: Wed, 07 Nov 2012 12:53:19 -0500

> multiple tags are present, even if it remains SHOULD NOT.

As long as the behaviour is properly documented, saying 'SHOULD NOT' is
probably ok, even if I think it is a bit strong.

> output gain from the OpusHead packet, if no R128 tag is present."

I think that the player should allow the user to optionally prefer
REPLAYGAIN over R128. The issue that I have is interoperability with
files in other formats, which do not have any standardized way of saving
R128 gain tags, but do have defined REPLAYGAIN mappings. Loudness
normalization is useless if you can't normalize everything to the same
standard :)

> too late for that already.

As far as I know, there are no applications currently that automatically
set replaygain tags in Ogg Opus. This could change - e.g. once a
tag-editing element for Ogg Opus is added to Gstreamer, then Gstreamer
applications will automatically gain the ability to set replaygain tags.
I'm considering adapting the 'vorbisgain' utility to decode Opus for my
personal use, to normalize files in my collection.

In order to apply the values to the files that I have, I used a
format-agnostic replaygain calculation tool to get the values, and a
standard vorbis comment editor to set the values.

If you ask foobar2000 to generate replaygain tags on Ogg Opus, it
currently saves values in the header output gain (for album) and the
R128 track tag. It's unclear whether it actually uses the R128 algorithm
or if it uses Replaygain with a non-standard reference value.

---

From: Gregory Maxwell <[email-masked]>
Date: Wed, 7 Nov 2012 19:46:34 +0000

> 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.

> 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.

> 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.

> checked foobar2000 on that point.

Well thats good.

> 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.

Make sense?

---

From: Calvin Walton <[email-masked]>
Date: Wed, 07 Nov 2012 17:41:21 -0500

On Wed, 2012-11-07 at 19:46 +0000, Gregory Maxwell wrote:
> 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.

> 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.

> 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)

> 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.

---

From: Calvin Walton <[email-masked]>
Date: Wed, 07 Nov 2012 17:51:36 -0500

> reference with a pink noise signal.

Sorry, a minor correction - and this *is* something that has caused
interoperability issues in the past: The correct replaygain reference
gain level is "89 dB" SMPTE SPL, not 83 dB. (The - sign was a typo...)

---

From: Ron <[email-masked]>
Date: Thu, 8 Nov 2012 14:23:05 +1030

Hi Calvin,

Thanks for your input here.

Just to comment on this point:

On Wed, Nov 07, 2012 at 05:41:21PM -0500, Calvin Walton wrote:
> in the opus header output gain field is *not specified* currently.

The 'normalisation method' for the header gain is specified as:

    An encoder SHOULD set this field to zero, and instead apply any
    gain prior to encoding, when this is possible and does not
    conflict with the user's wishes.  The output gain should only be
    nonzero when the gain is adjusted after encoding, or when the
    user wishes to adjust the gain for playback while preserving the
    ability to recover the original signal amplitude.

ie. any normalisation that you want to do at encoding time should be
done *before* encoding, and the header gain is left purely for other
users who would like to arbitrarily rescale it without reencoding,
to any level they deem appropriate for their particular use.

For instance you might use this to match levels with a signal from
some other source that isn't ordinarily normalised to some standard
like R128 or so.  It's not so much for equalising the signal to one
particular standard level, as it is for allowing people to later
trivially adjust it 'losslessly' to some desired level entirely of
their own choosing, for whatever reason they may desire that.

> An application can put any value in that field, and a player cannot
> assume that the value is relative to any useful reference point.

Correct, a player can only assume that it is the level that the
person who created the file wants it scaled to, and that it should
play it at that level, absent any other input from the user to the
contrary.

> The only supported place currently to get a gain with a useful
> reference point is the R128_TRACK_GAIN tag.

That's why this is a separate mechanism to the header gain.
This one is about noting the gain adjustment required (after the
header gain is applied) to achieve a known, specific reference
signal level.

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

A player must always apply the header gain to output the signal
level that the person who created the file intended it to have
(as if they really had scaled it by that level prior to encoding).

A player may also optionally apply normalisation to a standard
level on top of that, either based on information in the file's
comment tags, its own analysis of the file, or some other
mechanism based on input from the user of that player.

The former is about gain choices made by the creator, the latter
is more about gain choices made by the end user.  The former
must always be applied so that players behave consistently, the
latter may be applied at the sole discretion of the user and
(how they configure) the applications that they use to play it.

Is there something about that which we need to explain better
in the draft?

  Cheers,
  Ron

---

From: Calvin Walton <[email-masked]>
Date: Thu, 08 Nov 2012 01:13:50 -0500

> Is there something about that which we need to explain better

There is one place in the draft that does conflict with this - the
rational for why an R128_ALBUM_GAIN comment was not included. It is
noted that the 'album' gain value should be stored in the header gain
field instead. However, if the header gain is supposed to be used by the
audio creator/encoder and not the end user, then this will overwrite the
creator's value.

In addition, since the header gain field has no semantic meaning, there
is no way to know that the value in this field corresponds to the R128
album gain as opposed to an arbitrary creator-provided value, meaning
that a player cannot reliably give the user the ability to select
'album' vs. 'track' gain during playback by their preference.

(I admit that for the time being, most opus files will be encoded by the
same person as the end user who will be listening to them, of course...)

Anyways, this is getting a bit far afield from my original topic...
I want to play back Ogg Opus files at the same loudness level as my
existing Replaygained Ogg Vorbis/FLAC/MP3/AAC/etc. files. Currently I
have 3 choices:

1. Add Vorbis-style REPLAYGAIN_{TRACK,ALBUM}_GAIN comments with
adjustments relative to the header gain (usually 0). This works
correctly in all players that I have tried, even though the spec says
that these tags should not be used. Since players generally share
comment parsing code between vorbis and opus, these comments are likely
to continue working for the foreseeable future.

2. Store either the track or album replaygain values in the header gain
field. This works correctly in all players, but does not allow me to
choose between album and track gain at playback time. (e.g. for
continuous playback versus random/shuffle playback)

3. Store an arbitrary value (usually 0) in the header gain field, and
use the R128_TRACK_GAIN comment with an R128 adjustment. Have the player
add an additional adjustment to adjust the reference level to match
replaygain. foobar2000 gets this almost right, except that it assumes
that the header gain field corresponds to the album gain, which may not
be correct. No other player currently supports this. (On the other hand,
since comment parsing code is generally shared, this means that the
R128_TRACK_GAIN comment will likely start working in Ogg Vorbis files
soon.)

At this point, I see the replaygain comments as the most compatible /
interoperable way of reaching my goal, but it does mean that I'm relying
on behaviour that the spec says I SHOULD NOT do. I'm wondering if it
would make sense to specify the behaviour for when these tags are
present.

---

From: Gregory Maxwell <[email-masked]>
Date: Mon, 26 Nov 2012 16:30:24 +0000

Sorry for the delayed response— been tied up on other tasks.

> reference with a pink noise signal.

It offers one, yes— but it's not a specification. I was stridently corrected by the author of replaygain when I made the same claim that you are.

I'm also advised that most tools are now using the EBU R128 method now in any case. And in practice the point is fairly moot as the values are effectively compatible on actual audio once the reference level.

> them sound "worse" than files without gain applied.

I don't see how you can usefully make an argument here.  If you don't have gain adjustment (on the files or in the application) and you have files from various sources you will have various levels.

If you listen exclusively to commercially mastered loudness-war recordings then having gain adjustment on some files and not others would increase the level of the already existing inconsistency somewhat. But I don't see what more there is to do about that.  I can't abide by an argument that because Vorbis was previously broken all things forever must be broken.  Applying gain on OggOpus files has functionally identical behavior to aacgain/mp3gain with respect to this.

> track "Discipline" by Nine Inch Nails, with vorbis-style replaygain tags

I still can't reproduce on my system, but I've asked people to fix it and the next version of these tools shouldn't have the weird behavior any longer.

> in the opus header output gain field is *not specified* currently. An

There is a recommendation, but it's not— and shouldn't be— a requirement.

> knowledge of whether the output is loudness normalized or not.

I'd like to say that there should be an informative tag there to indicate whats being done. However: I'm absolutely sure it will be reliably set wrong, double so because other than displaying it as metadata there is simply nothing most software can do with the information. There would be little way for careless implementers to discover that they've gotten it wrong... and so the information would likely be worse than useless as it would just add complexity without concrete value.

---

From: Calvin Walton <[email-masked]>
Date: Mon, 26 Nov 2012 23:50:37 -0500

On Mon, 2012-11-26 at 16:30 +0000, Gregory Maxwell wrote:
> It offers one, yes— but it's not a specification. I was stridently
> corrected by the author of replaygain when I made the same claim that
> you are.
> 
> I'm also advised that most tools are now using the EBU R128 method now
> in any case. And in practice the point is fairly moot as the values
> are effectively compatible on actual audio once the reference level.

Yes... I've since looked into this a bit more. foobar2000 uses the R128
algorithm to calculate the values to store in ReplayGain comments; the
command-line tools vorbisgain and metaflac that I normally use are still
based on the older ReplayGain suggested algorithm.

The ReplayGain reference value is 5 dB louder than the EBU R128 standard
reference value, so compensating for the difference is straightforward.

> I don't see how you can usefully make an argument here.  If you don't
> have gain adjustment (on the files or in the application) and you have
> files from various sources you will have various levels.

My argument is based on using a player that supports Opus playback,
supports ReplayGain tags, but does not support R128 gain tags. This is
the case with some current players (e.g. Rockbox, Rhythmbox).

All of my existing Ogg Vorbis files with ReplayGain tags will be played
back 5 dB louder than an Opus file with R128 album gain stored in the
header gain field. (A workaround for this would be to use the ReplayGain
preamp to apply a -5 dB gain after the ReplayGain adjustment.)

Alternately, if the Opus file has a R128_TRACK_GAIN comment present, but
0 in the header gain field, it will be played back unnormalized!

For the case of older versions of Rhythmbox running with a newer
Gstreamer library backend that supports decoding Opus, this situation
may be maintained for quite a while.

> I'd like to say that there should be an informative tag there to
> indicate whats being done. However: I'm absolutely sure it will be
> reliably set wrong, double so because other than displaying it as
> metadata there is simply nothing most software can do with the
> information. There would be little way for careless implementers to
> discover that they've gotten it wrong... and so the information would
> likely be worse than useless as it would just add complexity without
> concrete value.

If I select to use 'Album Gain' mode for ReplayGain in the playback menu
of my iPod running Rockbox:
http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch7.html#x10-1270007.9
there is currently no way for the player to know whether or not the
arbitrary value in the header gain field represents R128-normalized
album gain or something completely different.

Most players fall back to using the track gain field if the album gain
is not present - but this can't work properly with the current
specification of Ogg Opus. They must either assume that the user has put
R128 album gain into the header gain field (I think foobar2000 currently
does this), or only use track gain.

My personal suggestion would be to have an R128_ALBUM_GAIN field, with
the same format and similar semantics to the R128_TRACK_GAIN field. In
the case where the album gain is stored in the header gain field, the
R128_ALBUM_GAIN field SHOULD be present and be filled with a value of
'0', indicating that no further adjustment is needed to get R128 album
normalized loudness.

---

From: Calvin Walton <[email-masked]>
Date: Tue, 27 Nov 2012 02:36:16 -0500

> may be maintained for quite a while.

Sorry for the double post, but I wanted to elaborate on this a bit:

This is why I'm currently putting the Vorbis-style ReplayGain tags into
my Ogg Opus files - they are interoperable with existing players, and
work right now. For the time being, in my personal files I'm using the
following backwards- and hopefully forwards-compatible structure:

New logical stream (#1, serial: 00332868): type opus
Encoded with libopus 1.0.1
User comments section follows...
[...]
	REPLAYGAIN_ALBUM_GAIN=+5.00 dB
	REPLAYGAIN_TRACK_GAIN=+4.72 dB
	REPLAYGAIN_TRACK_PEAK=0.171997
	REPLAYGAIN_ALBUM_PEAK=0.184993
	R128_TRACK_GAIN=-72
Opus stream 1:
	Pre-skip: 356
	Playback gain: -15.2891 dB

where the playback gain is an arbitrary number that bears a striking
resemblance to the R128 album gain, R128_TRACK_GAIN is a relative
adjustment to -23 LUFS reference, the REPLAYGAIN_*_GAIN comments are
relative adjustments to -14 LUFS reference (literally just the
corresponding R128 values +5 dB), and the REPLAYGAIN_*_PEAK tags contain
the peak after playback gain is applied, but before ReplayGain is
applied.

(Note that the ReplayGain peak tags are required to tell the GStreamer
'rgvolume' element that it is safe to increase the volume by 5 dB
without clipping; otherwise it will refuse to go above +0 dB.)

This gives me working volume normalization in all of the players that I
use regularly. Rhythmbox and Rockbox use the ReplayGain comments,
applied after the playback gain field. foobar2000 uses the R128 track
gain comment and the playback gain field (it assumes that playback gain
contains the R128 album gain), adjusts both +5 dB, then uses them as
ReplayGain values.

But the combination certainly looks really ugly, for what that's
worth :)

---

From: Ron <[email-masked]>
Date: Tue, 27 Nov 2012 18:29:10 +1030

> album gain or something completely different.

The only thing the decoder needs to know about the header gain is that
it should _always_ apply it.  Trying to assign some other meaning to it
and then applying it selectively is precisely the kind of confusion,
misbehaviour, and random difference between players that this mechanism
aims to avoid.

The draft says "virtually all players", because specialised applications
may have reasons to want the raw data level, but the simple rule for
most players is "you can't know what it means, it's the level the author
of the file wanted samples decoded at, just always apply it before doing
anything else".

Trying to attach an 'album gain' mode selector switch to it adds the kind
of chaos that this recommendation is meant to avoid:

In the absence of an ALBUM_GAIN tag, your album gain mode switch should
simply do exactly nothing at all.  If it tries to do something that it
thinks is "smart" instead, then it's lying to you about what the album
gain switch does (unless it's actually going to analyse the whole album
for you on the fly...).

> does this), or only use track gain.

If there are players where you explicitly select "album gain" and they
instead arbitrarily apply "track gain" instead, then I would say that
they are already not working properly.

But since we do seem to have generated some confusion here with at least
one person, I wonder if we need to reword this clause in the spec:

 There is no Opus comment tag corresponding to REPLAYGAIN_ALBUM_GAIN.
 That information should instead be stored in the ID header's 'output
 gain' field.

You seem to have confused that with "header gain may mean album gain".
That's not what it means at all.  What it means is "album gain is useless
and most things only get it wrong".  If you want your files normalised
to that level, and didn't do that when you first encoded them, then you
can still do it 'losslessly' by adjusting the header gain field later.

That way, _every_ player, that doesn't apply some other gain of its own,
will play them back with the desired "album gain".  And since "album gain"
is basically a euphemism for "play all tracks at the level that the artist
intended, not at some false-normalised level" -- that actually corresponds
fairly well to what the header gain does.

If an entire album is _supposed_ to be exceptionally quiet, or similarly
exceptionally loud, then you don't _want_ it normalised to some arbitrary
muzak sound pressure level that is the same for all albums.
Header gain lets you have all of those options, with the best guarantee
we can give that it will actually work the same in all players.

> '0', indicating that no further adjustment is needed to get R128 album

If you want all your albums to play at exactly the same level, regardless
of what the author intended, then you can tweak the header gain field
without re-encoding (and you become the new author that all players will
respect the choices of).

Selecting track gain does not mean that a player should ignore the header
gain.  It means the player should apply that relative to the already
applied header gain _in addition_.  Likewise, unselecting album gain
should _never_ cause a player to ignore the header gain.

If you are already confused with just 2 gain knobs to adjust, can you
imagine how many extra permutations of confused some people will be if
we add even more of them, with even more rules for when to apply them?

I don't mean to dismiss your concerns here, but I get the feeling that
there's some element of people talking past each other with different
impressions of what the same things actually mean.  And if that is the
case, then we should clarify the spec to better explain that header
gain is NOT "album gain", and should not be interpreted as such by any
'normal' player.

All the spec is intended to say is that an author _may_ use it for that,
just as they may use it to normalise to any other arbitrary level that
is appropriate for the *default* playback of that file.  But it's not
the job of a player to know what it is supposed to mean - for a player
to behave correctly, and the same as all other players, all it needs to
do is just always apply it.  We can't make a rule that is much simpler
to always get right across all player implementations than that :)

Does that makes sense?

  Cheers,
  Ron

---

From: Calvin Walton <[email-masked]>
Date: Tue, 27 Nov 2012 04:52:48 -0500

> misbehaviour, and random difference between players that this mechanism

This is very different from the ReplayGain tags. ReplayGain is
*optional* at playback time, and is only applied if the user
*explicitly* requests one or the other type of loudness normalization.

The issue is coming in because there are players that already support
the ReplayGain model, and they are trying to shoe-horn approximately
corresponding values into Opus header and comment fields that don't
share the same semantics.

ReplayGain-supporting players typically have 3 settings:
     1. ReplayGain off: Use the original audio levels of the file (as
        set by the mastering engineer/record label/artist/file encoder)
     2. ReplayGain album mode: Normalize the loudness of an album, but
        keep track-track variations. This is the counter to the loudness
        wars (see below), and is useful for general listening.
     3. ReplayGain track mode: Normalize all tracks to the same
        loudness. Useful for things like party background music randomly
        selected from multiple albums, or listening to music on public
        transit from a portable player, where a quiet song could be
        drowned out.

Players based on the current Ogg Opus standard cannot support all 3
modes on a single file, because the playback gain field may contain
either 1, 2, or something else entirely at the discretion of the person
who last modified the audio file.

Note that I generally want the "default" playback of the file to be at
original levels, so that if I e.g. pass a file to a friend who does not
use ReplayGain, they don't complain that "This file is too quiet!" Keep
in mind that a file of pop music with R128 normalization might play back
15 dB (or more!) quieter than the original signal!

As a result, I want my preferred playback loudness to be stored
*separately* from the default value, in a place where it is only used if
I explicitly select either album or track gain (and which one I choose
depends on what conditions I am listening to music under.)

> gain switch does (unless it's actually going to analyse the whole album

The reason for this is kind of a best effort fallback: You asked for
music to be normalized loudness. If it can't be normalized in the manner
you asked, a fallback would be to estimate a close level - Track gain is
usually within 1-2 dB of album gain on most releases.

If this isn't done, you could (given modern pop mastering) suddenly get
a track that's 10 dB (add 5 dB if you're using R128 instead of
ReplayGain) or more louder than everything else, simply because e.g. it
was a single-track download and you didn't notice that your scanning
tool didn't add 'album' gain to it. It's to protect your ears and/or
speakers.

> without re-encoding (and you become the new author that all players will

Unfortunately, if the record labels and mastering engineers get their
choice of selecting the playback level, you get something called
"Loudness Wars", because of the purely psychological fact that louder
music sounds better. This dates back to the days of vinyl, when e.g.
particularly "hot" vinyl masters would sound better when played in a
jukebox. Over the ~18 years that we've had CDs, the mastering volume of
pop music on CD has gone up around 10 dB. Record labels are refusing to
release quieter music, because it won't sound as good as the existing
loud recordings that someone already has. And online music sales have to
sound as good as the CD you just ripped (The artist rarely gets a say in
the matter, really...)

The main point of ReplayGain in album mode is to counter this trend and
even out the levels between albums, because the listener doesn't trust
the mastering engineer's choice of volume.

> should _never_ cause a player to ignore the header gain.

All players that I've tested handle this correctly. Players always apply
the header gain, then any other gain values on top of that.

> gain is NOT "album gain", and should not be interpreted as such by any

If this is the case, then there should be a separate album gain field so
that there is a place to store a value which a player could interpret as
such.

> to always get right across all player implementations than that :)

Players have already screwed this up, by assigning additional meaning to
a field which wasn't intended, since there wasn't a field corresponding
to the exact meaning desired.

---

From: Ron <[email-masked]>
Date: Tue, 27 Nov 2012 22:38:38 +1030

> *explicitly* requests one or the other type of loudness normalization.

Header gain is not about normalisation.  It is about being able to change
the gain deterministically for all players, in a way that actually works
the same for everyone everywhere, without needing to re-encode the file.

> share the same semantics.

If there really are players that are doing it wrongly, then bugs should
be reported to their authors.

> who last modified the audio file.

No, the header gain _never_ contains 1 or 2, it is always and only
an entirely discretionary post-encoding adjustment.  This ensures
there will never be any confusion about what it "means".

> tool didn't add 'album' gain to it. It's to protect your ears and/or

If you're within 10dB of blowing your speakers, your ears are already lost.
If you're relying on this to save either of them, then you'd better never
change your player software, and hope nothing or nobody ever changes the
current settings in it without you noticing.

I'd certainly change my player if it applied track gain when I didn't ask
for track gain to be applied.

> the mastering engineer's choice of volume.

So you don't trust them to set the header gain to a level you don't like,
but you do trust them not to set ALBUM_GAIN = +11 ?

You don't need album gain to be able to fix this.

> the header gain, then any other gain values on top of that.

Then maybe there are no bugs to report to them after all ... ?

> to the exact meaning desired.

Now you have me confused.  Did they *actually* screw this up or not?

And how would making it even more complicated help them screw it up less?

So far as I can see still, you're trying to find a use for an "album gain"
button that your application gave you, which isn't actually of any use at
all for this format, because the problem that album gain was invented to
solve doesn't actually exist with this format like it does for some others.

You have two very simple knobs.  Default gain, and normalised gain.
The latter being entirely optional for both users and players, and both
of which can be changed by the user losslessly if desired.

If you say you want multiple levels of normalised, then where does this
stop?  Should we also provide equalisation profiles for every room that
you listen in and every piece of audio equipment you use to play it?

Aside from "making things an overcomplicated mess like ReplayGain", what
real problem cannot be solved with the degrees of freedom that the current
spec already gives you?

  Ron

---

From: Calvin Walton <[email-masked]>
Date: Tue, 27 Nov 2012 11:53:01 -0500

> real problem cannot be solved with the degrees of freedom that the current

Let me state my goals simply:
     1. I want my Ogg Opus albums to play back at the same loudness as
        my existing albums in other formats (Vorbis, Flac, Mp3, etc.)
        that are using ReplayGain.
     2. I would like to be able to at playback time select track-based
        normalization instead of my normal preferred loudness.
     3. Ideally, I want to be able to give one of my files to a friend
        who doesn't normally use ReplayGain, without them complaining
        that "This is too quiet!"

#1 is pretty simple to do with header gain: I just store my album
ReplayGain values in the header gain field. Most of my players get this
right, but foobar2000 gets this wrong, and adds +5 dB to the value when
playing it because it assumes that the field contains R128 normalized
levels and it is compensating.

We probably still have time to get them to fix this before the rest of
the world decides to follow "what foobar2000 does" for compatibility :)

#2 is OK in theory using the R128_TRACK_GAIN tag, except that most of
the players I use don't know how to apply it yet. This is in general not
too bad, because they still apply the header gain, so the level is
close... but not correct.

#3 I can't do if the header gain field contains anything other than 0,
really. So I end up having an extra step of stripping out my personal
gain modification settings before giving away a file.

Or, alternatively, I can set the header gain field to any value (0 works
ok if I also remove the R128_TRACK_GAIN tag, since that tricks
foobar2000 into thinking that R128 gain isn't present), add ReplayGain
tags relative to the header gain value, and *everything works on all
players that I use*.

> for track gain to be applied.

Alright, I might be exaggerating a bit here, but still... a sudden 10 dB
jump in volume from one track to another while listening on headphones
can be very surprising and unwelcome. On speakers it's more "annoying
your roommates" than "blowing your speakers".