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

Ron <ron@debian.org> Sat, 16 August 2014 04:01 UTC

Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630421A0714 for <codec@ietfa.amsl.com>; Fri, 15 Aug 2014 21:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAQOYOjh1ym0 for <codec@ietfa.amsl.com>; Fri, 15 Aug 2014 21:01:45 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12C1A6F1B for <codec@ietf.org>; Fri, 15 Aug 2014 21:01:45 -0700 (PDT)
Received: from ppp14-2-60-85.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.60.85]) by ipmail05.adl6.internode.on.net with ESMTP; 16 Aug 2014 13:31:44 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 36F15FFF50 for <codec@ietf.org>; Sat, 16 Aug 2014 13:31:41 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2eG68Rc8geJq for <codec@ietf.org>; Sat, 16 Aug 2014 13:31:40 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 79AB0FFD70 for <codec@ietf.org>; Sat, 16 Aug 2014 13:31:40 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 6810380470; Sat, 16 Aug 2014 13:31:40 +0930 (CST)
Date: Sat, 16 Aug 2014 13:31:40 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140816040140.GA31682@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53ECF0E0.9060308@xiph.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/Tr5onUzbKd8ojMrIkhMFyYrhCaU
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 04:01:48 -0000

On Thu, Aug 14, 2014 at 10:24:48AM -0700, Timothy B. Terriberry wrote:
> >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.

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

And I wonder two things about it:

Is that intended to be "An encoder SHOULD assume"?

And if we do want this to be normative, do we need to expand a little on
what 'tools' and 'respect' means there - since that's possibly now less
clear as a statement which stands on its own, rather than a(n intended)
clarification to the text that is being removed.

I agree with the rationale of what's intended by this change, but I'm
less sure if it's now clear to a first time reader whether 'tools'
includes both players and editors, and under what conditions the
assumptions about 'default behaviour' will apply (since if we have the
comment tags, obviously *something* might respect them sometimes).

If we're going to give (normative) guidance there, it possibly wants
to be a little more specific about what exactly it applies to.

  Ron