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

"Timothy B. Terriberry" <> Thu, 14 August 2014 17:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 763961A6F82 for <>; Thu, 14 Aug 2014 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sZKigNTqCVJk for <>; Thu, 14 Aug 2014 10:24:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F9371A02CF for <>; Thu, 14 Aug 2014 10:24:50 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 87A99F251D for <>; Thu, 14 Aug 2014 10:24:49 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2014 10:24:48 -0700
From: "Timothy B. Terriberry" <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
References: <20140813222201.54fe7910@crunchbang>
In-Reply-To: <20140813222201.54fe7910@crunchbang>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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: Thu, 14 Aug 2014 17:24:52 -0000

To capture the reasoning behind these changes...

Ian Nartowicz wrote:
> In section 5.1:
>          Virtually all players and media frameworks should apply it by
> -       default.  If a player chooses to apply any volume adjustment or
> -       gain modification, such as the R128_TRACK_GAIN, R128_ALBUM_GAIN
> -       (see Section 5.2) or a user-facing volume knob, the adjustment
> -       MUST be applied in addition to this output gain in order to
> -       achieve playback at the desired volume.
> +       default.  If a player chooses to apply any gain modification,
> +       such as the R128_TRACK_GAIN or R128_ALBUM_GAIN (see Section 5.2),
> +       the adjustment MUST be applied in addition to this output
> +       gain in order to achieve playback at the normalised volume.

Ian felt that including the volume knob example made this text unclear. 
The new text makes it explicit that 'output gain' + R128_TACK_GAIN or 
'output gain' + R128_ALBUM_GAIN gives you _normalized_ volume (as 
defined by EBU R128), which may or may not have any relation to "desired 
volume". I don't think we need to be in the business of telling players 
how to implement a volume knob, so taking the example out seemed best.

> In section 5.2.1:
> -   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
> +   The encoder should assume that by default tools
>      will respect the 'output gain' field, and not the comment tag.  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

This was causing confusion because it suggested that an encoder should 
_always_ prefer to put the track gain into the 'output gain' field. In 
reality we used to have text saying that using the album gain for 
'output gain' was preferred, and this was just an alternative (the 
leading "If" clause being the the important part of the sentence, not 
the SHOULD). However, this sentence is entirely redundant with the text 
from the definition of the 'output gain' field: "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." Removing 
the sentence avoids the confusion.

I've applied both sets of changes locally (using "An encoder" instead of 
"The encoder"), and they'll be included in the next update (after WGLC).

I also moved the "assume by default" sentence to the end of the 
paragraph and removed the preceding paragraph break, as the warning 
about being required to update the tags when the header value changes 
now logically follows from the declaration that these tags are relative 
to that field.