[codec] OggOpus: Rational for excluding replaygain tags?

Calvin Walton <calvin.walton@kepstin.ca> Wed, 07 November 2012 17:03 UTC

Return-Path: <calvin.walton@kepstin.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 28CF221F8C34 for <codec@ietfa.amsl.com>; Wed, 7 Nov 2012 09:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PbFR+6IMWpoF for <codec@ietfa.amsl.com>; Wed, 7 Nov 2012 09:03:27 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id C07AC21F8C30 for <codec@ietf.org>; Wed, 7 Nov 2012 09:03:18 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so3047384iec.31 for <codec@ietf.org>; Wed, 07 Nov 2012 09:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:date:content-type:x-mailer:mime-version; bh=iuqC928pOS5YHll+Bg/gpYeiC07ZPLTNUZFUQoGwS7k=; b=V9/T5enX+TSDSxpj6EIyvKDlC7t19IJMUrvv4NBLG9PlY5wtXOXtJYUfwgaQYmspo2 tpsbeQ6us/yUuRTMNJRwoGmzKwhTOOx0xe0c/Xn/4lSM7CtKXDC9Eq+N7lhvM2ZdaUOd CzD5rF+7Vhz/b37NDVyWARRnzWW3dQPugiu1U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:date:content-type:x-mailer:mime-version :x-gm-message-state; bh=iuqC928pOS5YHll+Bg/gpYeiC07ZPLTNUZFUQoGwS7k=; b=WBgr45OXPGhhuS5T1gc+UMhQGfP7O0KaihgeCLUSErfG2/TiOrnBeIQFlm+tP9kife K7MOL7soyFVw8NDFX1Vlj6NUaLE8q2LvG8i1ARwdUPXpB2EcvzjBupWPbS0xQbix3TO/ i6nW1pYCSKrSsKUFTMwXF0KydI7jPq4YcbZj4FD7iits5SuGvOquakHgvcbt3Sz6ngnL QWaNRT1fn00Xtnb0fL1HLVwHxO6s7A0peVQ8aSRFQ6gyz+Xl33/GDVNyWfFHCST1HFeZ P09SmN7uai9JbiddqT3X6sMR/BivShGuV8HDWDh2jNluCBCnFah2CnDKYeWYz+bN5p6r 1aNA==
Received: by with SMTP id ut8mr5301569igc.20.1352307798167; Wed, 07 Nov 2012 09:03:18 -0800 (PST)
Received: from [] ([]) by mx.google.com with ESMTPS id 7sm2537955igh.0.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:03:17 -0800 (PST)
Message-ID: <1352307794.14547.30.camel@ayu>
From: Calvin Walton <calvin.walton@kepstin.ca>
To: codec@ietf.org
Date: Wed, 07 Nov 2012 12:03:14 -0500
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-4OXNEyWl4XamVoXGHJ22"
X-Mailer: Evolution 3.6.0
Mime-Version: 1.0
X-Gm-Message-State: ALoCoQnTXHUtB3sVvArdAojnTDD3tmKpP7Zh/xgGOaFDPq5dYxoSx9HD/2jjQRovFqFQ8EtfnbkZ
Subject: [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 17:03:28 -0000

Hi everyone,

I've been going through draft-terriberry-oggopus-01, and I'm wondering
why this section is present:

   To avoid confusion with multiple normalization schemes, an Opus
   comment header SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN,

As an end-user, I'm considering using Opus for part of my music
collection. The rest of my collection (a mix of file formats including
MP3, Vorbis, FLAC, AAC) is all normalized using the replaygain standard.

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
other audio formats - it gives different results, and isn't directly
interoperable, and isn't supported by many existing players.

I've done a survey of existing player applications with Ogg Opus
support. All of these players:
* Rockbox (development version with Opus support)
* foobar2000
* GStreamer-based (e.g. Rhythmbox)
specified in Vorbis) to apply replaygain to Opus tracks. Both Rockbox
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.

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

I would suggest that instead of simply saying that the OggOpus file
SHOULD NOT contain the replaygain tags, it should say that they MAY be
present, and should specify how they are interpreted and applied (This
mainly would concern their relation to the stream "output gain").

I would however recommend that the files still SHOULD NOT have the
REPLAYGAIN_{TRACK,ALBUM}_PEAK tags, as Opus does not have a bit-accurate
decoder specified, and the peak values will also vary based on the
sample rate selected for decoding.

I'd appreciate any comments you have, I'm really curious as to why the
draft is recommending against the use of replaygain tags.

Calvin Walton <calvin.walton@kepstin.ca>