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

Calvin Walton <> Tue, 27 November 2012 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98C7121F85A4 for <>; Tue, 27 Nov 2012 08:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.994
X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 242GdPN8n5Zc for <>; Tue, 27 Nov 2012 08:53:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 469C421F85C5 for <>; Tue, 27 Nov 2012 08:53:05 -0800 (PST)
Received: by with SMTP id c13so12106413ieb.31 for <>; Tue, 27 Nov 2012 08:53:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=sY6pz/a/DVcVkSAzmw9D5ORPVN0KY1vqZvwurXkIVKo=; b=U2fvFdOtEN1kjzz9A4XaJ1130G+Af57BegsjYtGx7xUhyisXNyKZTZeUAjl8LXXBXH 3pu7bdtiqEoydfbpFiAfjuFHl2SjMOho54MTdf/dBLxfq0vWFAav/0OzRj4aaHg+2KQb x1yblkY3bgghmIbIV48en9afIWIX+Y0pA7URc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=sY6pz/a/DVcVkSAzmw9D5ORPVN0KY1vqZvwurXkIVKo=; b=mUoxbawmxHaMgBo089QG6+kORNeuDLru9oAQ7dJM/DTtvt5g00b0Q9U7aYl0ihrtUz Y3Wm1ttnIQ09CWOo1G2BJcxq5WL0H9fRTYvxIcPitHXYOnHjdHjLT5EWRv/SWeQUh19n chfgxuBVcbd1e5H0M0c+cBghOczn/CNxjIoxc1lwKG1AiVm3Awcws0yeHjzoiijoaEko kDAMeMnbmvQRpn+AKYcRU1lpRzPRijRU0uQMNN2E7yUHo2MZNY0baf2YELKuunODlQgQ G6zmmZiOFVy4bXcWTRGRBFrqCKqVHs+UgAp/yrz01bNPkMCEeFmYFhibsd78CvokdrnO yy5w==
Received: by with SMTP id c1mr18625862igj.67.1354035184826; Tue, 27 Nov 2012 08:53:04 -0800 (PST)
Received: from [] ( []) by with ESMTPS id xn10sm1951067igb.4.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 08:53:03 -0800 (PST)
Message-ID: <1354035181.10253.88.camel@ayu>
From: Calvin Walton <>
To: Ron <>
Date: Tue, 27 Nov 2012 11:53:01 -0500
In-Reply-To: <20121127120838.GJ2043@audi.shelbyville.oz>
References: <1352307794.14547.30.camel@ayu> <> <1352328081.14547.82.camel@ayu> <> <> <20121127075909.GH2043@audi.shelbyville.oz> <1354009968.10253.55.camel@ayu> <20121127120838.GJ2043@audi.shelbyville.oz>
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-iC6FbjE7FmVoHxrKUyzi"
X-Mailer: Evolution 3.6.0
Mime-Version: 1.0
X-Gm-Message-State: ALoCoQmiq32IQ/ipCXyxWFtlURTnEeCsb6W+p9REL8I7nFkcnDETIOWZKaGjZrhwPojLftxtY8vL
Subject: Re: [codec] OggOpus: Rational for excluding replaygain tags?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Nov 2012 16:53:07 -0000

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

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

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

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

Calvin Walton <>