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

Ron <> Thu, 08 November 2012 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA75021F8A14 for <>; Wed, 7 Nov 2012 19:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nu-8lJDwkjNP for <>; Wed, 7 Nov 2012 19:53:11 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by (Postfix) with ESMTP id 04BBA21F88E9 for <>; Wed, 7 Nov 2012 19:53:10 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJQrm1B5LW4k/2dsb2JhbABEw2qBCYIeAQEEATocFgoDBQsLGC4UGA0kiBcFvR+MDYVmYQOODodsAZBEgwI
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 08 Nov 2012 14:23:08 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 4E4564F8F3; Thu, 8 Nov 2012 14:23:06 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id jQANq66nJWQG; Thu, 8 Nov 2012 14:23:05 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 86B4A4F902; Thu, 8 Nov 2012 14:23:05 +1030 (CST)
Date: Thu, 8 Nov 2012 14:23:05 +1030
From: Ron <>
To: Calvin Walton <>
Message-ID: <20121108035305.GE6812@audi.shelbyville.oz>
References: <1352307794.14547.30.camel@ayu> <> <1352328081.14547.82.camel@ayu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1352328081.14547.82.camel@ayu>
User-Agent: Mutt/1.5.20 (2009-06-14)
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: Thu, 08 Nov 2012 03:53:12 -0000

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

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

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