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

Ron <> Sun, 07 September 2014 16:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F41601A0667 for <>; Sun, 7 Sep 2014 09:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P4XEjOApsrpQ for <>; Sun, 7 Sep 2014 09:31:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 92E241A066D for <>; Sun, 7 Sep 2014 09:31:31 -0700 (PDT)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 08 Sep 2014 02:01:30 +0930
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id C806FFFD70 for <>; Mon, 8 Sep 2014 02:01:27 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id pamRkyDL-wOe for <>; Mon, 8 Sep 2014 02:01:27 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 0C640FFD63 for <>; Mon, 8 Sep 2014 02:01:27 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EB81B80470; Mon, 8 Sep 2014 02:01:26 +0930 (CST)
Date: Mon, 08 Sep 2014 02:01:26 +0930
From: Ron <>
Message-ID: <20140907163126.GZ326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <> <20140816040140.GA31682@hex.shelbyville.oz> <> <20140827153043.2ff5e031@crunchbang> <> <20140827212655.GW326@hex.shelbyville.oz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140827212655.GW326@hex.shelbyville.oz>
User-Agent: Mutt/1.5.23 (2014-03-12)
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: Sun, 07 Sep 2014 16:31:34 -0000

On Thu, Aug 28, 2014 at 06:56:55AM +0930, Ron wrote:
> On Wed, Aug 27, 2014 at 08:59:16AM -0700, Ralph Giles wrote:
> > 
> > "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."
> s/to performing/performing/ ?  Or maybe "that is performing"?
> But yeah, modulo whatever still seems to be misleading Ian,
> that seems about right to me.

So I believe this is now the last outstanding question from the last
call comments that we still have open.

There were some concerns raised about this wording, but my questions
about exactly what the problem Ian had with it was have so far gone
unanswered, which makes it a bit tricky to try to address whatever
they really were, and I haven't seen a proposed alternative wording
that covers the problem Ralph and I saw with the initial proposed
edit leaving it without a rationale (which this version tried to fix).

So if someone still thinks this says something that it shouldn't, or
isn't properly clear about what it does say, could you please give
us a sufficient explanation of that so we can understand and fix the
problem, or propose an alternative wording that you think does which
we can discuss.

Otherwise, this is so far the closest to what I think was originally
intended that we have on the table to accept.

If we get this one out of the way now, I think we're nearly done.