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

Ron <ron@debian.org> Tue, 26 August 2014 13:06 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 7D4901A6FF2 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 06:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 r6XoE89FPic0 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 06:06:45 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id E9B8B1A6FEC for <codec@ietf.org>; Tue, 26 Aug 2014 06:06:43 -0700 (PDT)
Received: from ppp121-45-6-245.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.6.245]) by ipmail07.adl2.internode.on.net with ESMTP; 26 Aug 2014 22:36:43 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 5AC6EFFEA5 for <codec@ietf.org>; Tue, 26 Aug 2014 22:36:30 +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 PF9a85zh4YYZ for <codec@ietf.org>; Tue, 26 Aug 2014 22:36:29 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 99439FFD84 for <codec@ietf.org>; Tue, 26 Aug 2014 22:36:29 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 822C880470; Tue, 26 Aug 2014 22:36:29 +0930 (CST)
Date: Tue, 26 Aug 2014 22:36:29 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140826130629.GQ326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53FBC299.1070008@thaumas.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/-yUjBbkLgujHPiox1FPRvj2__D4
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: Tue, 26 Aug 2014 13:06:48 -0000

On Mon, Aug 25, 2014 at 04:11:21PM -0700, Ralph Giles wrote:
> 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
> guidance.
> 
> >>   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.

Yes, I agree that part stands as a sensible MUST.  About the only thing
I could niggle about there might be s/update/correct/, but I don't
personally think it's unclear what that indicates you should do or why
(though I'm probably too close to this to be a good judge of that for
other readers).  And if we say 'correct' we might need a few words on,
or a simple example of, what 'correct' actually is.


> >> + 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:

I couldn't really decide whether that ought to be normative or not,
mostly because I couldn't draw a useful distinction between "you
SHOULD assume this because the standard says so" and "you should
assume this because it's about the only sensible thing you can".

Either way what we're really saying is "unless you have a good
reason to believe otherwise, this is what you should expect",
which fits with both normative and 'ordinary' use.

(partly that question was in the context of us having a few other
non-normative keywords we need to clean up still, I don't feel
strongly about it going either way here)


> "By default, implementations of this specification MUST respect the
> 'output gain' field, but MAY NOT respect the comments.

I'd be inclined to drop the "By default" there, unless we're going
to expand on what the exceptions to the 'default' might be.

> Encoder authors are advised to take this into account.

In which case the normative language probably makes that sentence
redundant.

> 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."

Should the example there be ALBUM_GAIN rather than track gain
(consistent with what we recommended before these changes, and
with what is probably preferred in the absence of finer grained
recalibration)?

Maybe s/it's more reliable/it would be more robust/ ?
(the distinction I see there being between what real apps
_actually_ do in practice now and in the future, and what
the standard guarantees you as being baseline support ...
I don't have data on which is really more reliable, but I
can tell you what the standard guarantees is most likely).

But yes, I think that addresses the missing context I saw,
assuming it doesn't also revert whatever it was Ian found
confusing to remove it in the first place :)

  Ron