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

[Ron <[e-mail]>]

On Tue, Nov 27, 2012 at 04:52:48AM -0500, Calvin Walton wrote:
> On Tue, 2012-11-27 at 18:29 +1030, Ron wrote:
> > On Mon, Nov 26, 2012 at 11:50:37PM -0500, Calvin Walton wrote:
> > > 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.
> > 
> > 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.
> 
> 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.

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.

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

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

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

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

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

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.

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

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.

> > 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.
> 
> All players that I've tested handle this correctly. Players always apply
> the header gain, then any other gain values on top of that.

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

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

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