Re: [codec] draft-ietf-codec-oggopus and "album" gain

Ian Nartowicz <> Mon, 08 September 2014 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2FE01A8877 for <>; Mon, 8 Sep 2014 08:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P4_s6ijZNy6a for <>; Mon, 8 Sep 2014 08:46:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 14C001A8869 for <>; Mon, 8 Sep 2014 08:46:04 -0700 (PDT)
Received: from crunchbang ([]) by know-smtprelay-7-imp with bizsmtp id ofm31o00o1pcAUZ01fm33w; Mon, 08 Sep 2014 16:46:04 +0100
X-Originating-IP: []
X-Spam: 0
X-Authority: v=2.1 cv=cpwVkjIi c=1 sm=1 tr=0 a=bYNBYWS+Sj0o/bRbN9Xjqw==:117 a=bYNBYWS+Sj0o/bRbN9Xjqw==:17 a=KEKbkQfv9EEA:10 a=ud0LK1MCnV8A:10 a=RoPK8JaNmp0A:10 a=kj9zAlcOel0A:10 a=hU221NPEAAAA:8 a=k5tU_nt-SUti6MfviC0A:9 a=FWZkCIvD01mszB-3:21 a=Vc-Cv0Jhs0K3inSM:21 a=CjuIK1q_8ugA:10
Date: Mon, 08 Sep 2014 16:46:02 +0100
From: Ian Nartowicz <>
Message-ID: <20140908164602.2320a8c1@crunchbang>
In-Reply-To: <20140907203345.GA326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <> <20140816040140.GA31682@hex.shelbyville.oz> <> <20140827153043.2ff5e031@crunchbang> <> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> <20140907203345.GA326@hex.shelbyville.oz>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; i486-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Sep 2014 15:46:06 -0000

>But this part:
>> Encoder authors are advised to
>> take this into account. For example, it is more robust for a
>> post-processing application to performing track normalization to update
>> the 'output gain' field and write a comment 'R128_TRACK_GAIN=0' than to
>> put the normalization value directly in the comment."
>Possibly needs to give some slightly different advice, at least for the
>case where R128 normalisation is something that someone retrofits to
>a recording that was previously mastered to some acceptable level, to
>avoid actually losing useful information about the original in that case.
>Does that seem like it would cover what you're worried about?
>Do you have some proposed language for what you'd like us to recommend
>people do if they want to retrofit R128 normalisation to recordings?

I hadn't considered language that goes any further than leaving the issue
unspecified.  Actively encouraging encoders not to put R128 gains into the
output gain field seems to go directly against a key design goal for Opus.
Although I'd be happy to see this particular case recognised, do we want to to
second-guessing users and filling the spec with exceptions?

In an ideal world I'd still like to see a solution that produces normalised
output by default for all players, with sufficient information for more
advanced players to "de-normalise" out a specific R128 gain when needed.