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

Ralph Giles <> Mon, 25 August 2014 23:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3C701A0350 for <>; Mon, 25 Aug 2014 16:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S4xh7G6Phj0V for <>; Mon, 25 Aug 2014 16:12:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E52B01A046A for <>; Mon, 25 Aug 2014 16:11:22 -0700 (PDT)
Received: by with SMTP id w10so21293692pde.4 for <>; Mon, 25 Aug 2014 16:11:22 -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=mD3LGCLsVWpEqRf/oAVH/4a0RCuPwCSevN4jd5qGSsA=; b=Gdrf1glq+yAjQlcFZ5MCoL2etYXfi2lPWOwOClnwI/am4LX7XB76GByXUF4Dy52W2e RST9AYXuSJ+2tQk2+3UwPaBLiONZN4qCXa6COLS8F/s1WuSJzqHmtTE8Z+yQgXQclWrg /YbLDj5tQpvlr6nH2hS1fc6ZKOw2Vu/2mKwkj0zRUeEq2dWIz/eQ/S4DH4pxogDCU93z MPAdr1cMGawDn8PqFHp+Kd8qM/4QRYnhykXOtluS4Q7atopYxovsTp1daDtaD/NfWo8n jHf9TkU1H5gZK3409gG7IMgTcEmCG4Uw/6XLb2+pikzasY8EX/aHZYE+1Kjx7IH+vBui 9HUQ==
X-Gm-Message-State: ALoCoQnui9vuytRh9mbQMxZQIrQhAs5MAov8cHWw3F+7ayDKEQ9//cfP7gWvaaHl+ST1pKH+jJIn
X-Received: by with SMTP id a3mr32742857pbu.94.1409008282636; Mon, 25 Aug 2014 16:11:22 -0700 (PDT)
Received: from tamias.local ([]) by with ESMTPSA id g7sm1579708pdj.7.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 16:11:21 -0700 (PDT)
Message-ID: <>
Date: Mon, 25 Aug 2014 16:11:21 -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
References: <20140813222201.54fe7910@crunchbang> <> <20140816040140.GA31682@hex.shelbyville.oz>
In-Reply-To: <20140816040140.GA31682@hex.shelbyville.oz>
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: Mon, 25 Aug 2014 23:12:28 -0000

On 2014-08-15 9:01 PM, Ron wrote:

> So the patch applied for this part is now:
>> - If an encoder wishes to use R128 normalization, and the output gain is not
>> - otherwise constrained or specified, the encoder SHOULD write the R128 gain
>> - into the 'output gain' field and store a tag containing "R128_TRACK_GAIN=0".
>> - That is, it should assume that by default tools will respect the 'output gain'
>> - field, and not the comment tag.

I agree this part is confusing. I think it's too terse to offer good

>>   If a tool modifies the ID header's 'output gain' field, it MUST also update or
>>   remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present.

This seems helpful in avoiding broken files.

>> + An encoder should assume that by default tools will respect the 'output gain'
>> + field, and not the comment tag.

I read this as a non-normative should. Would it be better:

"By default, 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, to produce R128
normalized files it's more reliable for post-processing application to
update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
than to put the normalized value directly in the comment."

This removes the normative suggestion of 'should' while maintaining the
suggestion and rationale.