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

Ian Nartowicz <flac@nartowicz.co.uk> Mon, 08 September 2014 15:46 UTC

Return-Path: <flac@nartowicz.co.uk>
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 C2FE01A8877 for <codec@ietfa.amsl.com>; Mon, 8 Sep 2014 08:46:06 -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 P4_s6ijZNy6a for <codec@ietfa.amsl.com>; Mon, 8 Sep 2014 08:46:05 -0700 (PDT)
Received: from know-smtprelay-omc-7.server.virginmedia.net (know-smtprelay-omc-7.server.virginmedia.net [80.0.253.71]) by ietfa.amsl.com (Postfix) with ESMTP id 14C001A8869 for <codec@ietf.org>; Mon, 8 Sep 2014 08:46:04 -0700 (PDT)
Received: from crunchbang ([81.103.170.84]) by know-smtprelay-7-imp with bizsmtp id ofm31o00o1pcAUZ01fm33w; Mon, 08 Sep 2014 16:46:04 +0100
X-Originating-IP: [81.103.170.84]
X-Spam: 0
X-Authority: v=2.1 cv=cpwVkjIi c=1 sm=1 tr=0 a=bYNBYWS+Sj0o/bRbN9Xjqw==:117 a=bYNBYWS+Sj0o/bRbN9Xjqw==:17 a=KEKbkQfv9EEA:10 a=ud0LK1MCnV8A:10 a=RoPK8JaNmp0A:10 a=kj9zAlcOel0A:10 a=hU221NPEAAAA:8 a=k5tU_nt-SUti6MfviC0A:9 a=FWZkCIvD01mszB-3:21 a=Vc-Cv0Jhs0K3inSM:21 a=CjuIK1q_8ugA:10
Date: Mon, 8 Sep 2014 16:46:02 +0100
From: Ian Nartowicz <flac@nartowicz.co.uk>
To: codec@ietf.org
Message-ID: <20140908164602.2320a8c1@crunchbang>
In-Reply-To: <20140907203345.GA326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE0054.5080207@thaumas.net> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> <20140907203345.GA326@hex.shelbyville.oz>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; i486-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/ceRi5LzQ-UpVvT0ObwqE-szoH78
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: Mon, 08 Sep 2014 15:46:06 -0000

>But this part:
>
>> 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."
>
>Possibly needs to give some slightly different advice, at least for the
>case where R128 normalisation is something that someone retrofits to
>a recording that was previously mastered to some acceptable level, to
>avoid actually losing useful information about the original in that case.
>
>Does that seem like it would cover what you're worried about?
>
>Do you have some proposed language for what you'd like us to recommend
>people do if they want to retrofit R128 normalisation to recordings?

I hadn't considered language that goes any further than leaving the issue
unspecified.  Actively encouraging encoders not to put R128 gains into the
output gain field seems to go directly against a key design goal for Opus.
Although I'd be happy to see this particular case recognised, do we want to to
second-guessing users and filling the spec with exceptions?

In an ideal world I'd still like to see a solution that produces normalised
output by default for all players, with sufficient information for more
advanced players to "de-normalise" out a specific R128 gain when needed.

--ian