Re: [codec] OggOpus: Rational for excluding replaygain tags?

Gregory Maxwell <gmaxwell@juniper.net> Wed, 07 November 2012 19:57 UTC

Return-Path: <gmaxwell@juniper.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF821F8CA1 for <codec@ietfa.amsl.com>; Wed, 7 Nov 2012 11:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzCpn0R3otL1 for <codec@ietfa.amsl.com>; Wed, 7 Nov 2012 11:57:34 -0800 (PST)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5721F8C9B for <codec@ietf.org>; Wed, 7 Nov 2012 11:57:34 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUJq9LZ+AMLHGkLkL2My1gMOSeezadYve@postini.com; Wed, 07 Nov 2012 11:57:34 PST
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 7 Nov 2012 11:49:03 -0800
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 7 Nov 2012 11:47:12 -0800
Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Nov 2012 11:53:40 -0800
Received: from mail27-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Wed, 7 Nov 2012 19:46:37 +0000
Received: from mail27-ch1 (localhost [127.0.0.1]) by mail27-ch1-R.bigfish.com (Postfix) with ESMTP id 39823300124 for <codec@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Wed, 7 Nov 2012 19:46:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: 3
X-BigFish: PS3(zz98dIzz1de0h1202h1d1ah1d2ahzzz2dh2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h)
Received: from mail27-ch1 (localhost.localdomain [127.0.0.1]) by mail27-ch1 (MessageSwitch) id 1352317595730719_17827; Wed, 7 Nov 2012 19:46:35 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail27-ch1.bigfish.com (Postfix) with ESMTP id 9E74C2015C; Wed, 7 Nov 2012 19:46:35 +0000 (UTC)
Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 7 Nov 2012 19:46:35 +0000
Received: from CH1PRD0511MB432.namprd05.prod.outlook.com ([169.254.4.82]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0233.002; Wed, 7 Nov 2012 19:46:34 +0000
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Calvin Walton <calvin.walton@kepstin.ca>, "codec@ietf.org" <codec@ietf.org>
Thread-Topic: [codec] OggOpus: Rational for excluding replaygain tags?
Thread-Index: AQHNvQnvBoegpuVZ4E2cm3ibvkK3tJfexXam
Date: Wed, 7 Nov 2012 19:46:34 +0000
Message-ID: <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com>
References: <1352307794.14547.30.camel@ayu>
In-Reply-To: <1352307794.14547.30.camel@ayu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.224.54]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%KEPSTIN.CA$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Subject: Re: [codec] OggOpus: Rational for excluding replaygain tags?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 07 Nov 2012 19:57:35 -0000

Calvin Walton [calvin.walton@kepstin.ca] wrote:
> While I don't see any technical problems with R128 - it is a good volume
> normalization scheme - the issue is that it is a *different*
> normalization scheme from the replaygain tags that are supported in

Replay gain does not specify a method for measuring the level. The R128 measurement technique is, in fact, being used in place of te older replay-gain in many places and I wouldn't be surprised if it were actually the most popular of the two then.   With that in mind the only difference between the two values is the specified meaning and a constant scaling factor for the different reference levels.   So it's trivial to make software that that can play a mixture of OggOpus and replaygain vorbis with the expected constant levels.

> other audio formats - it gives different results, and isn't directly
> interoperable, and isn't supported by many existing players.

Replaygain itself has very spotty support.

This means that if you create a file with replaygain tags it will have _wildly_ different playback levels depending on which player you use.   So any content distributor can simply not use it if they care about things working consistently at all.  The only place it works reliably is on your own files... and well, if thats all you care about interoperability isn't much of an issue.

One of the major motivations behind how this this is address in OggOpus is that we have the gain header field that gives a default playback gain. This works in all existent players... and it allows consistent behavior.  And it is supported by every single existing decoder that I'm aware of.

> I've done a survey of existing player applications with Ogg Opus
> support. All of these players:
> * Rockbox (development version with Opus support)
> * GStreamer-based (e.g. Rhythmbox)
> will use the REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags (as
> specified in Vorbis) to apply replaygain to Opus tracks. Both Rockbox

Can you give me a link to a test file— I tried and it isn't for me.

> and Gstreamer-based players will first apply the stream header's output
> gain field prior to applying the replaygain correction; I haven't
> checked foobar2000 on that point.

Well thats good.

> Of the players in that list, only foobar2000 supports the R128 gain tag.
> I am not sure what happens if both tags are present.

Thats not correct. The way the spec is constructed and apps are implemented gain works fine _without_ supporting the tag.  It basically make it work by default. And I think this is a massive improvement which would be broken by reintroducing the widespread inconsistency of replaygain.

Make sense?