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

Ralph Giles <> Wed, 27 August 2014 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3C6F1A0B02 for <>; Wed, 27 Aug 2014 08:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0sm2-4NbMCIy for <>; Wed, 27 Aug 2014 08:59:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1162D1A0AF8 for <>; Wed, 27 Aug 2014 08:59:17 -0700 (PDT)
Received: by with SMTP id rd18so530010iec.0 for <>; Wed, 27 Aug 2014 08:59:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KB5CgnwpQyF8eJAj2AKvxmxkRqjDhh6DLC79zITKdso=; b=QQxeplmQbv4Ni60Kl34hS0VWxe+nwkSfS2RGUEZJM/zRPKbq2hobmxVlgd9B1GPqlS mXBYBiXBPsjAL+fqaluA9KpML2fqJnrsp7UtvlTI7P+3YsDej8GjOiFLXp+hXbZrGj3B 9V4vXTp9Fh2esxvt7REKPnArMjLifSKg+Dpg6qYLTb7RKyMelpsTuLGZbMTSpgGWs6iz zBZc5Lu8Ge3+av5moLZilFxwW0laerB1tl9DkjD8C7hDlHJ77HBzIwqGcCxXfRcyD6g3 3YFHHOMrOB/N9uTuSWAEIvIjB165+NsPoB9t/tM+2ZndD7pNmyh1rqlZIwhjMWFyKSdn EvBw==
X-Gm-Message-State: ALoCoQldK1rolOGWVtltbQqJSwbbb9QNENVSR5AsD37sb75qfqyXQDp5v8RhtAjuwxsZmbasLluJ
X-Received: by with SMTP id vr6mr3051499icb.74.1409155156495; Wed, 27 Aug 2014 08:59:16 -0700 (PDT)
Received: from tamias.local ( []) by with ESMTPSA id rr3sm4546802igb.19.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 08:59:15 -0700 (PDT)
Message-ID: <>
Date: Wed, 27 Aug 2014 08:59:16 -0700
From: Ralph Giles <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ian Nartowicz <>,
References: <20140813222201.54fe7910@crunchbang> <> <20140816040140.GA31682@hex.shelbyville.oz> <> <20140827153043.2ff5e031@crunchbang>
In-Reply-To: <20140827153043.2ff5e031@crunchbang>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
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: Wed, 27 Aug 2014 15:59:19 -0000

On 2014-08-27 7:30 AM, Ian Nartowicz wrote:

> This seems like a step backwards to me.  That MUST is a requirement
> that wasn't present before.  An earlier statement is "Virtually all players
> and media frameworks should apply it by default.", which I think is the
> appropriate guidance.

That's another one of those non-normative 'should' clauses we'd like to
resolve. The intention was that players MUST apply the gain; the
exception was for things like transcoders or DAW systems which could
propagate the gain without altering the decoded data. Can you think of

I was trying to clarify that here, while leaving similar wiggle room in
the word 'respect'.

>> Is there a reason we shouldn't just have two examples?

Only brevity. The previous example used album gain because it was
offering guidance on how to record album gain in the absence of an
R128_ALBUM_GAIN tag. I switched to track gain because I thought that was
the more common normalization.

"Implementations of this specification MUST respect the 'output gain'
field, but MAY NOT respect the comments. 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."