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

Gregory Maxwell <gmaxwell@juniper.net> Mon, 26 November 2012 16:33 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 BB00621F86BB for <codec@ietfa.amsl.com>; Mon, 26 Nov 2012 08:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 67XCyRQ17ARb for <codec@ietfa.amsl.com>; Mon, 26 Nov 2012 08:33:28 -0800 (PST)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 5B42A21F85C2 for <codec@ietf.org>; Mon, 26 Nov 2012 08:33:24 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKULOZ0b3HopZ/n5bb5PY4aY0PUNPmx6+9@postini.com; Mon, 26 Nov 2012 08:33:27 PST
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 26 Nov 2012 08:31:11 -0800
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 26 Nov 2012 08:31:10 -0800
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Nov 2012 08:37:40 -0800
Received: from mail185-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Mon, 26 Nov 2012 16:30:50 +0000
Received: from mail185-co1 (localhost [127.0.0.1]) by mail185-co1-R.bigfish.com (Postfix) with ESMTP id C16EF8C03F0 for <codec@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Mon, 26 Nov 2012 16:30:50 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -3
X-BigFish: PS-3(zz98dI179dNzz1de0h1202h1d1ah1d2ahzz17326ah8275dhz2dh2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h)
Received: from mail185-co1 (localhost.localdomain [127.0.0.1]) by mail185-co1 (MessageSwitch) id 1353947448964124_18096; Mon, 26 Nov 2012 16:30:48 +0000 (UTC)
Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.250]) by mail185-co1.bigfish.com (Postfix) with ESMTP id CFE329E00CB; Mon, 26 Nov 2012 16:30:48 +0000 (UTC)
Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 26 Nov 2012 16:30:25 +0000
Received: from CH1PRD0511MB432.namprd05.prod.outlook.com ([169.254.4.18]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0239.002; Mon, 26 Nov 2012 16:30:24 +0000
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Calvin Walton <calvin.walton@kepstin.ca>
Thread-Topic: [codec] OggOpus: Rational for excluding replaygain tags?
Thread-Index: AQHNvQnvBoegpuVZ4E2cm3ibvkK3tJfexXamgAAyeoCAHXDy/g==
Date: Mon, 26 Nov 2012 16:30:24 +0000
Message-ID: <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com>
References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com>, <1352328081.14547.82.camel@ayu>
In-Reply-To: <1352328081.14547.82.camel@ayu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.238.2]
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
Cc: "codec@ietf.org" <codec@ietf.org>
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: Mon, 26 Nov 2012 16:33:28 -0000

Sorry for the delayed response— been tied up on other tasks.

Calvin Walton [calvin.walton@kepstin.ca] wrote:
> Hmm? Replaygain does specify a method. They go into a lot of details on
> http://www.replaygain.org/ to describe the loudness filter used, the
> method for calculating RMS power levels afterwards, the histogram-based
> statistical processing, and how to calibrate the gain level to the -83dB
> reference with a pink noise signal.

It offers one, yes— but it's not a specification. I was stridently corrected by the author of replaygain when I made the same claim that you are.

I'm also advised that most tools are now using the EBU R128 method now in any case. And in practice the point is fairly moot as the values are effectively compatible on actual audio once the reference level.

> Yes, having the standard gain header that is supported by all decoders
> is nice - except for the case of playback of mixed file formats,
> particularly by an application that doesn't understand the gain tags in
> other formats. In those cases, the Opus files will be significantly
> quieter (assuming modern pop mastering...) than the other files, making
> them sound "worse" than files without gain applied.

I don't see how you can usefully make an argument here.  If you don't have gain adjustment (on the files or in the application) and you have files from various sources you will have various levels.

If you listen exclusively to commercially mastered loudness-war recordings then having gain adjustment on some files and not others would increase the level of the already existing inconsistency somewhat. But I don't see what more there is to do about that.  I can't abide by an argument that because Vorbis was previously broken all things forever must be broken.  Applying gain on OggOpus files has functionally identical behavior to aacgain/mp3gain with respect to this.

> I can do that; here's the CC attribution, non-commercial, share-alike
> track "Discipline" by Nine Inch Nails, with vorbis-style replaygain tags

I still can't reproduce on my system, but I've asked people to fix it and the next version of these tools shouldn't have the weird behavior any longer.

> The issue I see here is that the normalization method used for the value
> in the opus header output gain field is *not specified* currently. An

There is a recommendation, but it's not— and shouldn't be— a requirement.

> If a player blindly applies only the header output gain value, it has no
> knowledge of whether the output is loudness normalized or not.

I'd like to say that there should be an informative tag there to indicate whats being done. However: I'm absolutely sure it will be reliably set wrong, double so because other than displaying it as metadata there is simply nothing most software can do with the information. There would be little way for careless implementers to discover that they've gotten it wrong... and so the information would likely be worse than useless as it would just add complexity without concrete value.