From internet-drafts@ietf.org Mon Nov 5 07:04:19 2012 Return-Path: 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 BA7FB21F84B9; Mon, 5 Nov 2012 07:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 gWjvryyX0ILX; Mon, 5 Nov 2012 07:04:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E221F849A; Mon, 5 Nov 2012 07:04:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105150419.16812.98377.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 07:04:19 -0800 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-results-02.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:04:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working Gro= up of the IETF. Title : Summary of Opus listening test results Author(s) : Christian Hoene Jean-Marc Valin Koen Vos Jan Skoglund Filename : draft-ietf-codec-results-02.txt Pages : 31 Date : 2012-11-05 Abstract: This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-results There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-results-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-results-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hoene@uni-tuebingen.de Mon Nov 5 07:15:37 2012 Return-Path: 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 E777421F8552 for ; Mon, 5 Nov 2012 07:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 2U0XKuaHVqFT for ; Mon, 5 Nov 2012 07:15:37 -0800 (PST) Received: from mx09.uni-tuebingen.de (mx09.uni-tuebingen.de [134.2.3.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1273421F8533 for ; Mon, 5 Nov 2012 07:15:36 -0800 (PST) Received: from ChristianHoene (dhcp-508e.meeting.ietf.org [130.129.80.142]) (authenticated bits=0) by mx09.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id qA5FFBRV027885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Nov 2012 16:15:24 +0100 From: "Hoene" To: References: <20121105150419.16812.98377.idtracker@ietfa.amsl.com> In-Reply-To: <20121105150419.16812.98377.idtracker@ietfa.amsl.com> Date: Mon, 5 Nov 2012 16:15:30 +0100 Message-ID: <012001cdbb68$6ccefdb0$466cf910$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNcQkaIhdpO6cgV4ATBGgn3yRRa/5S+S9Dw Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx09) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx09); id=32218-9JQMXP Subject: Re: [codec] I-D Action: draft-ietf-codec-results-02.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:15:38 -0000 Hi all, no new results so far :-( But still some good news, in the next weeks we will start some more = MUSHRA and complexity testing. More to come. With best regards, Christian -- Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel +49 7071 2970532, Fax +49 7071 5220 http://kn.inf.uni-tuebingen.de/staff/hoene.html -----Urspr=FCngliche Nachricht----- Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im Auftrag = von internet-drafts@ietf.org Gesendet: Montag, 5. November 2012 16:04 An: i-d-announce@ietf.org Cc: codec@ietf.org Betreff: [codec] I-D Action: draft-ietf-codec-results-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. Title : Summary of Opus listening test results Author(s) : Christian Hoene Jean-Marc Valin Koen Vos Jan Skoglund Filename : draft-ietf-codec-results-02.txt Pages : 31 Date : 2012-11-05 Abstract: This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-results There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-results-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-results-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jmvalin@mozilla.com Mon Nov 5 09:04:11 2012 Return-Path: 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 C80BA21F87E9 for ; Mon, 5 Nov 2012 09:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 lb6tbwB6cZ1r for ; Mon, 5 Nov 2012 09:04:05 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id A495A21F872A for ; Mon, 5 Nov 2012 09:04:05 -0800 (PST) Received: from [130.129.33.4] (dhcp-2104.meeting.ietf.org [130.129.33.4]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 36B15F230D; Mon, 5 Nov 2012 09:04:05 -0800 (PST) Message-ID: <5097F184.3010807@mozilla.com> Date: Mon, 05 Nov 2012 12:04:04 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hoene References: <20121105150419.16812.98377.idtracker@ietfa.amsl.com> <012001cdbb68$6ccefdb0$466cf910$@uni-tuebingen.de> In-Reply-To: <012001cdbb68$6ccefdb0$466cf910$@uni-tuebingen.de> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-results-02.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:04:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2012 10:15 AM, Hoene wrote: > But still some good news, in the next weeks we will start some more > MUSHRA and complexity testing. More to come. Just curious, who is "we"? Jean-Marc > With best regards, > > Christian > > > -- Universität Tübingen, Sand 13, 72076 Tübingen, Germany Tel +49 > 7071 2970532, Fax +49 7071 5220 > http://kn.inf.uni-tuebingen.de/staff/hoene.html > > -----Ursprüngliche Nachricht----- Von: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] Im Auftrag von > internet-drafts@ietf.org Gesendet: Montag, 5. November 2012 16:04 > An: i-d-announce@ietf.org Cc: codec@ietf.org Betreff: [codec] I-D > Action: draft-ietf-codec-results-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Internet Wideband > Audio Codec Working Group of the IETF. > > Title : Summary of Opus listening test results Author(s) > : Christian Hoene Jean-Marc Valin Koen Vos Jan Skoglund Filename > : draft-ietf-codec-results-02.txt Pages : 31 Date > : 2012-11-05 > > Abstract: This document describes and examines listening test > results obtained for the Opus codec and how they relate to the > requirements. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-codec-results > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-codec-results-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-codec-results-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ codec mailing list > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ codec mailing list > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQl/GAAAoJEJ6/8sItn9q9CVIH/1TDfJkv7OCfUq9k2YS1HfFA Tt1qUuOJGw0OjGlDAhjA+bg0HdHmHxwtvBZ13bxRUVsCKolszrtnAk9AsqPFj23x 20vkKfTUMnh7xKelwX665zsD/cAS9MOvS4Xwd+bwyp7r4DxLP2oCu5EQGn/vOJvZ tKERKh7cGHxTdSaRguGhxyJyzMoA5EZ2pl1rta+22JqNThX3IySQ+qy/Gdxh7JVZ oVedmfCrBJy9Y2HUeAZrbugXZX9EiP7f4G/19/0TYD/qUuZl3JKem3lNQkHT8jyl 9q3dtYBHw4rtRzZoAnfLPvdJD38WGzWHwAZjoWi0R3WsWbdt0Oe/Dx0lMB4arAo= =Ej0P -----END PGP SIGNATURE----- From hoene@uni-tuebingen.de Mon Nov 5 10:16:44 2012 Return-Path: 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 4C70821F892A for ; Mon, 5 Nov 2012 10:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 keFC3aisxVnC for ; Mon, 5 Nov 2012 10:16:43 -0800 (PST) Received: from mx09.uni-tuebingen.de (mx09.uni-tuebingen.de [134.2.3.2]) by ietfa.amsl.com (Postfix) with ESMTP id E8E9421F8937 for ; Mon, 5 Nov 2012 10:16:42 -0800 (PST) Received: from ChristianHoene (dhcp-508e.meeting.ietf.org [130.129.80.142]) (authenticated bits=0) by mx09.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id qA5IGBmW016092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Nov 2012 19:16:28 +0100 From: "Hoene" To: "'Jean-Marc Valin'" References: <20121105150419.16812.98377.idtracker@ietfa.amsl.com> <012001cdbb68$6ccefdb0$466cf910$@uni-tuebingen.de> <5097F184.3010807@mozilla.com> In-Reply-To: <5097F184.3010807@mozilla.com> Date: Mon, 5 Nov 2012 13:15:59 -0500 Message-ID: <001201cdbb81$b0efe720$12cfb560$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNcQkaIhdpO6cgV4ATBGgn3yRRa/wGsmC0aApEmS4mUnIuPsA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx09) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx09); id=32218-9Lqp5d Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-results-02.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:16:44 -0000 Hi Valin, we at University of T=FCbingen/Symonics. I am expecting about 100 = participants in the tests. Give me some more time to write down the testing plan. I = will be happy to read your comments then. The tests will focus on 1) Comparision with other codecs (similar to the graph on the Opus web = page but based on scientific correctly measured results). 2) Characterisation of Opus and its operational modes (including packet loss) Also, I am planning to measure the complexity of the codecs somehow. As the tests are not intended for the codec developers but for people outside of the IETF, I will focus on well standardized testing = procedures like MUSHRA and the guidelines given in "practical procedures of subjective testing" http://www.itu.int/opb/publications.aspx?media=3Delectronic&parent=3DT-HD= B-QOS.0 2-2011 Jean-Marc, there is no reason to be worried. We will just do some very transparent MUSHRA testing on use cases that are important for codec = users. But - of course - I cannot promise you that Opus will be best in every testing condition. See you today at the Video BOF? With best regards, Christian Hoene -- Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel +49 7071 2970532, Fax +49 7071 5220 http://kn.inf.uni-tuebingen.de/staff/hoene.html -----Urspr=FCngliche Nachricht----- Von: Jean-Marc Valin [mailto:jmvalin@mozilla.com]=20 Gesendet: Montag, 5. November 2012 12:04 An: Hoene Cc: codec@ietf.org Betreff: Re: [codec] I-D Action: draft-ietf-codec-results-02.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2012 10:15 AM, Hoene wrote: > But still some good news, in the next weeks we will start some more=20 > MUSHRA and complexity testing. More to come. Just curious, who is "we"? Jean-Marc > With best regards, >=20 > Christian >=20 >=20 > -- Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel = +49 > 7071 2970532, Fax +49 7071 5220 > http://kn.inf.uni-tuebingen.de/staff/hoene.html >=20 > -----Urspr=FCngliche Nachricht----- Von: codec-bounces@ietf.org=20 > [mailto:codec-bounces@ietf.org] Im Auftrag von=20 > internet-drafts@ietf.org Gesendet: Montag, 5. November 2012 16:04 > An: i-d-announce@ietf.org Cc: codec@ietf.org Betreff: [codec] I-D > Action: draft-ietf-codec-results-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the Internet Wideband Audio=20 > Codec Working Group of the IETF. >=20 > Title : Summary of Opus listening test results Author(s) > : Christian Hoene Jean-Marc Valin Koen Vos Jan Skoglund Filename > : draft-ietf-codec-results-02.txt Pages : 31 Date > : 2012-11-05 >=20 > Abstract: This document describes and examines listening test results=20 > obtained for the Opus codec and how they relate to the requirements. >=20 >=20 > The IETF datatracker status page for this draft is:=20 > https://datatracker.ietf.org/doc/draft-ietf-codec-results >=20 > There's also a htmlized version available at:=20 > http://tools.ietf.org/html/draft-ietf-codec-results-02 >=20 > A diff from the previous version is available at:=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-results-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at:=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ codec mailing list=20 > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec >=20 > _______________________________________________ codec mailing list=20 > codec@ietf.org https://www.ietf.org/mailman/listinfo/codec >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQl/GAAAoJEJ6/8sItn9q9CVIH/1TDfJkv7OCfUq9k2YS1HfFA Tt1qUuOJGw0OjGlDAhjA+bg0HdHmHxwtvBZ13bxRUVsCKolszrtnAk9AsqPFj23x 20vkKfTUMnh7xKelwX665zsD/cAS9MOvS4Xwd+bwyp7r4DxLP2oCu5EQGn/vOJvZ tKERKh7cGHxTdSaRguGhxyJyzMoA5EZ2pl1rta+22JqNThX3IySQ+qy/Gdxh7JVZ oVedmfCrBJy9Y2HUeAZrbugXZX9EiP7f4G/19/0TYD/qUuZl3JKem3lNQkHT8jyl 9q3dtYBHw4rtRzZoAnfLPvdJD38WGzWHwAZjoWi0R3WsWbdt0Oe/Dx0lMB4arAo=3D =3DEj0P -----END PGP SIGNATURE----- From jmvalin@jmvalin.ca Mon Nov 5 11:09:45 2012 Return-Path: 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 7DC7621F8BAF for ; Mon, 5 Nov 2012 11:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 Ij5oW2rFslTJ for ; Mon, 5 Nov 2012 11:09:44 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B121F8B5B for ; Mon, 5 Nov 2012 11:09:44 -0800 (PST) Received: from [130.129.33.4] (dhcp-2104.meeting.ietf.org [130.129.33.4]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4EEEEF260A; Mon, 5 Nov 2012 11:09:44 -0800 (PST) Message-ID: <50980EF7.1020507@jmvalin.ca> Date: Mon, 05 Nov 2012 14:09:43 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hoene References: <20121105150419.16812.98377.idtracker@ietfa.amsl.com> <012001cdbb68$6ccefdb0$466cf910$@uni-tuebingen.de> <5097F184.3010807@mozilla.com> <001201cdbb81$b0efe720$12cfb560$@uni-tuebingen.de> In-Reply-To: <001201cdbb81$b0efe720$12cfb560$@uni-tuebingen.de> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-results-02.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:09:45 -0000 Hi Christian, On 11/05/2012 01:15 PM, Hoene wrote: > we at University of Tübingen/Symonics. I am expecting about 100 participants > in the tests. Give me some more time to write down the testing plan. I will > be happy to read your comments then. I'll be happy to read your test plan. Note that if you really have 100 willing participants and are going to use MUSHRA, you can actually make many tests because MUSHRA typically only needs 10-20 listeners to produce statistically significant results. This would make it possible to actually help improve the existing implementation, as opposed to only adding one more data point. > As the tests are not intended for the codec developers but for people > outside of the IETF, I will focus on well standardized testing procedures > like MUSHRA and the guidelines given in > "practical procedures of subjective testing" > http://www.itu.int/opb/publications.aspx?media=electronic&parent=T-HDB-QOS.0 > 2-2011 About MUSHRA, I suggest you review the exact methodology because your previous test had issues with that. For example, your slides ( http://wiki.tools.ietf.org/wg/codec/trac/raw-attachment/wiki/TestingResults/summary.pdf ) indicated "Participants were not informed about the presence of hidden references" which goes against the MUSHRA methodology. Cheers, Jean-Marc From jdrosen@jdrosen.net Tue Nov 6 09:45:40 2012 Return-Path: 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 240C721F8A86 for ; Tue, 6 Nov 2012 09:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 4cH+arqThPM7 for ; Tue, 6 Nov 2012 09:45:37 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id 90A0021F8A27 for ; Tue, 6 Nov 2012 09:45:37 -0800 (PST) Received: from mail-wi0-f178.google.com ([209.85.212.178]:58653) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1TVnDU-00059j-KE for codec@ietf.org; Tue, 06 Nov 2012 12:45:36 -0500 Received: by mail-wi0-f178.google.com with SMTP id hr7so584647wib.13 for ; Tue, 06 Nov 2012 09:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.134.140 with SMTP id s12mr846848wei.105.1352223935941; Tue, 06 Nov 2012 09:45:35 -0800 (PST) Received: by 10.227.227.84 with HTTP; Tue, 6 Nov 2012 09:45:35 -0800 (PST) Date: Tue, 6 Nov 2012 12:45:35 -0500 Message-ID: From: Jonathan Rosenberg To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636ed6d205bcca804cdd72b39 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [codec] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:45:40 -0000 --001636ed6d205bcca804cdd72b39 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We've still got two items left on our charter to complete - a container format and the testing document. Cullen, Tim and myself met yesterday during IETF and discussed these. For the container format, we'd like to see if there is consensus to adopt http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text=1 as a working group item. Please let us know what you think by the end of this week. Thanks, Jonathan (as co-chair) -- Jonathan Rosenberg, Ph.D. GM Product Strategy and Research, Microsoft/Skype jdrosen@{skype.net,jdrosen.net,microsoft.com} http://www.jdrosen.net --001636ed6d205bcca804cdd72b39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,
=A0
We've still got two items left o= n our charter to complete - a container format and the testing document. Cu= llen, Tim and myself met yesterday during IETF and discussed these. For the= container format, we'd like to see if there is consensus to adopt http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_t= ext=3D1=A0as a working group item. Please let us know what you think by= the end of this week.
=A0
Thanks,
Jonathan
(as co-chair)

--
Jonathan Rosenberg, Ph.D.
GM Product Strategy and= Research, Microsoft/Skype
jdrosen@{skype.net,= jdrosen.net,microsof= t.com}
http://www.jdrosen.net=
--001636ed6d205bcca804cdd72b39-- From jmvalin@mozilla.com Tue Nov 6 10:16:29 2012 Return-Path: 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 40EAA21F8A0F for ; Tue, 6 Nov 2012 10:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 R5XFef9LkH3t for ; Tue, 6 Nov 2012 10:16:27 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4C21F8958 for ; Tue, 6 Nov 2012 10:16:27 -0800 (PST) Received: from [130.129.33.4] (dhcp-2104.meeting.ietf.org [130.129.33.4]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 43BDEF232C; Tue, 6 Nov 2012 10:16:27 -0800 (PST) Message-ID: <509953FA.2080500@mozilla.com> Date: Tue, 06 Nov 2012 13:16:26 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jonathan Rosenberg References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:16:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2012 12:45 PM, Jonathan Rosenberg wrote: > We've still got two items left on our charter to complete - a > container format and the testing document. Cullen, Tim and myself > met yesterday during IETF and discussed these. For the container > format, we'd like to see if there is consensus to adopt > http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text=1 > as a working group item. Please let us know what you think by the > end of this week. I support that. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQmVP3AAoJEJ6/8sItn9q9N/cH/Au2Cdk0Oy9IsWIy2WOpQq1D b4YfYpuHDTXzWk8dTDgFUUUZWuzfech+VNrVRthZJ5tL7utsNMJ92lk/aEnXHmBx OoGid8EbFJeImYdTo6/SRoc5YGJgR1EpjrIvfQICaPYFALAfrk9yLXqwd+7+PGpb FwmR/YXpiER7SMEn0bfCTFd3AsdAj/vLc8kgi6rpndKmV0zX9koK1b2cgb5uLWFt W/MYRfQNR8kGX1EaFqhgAt7RRKpNRsD3GfDV1zFAee+mu0VEDu8NKxvrFOEoo7/a RC49Yr9VNwKHtFin3WiZWE54SxUB7beo1QHTNCJz58t5o3WwGmtnEuMiucBz7oA= =w47l -----END PGP SIGNATURE----- From giles@thaumas.net Tue Nov 6 11:30:55 2012 Return-Path: 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 00CB921F85E8 for ; Tue, 6 Nov 2012 11:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vM3f9lqm+5N for ; Tue, 6 Nov 2012 11:30:54 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 872D521F85C6 for ; Tue, 6 Nov 2012 11:30:54 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so341758dan.31 for ; Tue, 06 Nov 2012 11:30:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=C5McUrfgCrmV0pQVz8KEaB5JroORrWhV8YrazzF8uAE=; b=OcBNmBfOGrPcKPdh+uEwrzKIUPb1eYNpHiZmwuZVGTRGuADIjbnNrUzx1o17Ls19bk tJEhS+s1XXN3x4lIvq34Kkx9r8ot/5tcOSv3huIZBKBfLxIo8WfVAN/Iy1HUnHWXDhDC JKqurW5rCqe59uguaFgsB92YdJjr4hq7HeA3x/Pf17zYGg/hG77RhPqfX2q1SwK8v/Y6 y+eScLDW1NR/XQC7W5a2ok+L56Ppb7j4N0N4ENoIhNyiuT5UURZTRGJRJYDi9AdTxFSi t7oVzZ7QqFDjU34aEFuwf2pMV9V5jT8u7Dwzb2a4zGPKq80J2MigpvEI6NNPwY61Whpd mRlw== Received: by 10.68.245.167 with SMTP id xp7mr6435549pbc.75.1352230254375; Tue, 06 Nov 2012 11:30:54 -0800 (PST) Received: from Glaucomys.local ([64.213.70.194]) by mx.google.com with ESMTPS id a10sm12886274paz.35.2012.11.06.11.30.52 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 11:30:53 -0800 (PST) Message-ID: <5099656C.9040809@thaumas.net> Date: Tue, 06 Nov 2012 11:30:52 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jonathan Rosenberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnWLrDVaewsaijD40Q4DgqvnfaFBIeAdraYyD6sjkLaSy/r/1vB/PlNnRw42aJeP8J4z45E Cc: codec@ietf.org Subject: Re: [codec] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:30:55 -0000 On 12-11-06 9:45 AM, Jonathan Rosenberg wrote: > For the container format, we'd like to see if there is consensus to adopt > http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text=1 as > a working group item. I am in favour of adopting this as a working group draft. -r From mdr@reavy.org Tue Nov 6 11:33:56 2012 Return-Path: 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 D4E2121F8A5F for ; Tue, 6 Nov 2012 11:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SXU03DaAb0iQ for ; Tue, 6 Nov 2012 11:33:56 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFC221F8A5D for ; Tue, 6 Nov 2012 11:33:56 -0800 (PST) Received: from dhcp-50db.meeting.ietf.org ([130.129.80.219]:61671) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TVouJ-0008PS-LN for codec@ietf.org; Tue, 06 Nov 2012 13:33:55 -0600 Message-ID: <50996623.6010600@reavy.org> Date: Tue, 06 Nov 2012 14:33:55 -0500 From: Maire Reavy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: codec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - reavy.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [codec] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:33:57 -0000 On 11/6/2012 12:45 PM, Jonathan Rosenberg wrote: > Hi folks, > We've still got two items left on our charter to complete - a > container format and the testing document. Cullen, Tim and myself met > yesterday during IETF and discussed these. For the container format, > we'd like to see if there is consensus to adopt > http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text=1 as > a working group item. Please let us know what you think by the end of > this week. I'm in favor of adopting this. -Maire From hoene@uni-tuebingen.de Tue Nov 6 14:03:01 2012 Return-Path: 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 DC49B21F8B7E for ; Tue, 6 Nov 2012 14:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] 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 ayXEnwfVZ16q for ; Tue, 6 Nov 2012 14:03:01 -0800 (PST) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id C930C21F8B82 for ; Tue, 6 Nov 2012 14:03:00 -0800 (PST) Received: from ChristianHoene (dhcp-508e.meeting.ietf.org [130.129.80.142]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id qA6M2oJ3029310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Nov 2012 23:02:57 +0100 From: "Hoene" To: "'Maire Reavy'" , References: <50996623.6010600@reavy.org> In-Reply-To: <50996623.6010600@reavy.org> Date: Tue, 6 Nov 2012 17:02:50 -0500 Message-ID: <007c01cdbc6a$7b852110$728f6330$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXacxe+c6wmjDdGqSFrTUvYj3B0wLWUR0+lzMv1EA= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx08); id=3612-9g5TSS Subject: Re: [codec] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:03:02 -0000 +1 -- Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel +49 7071 2970532, Fax +49 7071 5220 http://kn.inf.uni-tuebingen.de/staff/hoene.html -----Urspr=FCngliche Nachricht----- Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im Auftrag = von Maire Reavy Gesendet: Dienstag, 6. November 2012 14:34 An: codec@ietf.org Betreff: Re: [codec] Adopt draft-terriberry-oggopus as a WG item On 11/6/2012 12:45 PM, Jonathan Rosenberg wrote: > Hi folks, > We've still got two items left on our charter to complete - a=20 > container format and the testing document. Cullen, Tim and myself met=20 > yesterday during IETF and discussed these. For the container format,=20 > we'd like to see if there is consensus to adopt > http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text > =3D1 as a working group item. Please let us know what you think by the = > end of this week. I'm in favor of adopting this. -Maire _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From ron@debian.org Wed Nov 7 00:23:22 2012 Return-Path: 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 70E0B21F8507 for ; Wed, 7 Nov 2012 00:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 erj9Df-g8w6U for ; Wed, 7 Nov 2012 00:23:22 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id BA17D21F84FF for ; Wed, 7 Nov 2012 00:23:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN4ZmlB5LW4k/2dsb2JhbABEw12BCYIeAQEFHR0cMwsYLhQYDYhADLtHjAODIoJEYQOODodsAYEcjyiDAg Received: from ppp121-45-110-36.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.110.36]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Nov 2012 18:53:20 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 88BD34F8F3 for ; Wed, 7 Nov 2012 18:47:10 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8axNETeks7XQ for ; Wed, 7 Nov 2012 18:47:06 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 1B1C84F902; Wed, 7 Nov 2012 18:47:06 +1030 (CST) Date: Wed, 7 Nov 2012 18:47:06 +1030 From: Ron To: codec@ietf.org Message-ID: <20121107081706.GA6812@audi.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 08:23:22 -0000 On Tue, Nov 06, 2012 at 12:45:35PM -0500, Jonathan Rosenberg wrote: > Hi folks, > > We've still got two items left on our charter to complete - a container > format and the testing document. Cullen, Tim and myself met yesterday > during IETF and discussed these. For the container format, we'd like to see > if there is consensus to adopt > http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text=1 as > a working group item. Please let us know what you think by the end of this > week. I'd definitely like us to move forward with adopting this. (and reiterate the call for any further comments that people may have about its content too) Thanks, Ron From calvin.walton@kepstin.ca Wed Nov 7 09:03:28 2012 Return-Path: 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 28CF221F8C34 for ; 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-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbFR+6IMWpoF for ; Wed, 7 Nov 2012 09:03:27 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C07AC21F8C30 for ; Wed, 7 Nov 2012 09:03:18 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3047384iec.31 for ; 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 10.50.236.104 with SMTP id ut8mr5301569igc.20.1352307798167; Wed, 07 Nov 2012 09:03:18 -0800 (PST) Received: from [172.17.145.250] ([134.117.254.248]) by mx.google.com with ESMTPS id 7sm2537955igh.0.2012.11.07.09.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:03:17 -0800 (PST) Message-ID: <1352307794.14547.30.camel@ayu> From: Calvin Walton 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:03:28 -0000 --=-4OXNEyWl4XamVoXGHJ22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags. 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) will use the REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags (as 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. --=20 Calvin Walton --=-4OXNEyWl4XamVoXGHJ22 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA3MTcw MzE0WjAjBgkqhkiG9w0BCQQxFgQUVIa17Gyk2a35UNNf8dxfsmtB08UwDQYJKoZIhvcNAQEBBQAE ggEATPhPL2wnf85DByDnjALcUUNTpWb5IEIp95HWh2HtsHmBb6+gq4zwt3uGmCGTP+qOVOLbq42T 4b2Uti7c3yaN94y4W7HFB0qpXlRa9vtVc/r3Ewr94qhSIeOCSuLnoUEoLOIlmx9m7khYRemv0hXA mU5YuFCJkxu3Qzr3WFFcQ9Vvv/3aZI3nM7W34HaVTa9Lqg/YT0EUemgSUAS5dPpPc7hcfwQTAyIR GucFAaSf7thOPBLZMlXCg8gtboMG7TTUBuvz4QcmqGdPtzyiAr4nE/k0W90AVRs8IBjlBYA1GwHo j09jGnyK0/h2Z/ZyIomXpyam+fFl8Suea5b2Km+nJgAAAAAAAA== --=-4OXNEyWl4XamVoXGHJ22-- From giles@thaumas.net Wed Nov 7 09:22:15 2012 Return-Path: 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 1271D21F8BF9 for ; Wed, 7 Nov 2012 09:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goKIjsPMY4Dq for ; Wed, 7 Nov 2012 09:22:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6511F21F8853 for ; Wed, 7 Nov 2012 09:22:14 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3086903iec.31 for ; Wed, 07 Nov 2012 09:22:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=wNk02a6G2jfRx01BcPnNN3nYEdxuuYyJXGNNsv/mN/s=; b=NCLJ3Q3vT84PU+HZe3wpQoBbQeD5VrE1wxx7UEC5dWeW41trDPUbDs1HssxQxWxUUn UIPhOSiJhzeBSgQVyJckdtzlcl5q2N2+040iQDLaKe3vpaiqSJ+ZAFaJpqbAF9S11Nqa 8F33R5q1MUhHmaj7tkSWPdBG/CVBl1xVE9iWeaRAHbtU+huaXW7aDgk0Kv5pTYV/EyMP FSHZtmBV2a0AMVEJeYnIKcu2sLg2N0SJQV9BnutRlTMBBZYNUHQgrMR+kIQ+RFFOrAKQ muf0Zn4ksaGhncxMl5eTpYZ/TZjE3vyugjMyBSxcvfcPJHzClr1Ftu/3MkmFBa5g4Ez6 tJzw== Received: by 10.50.104.230 with SMTP id gh6mr5482930igb.13.1352308933447; Wed, 07 Nov 2012 09:22:13 -0800 (PST) Received: from Glaucomys.local ([199.119.234.210]) by mx.google.com with ESMTPS id l8sm2494062igo.13.2012.11.07.09.22.08 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:22:10 -0800 (PST) Message-ID: <509A98BA.9050808@thaumas.net> Date: Wed, 07 Nov 2012 09:22:02 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: codec@ietf.org, calvin.walton@kepstin.ca References: <1352307794.14547.30.camel@ayu> In-Reply-To: <1352307794.14547.30.camel@ayu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl8igyaKSbtRLqaCpjZwX5JUIp9fPDik6JIBii3WEL7YPmuxrBO3RlfpBjHIQnGEjw+VH4I 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:22:15 -0000 On 12-11-07 9:03 AM, Calvin Walton wrote: > 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 think the idea was to encourage adoption of the R128 methods along with Opus, since R128 is both technically superiour and more officially standardized. I agree it would be useful to describe what to do if multiple tags are present, even if it remains SHOULD NOT. I would say, "The R128 tag overrides any REPLAYGAIN tag which is present. Player MAY choose to apply REPLAYGAIN values, combined with the output gain from the OpusHead packet, if no R128 tag is present." > 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. That's a useful distinction to maintain. I agree. The other issue is what encoders are doing. Are any of the applications you tested *setting* REPLAYGAIN tags on files they encode? Or is it just that you want some level equalization and your player doesn't currently support the R128 scheme during playback? The question is whether we have some hope of acheiving compliance with the idea as opposed, or if it's too late for that already. -r From calvin.walton@kepstin.ca Wed Nov 7 09:53:27 2012 Return-Path: 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 49E4C21F8878 for ; Wed, 7 Nov 2012 09:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgrE-AvkFW-d for ; Wed, 7 Nov 2012 09:53:26 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07721F8792 for ; Wed, 7 Nov 2012 09:53:24 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so1461614iak.31 for ; Wed, 07 Nov 2012 09:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=jXXf7WVMCQXPHG2wz9VU7IRsLJjnDG+W+eI4TcqFjgI=; b=JiYNAtj+V9O+noj15iknJA+t737LNUrL9pHaj96PvZ6g6al9NTVMmNc4Bbyi1nVma7 CaVX22hUSrsT3Dl5zhgTUpkjvuBlU4PIfaSnZ5u1oNJG7PV3ni8wyfMqVzdCs0mqB2vI CWwzDgFw/JEbrKmDNpxkkQKHAKd4Ao8eHmQWY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=jXXf7WVMCQXPHG2wz9VU7IRsLJjnDG+W+eI4TcqFjgI=; b=fgVwKo4lvGRHFesiYR9p6MHdvNGeY57og1Akflnq0rtOqa/SzWFU7quK0lzZCTKQ48 +DKQtBGiI9IQCimDp27RtRWhK+9cFk0ZotvEOXCGV11S+JWA/wot1P0RZ/phqoPQUksC oPkYWGDZUURq+BpMfeADJeGk4mdCyJFQKqFenEcgWghgVJ6J34Nl8niXaWa4pxgejUwy tpYCpVFY5Cul122rPUl/pt5GI96nph/xehDX/+E6bxXK68x1fpPC7ziUkwdhEFQPEKnA F+8FWF+NJFnyhp5rvoYN7k6kLoylsPdgSTbYiH3aVkRiGLuVvo2PoC6m4HknfGgnjnEU U/zw== Received: by 10.50.91.195 with SMTP id cg3mr17340836igb.57.1352310804478; Wed, 07 Nov 2012 09:53:24 -0800 (PST) Received: from [172.17.145.250] ([134.117.254.248]) by mx.google.com with ESMTPS id b13sm2577171igp.7.2012.11.07.09.53.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:53:22 -0800 (PST) Message-ID: <1352310799.14547.48.camel@ayu> From: Calvin Walton To: Ralph Giles Date: Wed, 07 Nov 2012 12:53:19 -0500 In-Reply-To: <509A98BA.9050808@thaumas.net> References: <1352307794.14547.30.camel@ayu> <509A98BA.9050808@thaumas.net> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-zySJtAjYhhJUgVFbX91t" X-Mailer: Evolution 3.6.0 Mime-Version: 1.0 X-Gm-Message-State: ALoCoQk1scc1/ZXmoPKxt5J3Ee5uTeMuYsU+j4GRSDitAbnfRuuMm+ds9JxWZXaAC818YeNC3K5w Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:53:27 -0000 --=-zySJtAjYhhJUgVFbX91t Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-11-07 at 09:22 -0800, Ralph Giles wrote: > On 12-11-07 9:03 AM, Calvin Walton wrote: >=20 > > 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"). >=20 > I think the idea was to encourage adoption of the R128 methods along > with Opus, since R128 is both technically superiour and more officially > standardized. I agree it would be useful to describe what to do if > multiple tags are present, even if it remains SHOULD NOT. As long as the behaviour is properly documented, saying 'SHOULD NOT' is probably ok, even if I think it is a bit strong. > I would say, "The R128 tag overrides any REPLAYGAIN tag which is > present. Player MAY choose to apply REPLAYGAIN values, combined with the > output gain from the OpusHead packet, if no R128 tag is present." I think that the player should allow the user to optionally prefer REPLAYGAIN over R128. The issue that I have is interoperability with files in other formats, which do not have any standardized way of saving R128 gain tags, but do have defined REPLAYGAIN mappings. Loudness normalization is useless if you can't normalize everything to the same standard :) > > I would however recommend that the files still SHOULD NOT have the > > REPLAYGAIN_{TRACK,ALBUM}_PEAK tags, as Opus does not have a bit-accurat= e > > decoder specified, and the peak values will also vary based on the > > sample rate selected for decoding. >=20 > That's a useful distinction to maintain. I agree. >=20 > The other issue is what encoders are doing. Are any of the applications > you tested *setting* REPLAYGAIN tags on files they encode? Or is it just > that you want some level equalization and your player doesn't currently > support the R128 scheme during playback? The question is whether we have > some hope of acheiving compliance with the idea as opposed, or if it's > too late for that already. As far as I know, there are no applications currently that automatically set replaygain tags in Ogg Opus. This could change - e.g. once a tag-editing element for Ogg Opus is added to Gstreamer, then Gstreamer applications will automatically gain the ability to set replaygain tags. I'm considering adapting the 'vorbisgain' utility to decode Opus for my personal use, to normalize files in my collection. In order to apply the values to the files that I have, I used a format-agnostic replaygain calculation tool to get the values, and a standard vorbis comment editor to set the values. If you ask foobar2000 to generate replaygain tags on Ogg Opus, it currently saves values in the header output gain (for album) and the R128 track tag. It's unclear whether it actually uses the R128 algorithm or if it uses Replaygain with a non-standard reference value. --=20 Calvin Walton --=-zySJtAjYhhJUgVFbX91t Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA3MTc1 MzE5WjAjBgkqhkiG9w0BCQQxFgQUvz4qMGobY2cdBnzPE4ckBqIl7iEwDQYJKoZIhvcNAQEBBQAE ggEALxc50Cx/5RcFYteT2jOsF/MQqqcBvAyL/2SKmtRBqJi8S1rlhfYpJaJyTq0dMtVagn+VWdw9 h2JglJpknhWDmmSe9PAQX4mVds87tPE+1icSZSWEJng2hnW3wrLBf8KRlrfTbkGQDbglGki7AcVI izctbYIPweXY+rQwgkHAkGPMuJB5QCDKs1SNna2XBhv2L/xmFXGiP0H1r0pKDuElV3uKNNSxIiwr FNDv6oRvPeuChPV/fC0JsRkNV4m+2gDlGp+gWjuyeIuq9PGhFp1c8izeDI0PzyCDMK0ERHIl/9BN ubfFpExGIwVYeP+e9vXSWW2JQbOlWIMq7bOTU/WTzwAAAAAAAA== --=-zySJtAjYhhJUgVFbX91t-- From gmaxwell@juniper.net Wed Nov 7 11:57:35 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: Calvin Walton , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:57:35 -0000 Calvin Walton [calvin.walton@kepstin.ca] wrote:=0A= > While I don't see any technical problems with R128 - it is a good volume= =0A= > normalization scheme - the issue is that it is a *different*=0A= > normalization scheme from the replaygain tags that are supported in=0A= =0A= Replay gain does not specify a method for measuring the level. The R128 mea= surement 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 po= pular 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 d= ifferent 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.=0A= =0A= > other audio formats - it gives different results, and isn't directly=0A= > interoperable, and isn't supported by many existing players.=0A= =0A= Replaygain itself has very spotty support.=0A= =0A= This means that if you create a file with replaygain tags it will have _wil= dly_ 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 file= s... and well, if thats all you care about interoperability isn't much of a= n issue.=0A= =0A= 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 i= t is supported by every single existing decoder that I'm aware of.=0A= =0A= > I've done a survey of existing player applications with Ogg Opus=0A= > support. All of these players:=0A= > * Rockbox (development version with Opus support)=0A= > * GStreamer-based (e.g. Rhythmbox)=0A= > will use the REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags (as=0A= > specified in Vorbis) to apply replaygain to Opus tracks. Both Rockbox=0A= =0A= Can you give me a link to a test file=97 I tried and it isn't for me.=0A= =0A= > and Gstreamer-based players will first apply the stream header's output= =0A= > gain field prior to applying the replaygain correction; I haven't=0A= > checked foobar2000 on that point.=0A= =0A= Well thats good.=0A= =0A= > Of the players in that list, only foobar2000 supports the R128 gain tag.= =0A= > I am not sure what happens if both tags are present.=0A= =0A= 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 b= y default. And I think this is a massive improvement which would be broken = by reintroducing the widespread inconsistency of replaygain.=0A= =0A= Make sense?=0A= From gmaxwell@juniper.net Wed Nov 7 12:15:13 2012 Return-Path: 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 AAC1C21F8CB1 for ; Wed, 7 Nov 2012 12:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 49JuDeU1XTLy for ; Wed, 7 Nov 2012 12:15:13 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 029D521F8CAE for ; Wed, 7 Nov 2012 12:15:12 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUJrBUIcxSeRy3vNJGZ+On4y1RQ9oIP0K@postini.com; Wed, 07 Nov 2012 12:15:13 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 12:03:29 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 7 Nov 2012 12:02:23 -0800 Received: from CO9EHSOBE006.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Nov 2012 12:04:40 -0800 Received: from mail17-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.23; Wed, 7 Nov 2012 20:02:03 +0000 Received: from mail17-co9 (localhost [127.0.0.1]) by mail17-co9-R.bigfish.com (Postfix) with ESMTP id C10DA3800C2 for ; Wed, 7 Nov 2012 20:02:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz98dIc85dhzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0l1155h) Received: from mail17-co9 (localhost.localdomain [127.0.0.1]) by mail17-co9 (MessageSwitch) id 1352318520521088_6414; Wed, 7 Nov 2012 20:02:00 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.254]) by mail17-co9.bigfish.com (Postfix) with ESMTP id 73FB710026D; Wed, 7 Nov 2012 20:02:00 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 7 Nov 2012 20:01:55 +0000 Received: from CH1PRD0511MB432.namprd05.prod.outlook.com ([169.254.4.82]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0233.004; Wed, 7 Nov 2012 20:01:54 +0000 From: Gregory Maxwell To: Jonathan Rosenberg , "codec@ietf.org" Thread-Topic: [codec] Adopt draft-terriberry-oggopus as a WG item Thread-Index: AQHNvEalcblm0Cy0D0ywQ0u4MqNMG5fezF4R Date: Wed, 7 Nov 2012 20:01:53 +0000 Message-ID: <9B8EA46C78239244B5F7A07E163D3DFE08C515@CH1PRD0511MB432.namprd05.prod.outlook.com> References: In-Reply-To: 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: multipart/alternative; boundary="_000_9B8EA46C78239244B5F7A07E163D3DFE08C515CH1PRD0511MB432na_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%JDROSEN.NET$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] Adopt draft-terriberry-oggopus as a WG item X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 20:15:13 -0000 --_000_9B8EA46C78239244B5F7A07E163D3DFE08C515CH1PRD0511MB432na_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan Rosenberg [jdrosen@jdrosen.net] wrote: > For the container format, we'd like to see if there is consensus to adop= t http://datatracker.ietf.org/doc/draft-terriberry-oggopus/?include_text=3D= 1 as a working group item. Sounds great. --_000_9B8EA46C78239244B5F7A07E163D3DFE08C515CH1PRD0511MB432na_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jonathan Rosenberg [jdrosen@jdrosen.net] wrote:
--_000_9B8EA46C78239244B5F7A07E163D3DFE08C515CH1PRD0511MB432na_-- From calvin.walton@kepstin.ca Wed Nov 7 14:41:36 2012 Return-Path: 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 1D6A421F84FF for ; Wed, 7 Nov 2012 14:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSJtT0+22bg2 for ; Wed, 7 Nov 2012 14:41:31 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58B9A21F84DF for ; Wed, 7 Nov 2012 14:41:31 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3631487iec.31 for ; Wed, 07 Nov 2012 14:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=rzQ4+qL7nUiLUpkQ/0h+r48PR/dGQAWZqHRl0HHeCy8=; b=uRtmhNeC5QJWNrg5IeRjaucUznE27GsnOJBXPIhlMi1zGC+/TPYuXq+2PN4RovTf9A XyAylC2rt1fqjADd8jWOo9UKqHSLT7/ezoaIxRG6vTMFkH1IZ5dwp6xjaOje5oPkbnJs zUwAv6Lby4Hv+PztnsIL/geS2bQ9DHuTgvNsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=rzQ4+qL7nUiLUpkQ/0h+r48PR/dGQAWZqHRl0HHeCy8=; b=BsvD4/g/KTUdxxMdrWh00ZUjXe7B8x3JQxpXfJ9I+ELlgyK8/s/pPk5U18RW7e1YX1 lA50+UNG9fmZFjrKYtmxBhCeEwbqm09qr5sqjfKqhFRJcDiuBv+2hAzaHxs/8mNT88UN J/uFlL8hyGdhkM3fDfM+xEmW2xXqhPN/n0cFup03DX6U/73sspH0hr7h/pIuwCTj/rPO qe5BzWXzx3pAEDAKXLGzQrijyPAPnGdJEabyTkVWieSWUyHdP6X5bIr173ljVS5hUMR9 gdTy5pkNJFQXtOHA/ACCN+Jk7p+TGqTNz4/vYdD8t8vm/2p/MYyp5NcSlFfz2B16SMbq /jyg== Received: by 10.42.101.11 with SMTP id c11mr5461069ico.52.1352328090991; Wed, 07 Nov 2012 14:41:30 -0800 (PST) Received: from [192.168.1.149] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [99.224.21.194]) by mx.google.com with ESMTPS id az6sm2987759igb.11.2012.11.07.14.41.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 14:41:29 -0800 (PST) Message-ID: <1352328081.14547.82.camel@ayu> From: Calvin Walton To: Gregory Maxwell Date: Wed, 07 Nov 2012 17:41:21 -0500 In-Reply-To: <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-Fg8nuJgpS8fqd9uVrQ5i" X-Mailer: Evolution 3.6.0 Mime-Version: 1.0 X-Gm-Message-State: ALoCoQl2pJmZbbHtsJjl+XmQlnrMtguOrEjbAwVLO4KC1f1GqEa/5xaTSWGrjVb6iPJiOUSqmiCg Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:41:36 -0000 --=-Fg8nuJgpS8fqd9uVrQ5i Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-11-07 at 19:46 +0000, Gregory Maxwell wrote: > Calvin Walton [calvin.walton@kepstin.ca] wrote: > > While I don't see any technical problems with R128 - it is a good volum= e > > normalization scheme - the issue is that it is a *different* > > normalization scheme from the replaygain tags that are supported in >=20 > 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. 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. I agree that it would be possible to write a program that would support playing back files with either R128 or replaygain values reasonably well by adjusting the gain to compensate for the different reference points. > > other audio formats - it gives different results, and isn't directly > > interoperable, and isn't supported by many existing players. >=20 > Replaygain itself has very spotty support. >=20 > 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. 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'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 >=20 > Can you give me a link to a test file=E2=80=94 I tried and it isn't for m= e. I can do that; here's the CC attribution, non-commercial, share-alike track "Discipline" by Nine Inch Nails, with vorbis-style replaygain tags added, no r128 gain tags present, and opus header gain set to 0. It is representative of how I've been doing music in my collection: http://www.kepstin.ca/dump/nin-discipline.opus (~4.1MB, ~128kbit stereo) Note that both Rockbox and Rhythmbox ship with replaygain correction turned off by default; it must be manually enabled (It's in the playback options in Rockbox, and in the Plugins menu in Rhythmbox). An example gstreamer pipeline for this is $ gst-launch-1.0 -t filesrc location=3Dnin-discipline.opus \! decodebin \! = rgvolume \! pulsesink (remove the rgvolume element to get the track without replaygain applied) > > 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. >=20 > Well thats good. >=20 > > Of the players in that list, only foobar2000 supports the R128 gain tag= . > > I am not sure what happens if both tags are present. >=20 > 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. 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 application can put any value in that field, and a player cannot assume that the value is relative to any useful reference point. The only supported place currently to get a gain with a useful reference point is the R128_TRACK_GAIN tag. If a player blindly applies only the header output gain value, it has no knowledge of whether the output is loudness normalized or not. --=20 Calvin Walton --=-Fg8nuJgpS8fqd9uVrQ5i Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA3MjI0 MTIxWjAjBgkqhkiG9w0BCQQxFgQUaFPOHiEnnv1zl4WCWas9MrATQmcwDQYJKoZIhvcNAQEBBQAE ggEAqI0JK2QwnGfRngQ9Z3u0jjo3jO5dscJ6WrKTgIpk8pqun+godiK5o1Uo5jvzdaf3LWNCZtDH DubTxB+MGDvtRRgjaxf7GNf/nXry3egMYZvjFaOWjHZkjnA9YFw1vshUmD8+MZPUMNrplbZAIc7s gHt7ypz6LlVKZmY1D/k4e8v108Vku9mP05FMtvDMvhszg4qCGLbH6WwY1Vmi10ARX0dxU5AEZfkx RcZ60JgK6QXXZ94IPHMr+0pe0vV5EnuA0xiltrcPsaBeUGdKsnAp50IGLvqYPZFZkasGpW5A5RFV 6gveHfMbgbTu+K1OuzEBYk6P39R3q1L7UQLlYrkkAwAAAAAAAA== --=-Fg8nuJgpS8fqd9uVrQ5i-- From calvin.walton@kepstin.ca Wed Nov 7 14:51:45 2012 Return-Path: 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 A8BB021F8724 for ; Wed, 7 Nov 2012 14:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m5kEfIe6utw for ; Wed, 7 Nov 2012 14:51:41 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB2FB21F86E4 for ; Wed, 7 Nov 2012 14:51:40 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so3643735iec.31 for ; Wed, 07 Nov 2012 14:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=GXZxyBiNoN1rHMCmdsUFSrcK8J/FS09Xny7PpJCl7hw=; b=iA+v/InXNk1n0d8tBl7SsgZIzXpuUnmw5ygje3DC/eLwy8ImgQbDXwNAnrMArGqO5E l2AOnfN8jMJ0aBxHQ+pn/lO5ABKcFVafbp8dwnQDbA33LPlecnaDY+bP8dU5nAo9/NZ4 wpmtbf2RPMGuk+loE4oulUY1qam8y5XE6n134= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=GXZxyBiNoN1rHMCmdsUFSrcK8J/FS09Xny7PpJCl7hw=; b=CtkZca9H+3iUL62CgVfQOMBC6kAjK7OVVDQSzY3vUXGu3ZBdPHIaXJy0NZVezQknzy w6qPv0/HCtNL25siinXOF2LwRzUNOflGbw9cehkR27t4Mbgd/4jSTbvDEwImV/gtK+ZB hFArn9mnfXdbyyTtoAsNEsc9ipXOeRsO6mwny0STMb8MWk5fk8d4RLVV19R/LpYDYoJm a7gVzv6olAitdvRcGiJkulCd6ibxtHnoXYTj7pGt5Ttk3q+ddi93GDzeSJ/51E0t0q6K 894BziMfI9+3gJc3Ioe/g1jrZxEKgOwcfQU4jNE+xTrKukuiMoWB88W7XU2OUIqIfSXz DNZA== Received: by 10.50.13.138 with SMTP id h10mr18303055igc.55.1352328700538; Wed, 07 Nov 2012 14:51:40 -0800 (PST) Received: from [192.168.1.149] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [99.224.21.194]) by mx.google.com with ESMTPS id 10sm3020697ign.5.2012.11.07.14.51.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 14:51:39 -0800 (PST) Message-ID: <1352328696.14547.85.camel@ayu> From: Calvin Walton To: Gregory Maxwell Date: Wed, 07 Nov 2012 17:51:36 -0500 In-Reply-To: <1352328081.14547.82.camel@ayu> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-tgDNKDMCoaD21kYTzLzW" X-Mailer: Evolution 3.6.0 Mime-Version: 1.0 X-Gm-Message-State: ALoCoQklq6pLY/WdUS4lzI5JAfBa47Bg+NF2N358/zHVs367fPEThix9KqlIIl/kgEUzyQKJYcWi Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:51:45 -0000 --=-tgDNKDMCoaD21kYTzLzW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-11-07 at 17:41 -0500, Calvin Walton wrote: > On Wed, 2012-11-07 at 19:46 +0000, Gregory Maxwell wrote: > > Calvin Walton [calvin.walton@kepstin.ca] wrote: > > > While I don't see any technical problems with R128 - it is a good vol= ume > > > normalization scheme - the issue is that it is a *different* > > > normalization scheme from the replaygain tags that are supported in > >=20 > > 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. >=20 > 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. Sorry, a minor correction - and this *is* something that has caused interoperability issues in the past: The correct replaygain reference gain level is "89 dB" SMPTE SPL, not 83 dB. (The - sign was a typo...) --=20 Calvin Walton --=-tgDNKDMCoaD21kYTzLzW Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA3MjI1 MTM2WjAjBgkqhkiG9w0BCQQxFgQUsB5DoovP2zdm8DJO5p9ViHRFqHswDQYJKoZIhvcNAQEBBQAE ggEALMTC8KyxiZhjDlCofVY+EFaYp3f4nlSpkcT6XxBnt6U7QY8gqG7x31kqBpekYm7Gm2Y1LjQ4 B3fyHgQ6z2BO0PuGJxLRpvDtNju6ldHtKDWKn5icbBFNOPaoDFB0dCdpkswnKD6cOOAXxtH1MEEn j56bQrJ0L8p4NV0smaItvqzU0pqtAQbQes9N3SZUi3mLreq7MaDpChG3OOGQK7zLJDLef9pLmbcL PGqrhHYgSXNdDQqHwfWUmxdByOh7U7LvvwHq22bh8rsJfQ7haHVu0XvWjDCYDt/ygsfm3JaMwNmy uiVZO7LjAQtHSQPXS06SeQzYQtUEWiQm3wzIHlTdxgAAAAAAAA== --=-tgDNKDMCoaD21kYTzLzW-- From ron@debian.org Wed Nov 7 19:53:11 2012 Return-Path: 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 DA75021F8A14 for ; Wed, 7 Nov 2012 19:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 nu-8lJDwkjNP for ; Wed, 7 Nov 2012 19:53:11 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBA21F88E9 for ; Wed, 7 Nov 2012 19:53:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJQrm1B5LW4k/2dsb2JhbABEw2qBCYIeAQEEATocFgoDBQsLGC4UGA0kiBcFvR+MDYVmYQOODodsAZBEgwI Received: from ppp121-45-110-36.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.110.36]) by ipmail06.adl2.internode.on.net with ESMTP; 08 Nov 2012 14:23:08 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 4E4564F8F3; Thu, 8 Nov 2012 14:23:06 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jQANq66nJWQG; Thu, 8 Nov 2012 14:23:05 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 86B4A4F902; Thu, 8 Nov 2012 14:23:05 +1030 (CST) Date: Thu, 8 Nov 2012 14:23:05 +1030 From: Ron To: Calvin Walton Message-ID: <20121108035305.GE6812@audi.shelbyville.oz> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1352328081.14547.82.camel@ayu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 03:53:12 -0000 Hi Calvin, Thanks for your input here. Just to comment on this point: On Wed, Nov 07, 2012 at 05:41:21PM -0500, Calvin Walton wrote: > 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. The 'normalisation method' for the header gain is specified as: An encoder SHOULD set this field to zero, and instead apply any gain prior to encoding, when this is possible and does not conflict with the user's wishes. The output gain should only be nonzero when the gain is adjusted after encoding, or when the user wishes to adjust the gain for playback while preserving the ability to recover the original signal amplitude. ie. any normalisation that you want to do at encoding time should be done *before* encoding, and the header gain is left purely for other users who would like to arbitrarily rescale it without reencoding, to any level they deem appropriate for their particular use. For instance you might use this to match levels with a signal from some other source that isn't ordinarily normalised to some standard like R128 or so. It's not so much for equalising the signal to one particular standard level, as it is for allowing people to later trivially adjust it 'losslessly' to some desired level entirely of their own choosing, for whatever reason they may desire that. > An application can put any value in that field, and a player cannot > assume that the value is relative to any useful reference point. Correct, a player can only assume that it is the level that the person who created the file wants it scaled to, and that it should play it at that level, absent any other input from the user to the contrary. > The only supported place currently to get a gain with a useful > reference point is the R128_TRACK_GAIN tag. That's why this is a separate mechanism to the header gain. This one is about noting the gain adjustment required (after the header gain is applied) to achieve a known, specific reference signal level. > If a player blindly applies only the header output gain value, > it has no knowledge of whether the output is loudness normalized > or not. A player must always apply the header gain to output the signal level that the person who created the file intended it to have (as if they really had scaled it by that level prior to encoding). A player may also optionally apply normalisation to a standard level on top of that, either based on information in the file's comment tags, its own analysis of the file, or some other mechanism based on input from the user of that player. The former is about gain choices made by the creator, the latter is more about gain choices made by the end user. The former must always be applied so that players behave consistently, the latter may be applied at the sole discretion of the user and (how they configure) the applications that they use to play it. Is there something about that which we need to explain better in the draft? Cheers, Ron From calvin.walton@kepstin.ca Wed Nov 7 22:14:07 2012 Return-Path: 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 5AD5521F878C for ; Wed, 7 Nov 2012 22:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xZBRc44cUS7 for ; Wed, 7 Nov 2012 22:14:06 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8121F8546 for ; Wed, 7 Nov 2012 22:13:54 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so4089157iec.31 for ; Wed, 07 Nov 2012 22:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=w0uge+zOUfuamJU8NPPqdmwhRnPyfBzyHFjs5P678oo=; b=MQjrEJREYOd6OKZPxqvFNCgnKl1ihii7gk+MVQCM9FMEGHUiEUwiNCPHT36i7Teuus 0qwkNc9ciS1LGh01T0mtZB71IDdN4a/brk74rI5ckC1jEQA+yaYklt9LDzS70Pwpkj+Y 4PhBICd3chc2vG9vzr+pBzc78q9qc0mSywoYc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=w0uge+zOUfuamJU8NPPqdmwhRnPyfBzyHFjs5P678oo=; b=GR+UXGD2FoEGQJUVERfQHf/d05Ulq8U7hXK0EljkYTgzjCU2vpwLB9Uv/niLfuLg1d RAuXuU01ZMQa+QmPfQLLpg70Wp3CGF4SWTwCfwQ58G9sCkCTKGhpL/zNT9gkkXf4nkPM WIAUVCE1plLBowunUa4Qge+lKJzYJx7Kkxna+X2EMopCD/3UMKTyT7j6vflFZMVnICrG Jy47cebQepFSrRKOdsPm0LHeNcws07ET+QfehUZMt9zcMTCWbbezrQ1jrPAbRpnBM1QA jO3I2kUbw7W2STego7t+62Fyh1evmL65O2IIfhdbDRelIA8VSZQR230mwEuRvNMDl85a X8sw== Received: by 10.50.36.200 with SMTP id s8mr18922153igj.25.1352355234163; Wed, 07 Nov 2012 22:13:54 -0800 (PST) Received: from [192.168.1.149] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [99.224.21.194]) by mx.google.com with ESMTPS id ez8sm4053395igb.17.2012.11.07.22.13.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 22:13:52 -0800 (PST) Message-ID: <1352355230.25560.30.camel@ayu> From: Calvin Walton To: Ron Date: Thu, 08 Nov 2012 01:13:50 -0500 In-Reply-To: <20121108035305.GE6812@audi.shelbyville.oz> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> <20121108035305.GE6812@audi.shelbyville.oz> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-4aSf0/yXeo/Fa2Gp+paV" X-Mailer: Evolution 3.6.0 Mime-Version: 1.0 X-Gm-Message-State: ALoCoQnrnPCe8jIQaX5V5nUXzbyVej1rOAaAvBoiRSqN4ZVKyTk83XOCLobVL7m0nSAS7VA3xmZn Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 06:14:07 -0000 --=-4aSf0/yXeo/Fa2Gp+paV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-11-08 at 14:23 +1030, Ron wrote: > A player must always apply the header gain to output the signal > level that the person who created the file intended it to have > (as if they really had scaled it by that level prior to encoding). >=20 > A player may also optionally apply normalisation to a standard > level on top of that, either based on information in the file's > comment tags, its own analysis of the file, or some other > mechanism based on input from the user of that player. >=20 > The former is about gain choices made by the creator, the latter > is more about gain choices made by the end user. The former > must always be applied so that players behave consistently, the > latter may be applied at the sole discretion of the user and > (how they configure) the applications that they use to play it. >=20 >=20 > Is there something about that which we need to explain better > in the draft? There is one place in the draft that does conflict with this - the rational for why an R128_ALBUM_GAIN comment was not included. It is noted that the 'album' gain value should be stored in the header gain field instead. However, if the header gain is supposed to be used by the audio creator/encoder and not the end user, then this will overwrite the creator's value. In addition, since the header gain field has no semantic meaning, there is no way to know that the value in this field corresponds to the R128 album gain as opposed to an arbitrary creator-provided value, meaning that a player cannot reliably give the user the ability to select 'album' vs. 'track' gain during playback by their preference. (I admit that for the time being, most opus files will be encoded by the same person as the end user who will be listening to them, of course...) Anyways, this is getting a bit far afield from my original topic... I want to play back Ogg Opus files at the same loudness level as my existing Replaygained Ogg Vorbis/FLAC/MP3/AAC/etc. files. Currently I have 3 choices: 1. Add Vorbis-style REPLAYGAIN_{TRACK,ALBUM}_GAIN comments with adjustments relative to the header gain (usually 0). This works correctly in all players that I have tried, even though the spec says that these tags should not be used. Since players generally share comment parsing code between vorbis and opus, these comments are likely to continue working for the foreseeable future. 2. Store either the track or album replaygain values in the header gain field. This works correctly in all players, but does not allow me to choose between album and track gain at playback time. (e.g. for continuous playback versus random/shuffle playback) 3. Store an arbitrary value (usually 0) in the header gain field, and use the R128_TRACK_GAIN comment with an R128 adjustment. Have the player add an additional adjustment to adjust the reference level to match replaygain. foobar2000 gets this almost right, except that it assumes that the header gain field corresponds to the album gain, which may not be correct. No other player currently supports this. (On the other hand, since comment parsing code is generally shared, this means that the R128_TRACK_GAIN comment will likely start working in Ogg Vorbis files soon.) At this point, I see the replaygain comments as the most compatible / interoperable way of reaching my goal, but it does mean that I'm relying on behaviour that the spec says I SHOULD NOT do. I'm wondering if it would make sense to specify the behaviour for when these tags are present. --=20 Calvin Walton --=-4aSf0/yXeo/Fa2Gp+paV Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA4MDYx MzUwWjAjBgkqhkiG9w0BCQQxFgQUwG0UeyHcvscV3OrjB+vG8KGbt1AwDQYJKoZIhvcNAQEBBQAE ggEALUiDxOCVBHBWYOdzQLaPOPW/qQBbEalO3yc7hz1iBivbhF43PkBYOfVjcw8+Zid3to3HdqYd GG6LwH6DDKc/w72O90EcF0XmwHR5P6ZgNsXvAqGYjSOQ6BNEk6vDUKTjaN/5E8hMuEIPL8quwKId Pvpkv19PXbmxdXi+tD2WwjgfcQK3vNaTldHvp6hirhwy3lXxgR2Uf/Yhe9gnqL77klWTtiG/Zy3e Nmbx+AgrJJTiF2fABdpS6JJt7Zx5/KnOG5CzAmnq2X/VKeRIRuZuFFEyY1vl6ngJxZqlAuXUZOj6 GsJvZOksKy39+tCshQIe5wb7f38qiglBQrSpaqHh8QAAAAAAAA== --=-4aSf0/yXeo/Fa2Gp+paV-- From giles@thaumas.net Tue Nov 13 12:33:30 2012 Return-Path: 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 30B9A21F8488 for ; Tue, 13 Nov 2012 12:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5HF3D-Oe4LE for ; Tue, 13 Nov 2012 12:33:25 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDD521F8692 for ; Tue, 13 Nov 2012 12:33:25 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1999641pbc.31 for ; Tue, 13 Nov 2012 12:33:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=m9chWH1ehVegcyzb21Wlfw4kGA+KaaArbJqYQ3JTCqU=; b=fxSxyx+shGjLVw9DPrahxsu3p4490m0/4sEfxKAJSu5R0lFb/a2BLXQibPwE8sdvXU JnbLcgitfdkM1GBNELMRikRzrbzxzhBukS2bAPif+tFc3abLmXtI9OHqZTv4EqRcBPZ9 enjnURvlekhCwLeqFd4iVqwKkc4u0sD0ObKzANlfAiMcPu9a9yOglm+y/p3PKVzmNh6a l0qFm8LLHyW1YYyY5eTMTAVc3zmJ6JP3PGaCii5WHeZSZyjbIa2Hy81/OPDqqR7C3o9B CT6cneLdDe3Y/LydYwyRla6ImBVA0Elz+e6x7nwrhGYwdIG/QNWLwqNAI8BkFDmuI7nk Cg7A== Received: by 10.68.234.167 with SMTP id uf7mr44484223pbc.20.1352838805238; Tue, 13 Nov 2012 12:33:25 -0800 (PST) Received: from Glaucomys.local ([64.213.70.194]) by mx.google.com with ESMTPS id j4sm6600364pax.31.2012.11.13.12.33.23 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 12:33:24 -0800 (PST) Message-ID: <50A2AE92.7000909@thaumas.net> Date: Tue, 13 Nov 2012 12:33:22 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk/tmYSLK833jddTrirTN8Zcui4YT8rwKn+gVtbapPqFIOdEBb9irMO2r7S8QzgBRYemb6P Subject: [codec] opusfile 0.2 release X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:33:30 -0000 Tim has written a high-level library called 'opusfile' for decoding .opus streams from disk, memory, or http, similar to what libvorbisfile does for .ogg (Vorbis) streams. You may find it interesting. It handles containerization for file storage according to draft-terriberry-oggopus, which we have consensus to adopt as a working group document, and in particular an efficient seeking implementation. The library is functional, but there are likely issues we didn't find in our own testing. Please give feedback in #opus on irc.freenode.net or on this list. You can download the source code here: http://downloads.xiph.org/releases/opus/opusfile-0.2.tar.gz Windows binaries (with HTTP support disabled) are here: https://ftp.mozilla.org/pub/mozilla.org/opus/win32/opusfile-0.2-win32.zip Thanks to everyone who contributed to the release. -r From internet-drafts@ietf.org Mon Nov 19 14:52:14 2012 Return-Path: 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 D73B721F8772; Mon, 19 Nov 2012 14:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pFvcGwiQUiGE; Mon, 19 Nov 2012 14:52:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB5C21F8775; Mon, 19 Nov 2012 14:52:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 14:52:13 -0800 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:52:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working Gro= up of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Author(s) : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-00.txt Pages : 30 Date : 2012-11-19 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Ogg encapsulation provides Opus with a long-term storage format supporting all of the essential features, including metadata, fast and accurate seeking, corruption detection, recapture after errors, low overhead, and the ability to multiplex Opus with other codecs (including video) with minimal buffering. It also provides a live streamable format, capable of delivery over a reliable stream-oriented transport, without requiring all the data, or even the total length of the data, up-front, in a form that is identical to the on-disk storage format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-oggopus-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tterribe@xiph.org Mon Nov 19 15:00:21 2012 Return-Path: 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 A6E5C21F8471 for ; Mon, 19 Nov 2012 15:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 wEKxVLzY8NwV for ; Mon, 19 Nov 2012 15:00:21 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4E21F858F for ; Mon, 19 Nov 2012 15:00:20 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 921BEF20F2 for ; Mon, 19 Nov 2012 15:00:16 -0800 (PST) Message-ID: <50AABA00.6030102@xiph.org> Date: Mon, 19 Nov 2012 15:00:16 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: codec@ietf.org References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> In-Reply-To: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:00:21 -0000 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Wideband Audio Codec Working Group of the IETF. The (other) chairs declared there was consensus to adopt this draft as a WG item and asked me to upload a new version of it. I have made a few minor edits from draft-terriberry-oggopus-01: 1) Fixed up the references. 2) Fixed a couple of typos. 3) Replaced a "should" with a "SHOULD" in Section 4.1. 4) Clarified the language around the starting granule position in the case that a) there is more audio in packets that complete on the first audio data page with a completed packet than the granule position indicates and b) the EOS flag is set on the same page (in this case you should not count forwards from 0, but should work backwards to figure out the real starting granule position). 5) Updated the acknowledgments. I have not incorporated any of the proposals that have been made to the list since the initial draft was posted (e.g., seamless chaining, replaygain tags, etc.). From gmaxwell@juniper.net Mon Nov 26 08:33:28 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: Calvin Walton 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 16:33:28 -0000 =0A= Sorry for the delayed response=97 been tied up on other tasks.=0A= =0A= Calvin Walton [calvin.walton@kepstin.ca] wrote:=0A= > Hmm? Replaygain does specify a method. They go into a lot of details on= =0A= > http://www.replaygain.org/ to describe the loudness filter used, the=0A= > method for calculating RMS power levels afterwards, the histogram-based= =0A= > statistical processing, and how to calibrate the gain level to the -83dB= =0A= > reference with a pink noise signal.=0A= =0A= It offers one, yes=97 but it's not a specification. I was stridently correc= ted by the author of replaygain when I made the same claim that you are.=0A= =0A= I'm also advised that most tools are now using the EBU R128 method now in a= ny case. And in practice the point is fairly moot as the values are effecti= vely compatible on actual audio once the reference level.=0A= =0A= > Yes, having the standard gain header that is supported by all decoders=0A= > is nice - except for the case of playback of mixed file formats,=0A= > particularly by an application that doesn't understand the gain tags in= =0A= > other formats. In those cases, the Opus files will be significantly=0A= > quieter (assuming modern pop mastering...) than the other files, making= =0A= > them sound "worse" than files without gain applied.=0A= =0A= 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 fro= m various sources you will have various levels.=0A= =0A= 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/mp3gai= n with respect to this.=0A= =0A= > I can do that; here's the CC attribution, non-commercial, share-alike=0A= > track "Discipline" by Nine Inch Nails, with vorbis-style replaygain tags= =0A= =0A= I still can't reproduce on my system, but I've asked people to fix it and t= he next version of these tools shouldn't have the weird behavior any longer= .=0A= =0A= > The issue I see here is that the normalization method used for the value= =0A= > in the opus header output gain field is *not specified* currently. An=0A= =0A= There is a recommendation, but it's not=97 and shouldn't be=97 a requiremen= t.=0A= =0A= > If a player blindly applies only the header output gain value, it has no= =0A= > knowledge of whether the output is loudness normalized or not.=0A= =0A= I'd like to say that there should be an informative tag there to indicate w= hats 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 no= thing most software can do with the information. There would be little way = for careless implementers to discover that they've gotten it wrong... and s= o the information would likely be worse than useless as it would just add c= omplexity without concrete value.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From calvin.walton@kepstin.ca Mon Nov 26 20:50:43 2012 Return-Path: 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 7C37B21F8487 for ; Mon, 26 Nov 2012 20:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGdYvk7w4Z51 for ; Mon, 26 Nov 2012 20:50:41 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6521F8488 for ; Mon, 26 Nov 2012 20:50:41 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so11049967ieb.31 for ; Mon, 26 Nov 2012 20:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=tEO5tFd6PXw50dQnSfpAp4ph/S50Trbyb/BYqevG2Xg=; b=pkXDRnbeu7mC3+XasAyOZRiEtNfUzDRGgO6L6FyVzthuu3eeJW+/x70m8jo5/eexyb ebblT2kpRo+EBvdtbX+d82kKVFIbM7XGglhGb/v2SNYzvZM1rKxVqFq2Iw+Vs5mPA6oZ S1Zqx0KyS00yNnvURw1drdmVrdijQIrgfc46U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding :x-gm-message-state; bh=tEO5tFd6PXw50dQnSfpAp4ph/S50Trbyb/BYqevG2Xg=; b=nB2RJOUo2Ud1ztTEziEGUQcEorXYYzWUsVXnkrO/2WcIV9DFD5nNH0RF4I/Hjss3PL sagVfBnIYqpWx2V98RlpUb2WsWOtQYs1OExgzuGRgle4bb7gcU+tFRbxwFxCz3nPJSqZ Mfksprbs0jPCp5djA7rbyKAuDAHA3mEeWRgVIyH9jpsCsEitJqEc4S1WUaLxqFHGFAjX /0PLGkDEvjRoq+vT0eVcEsgjUp57CBLTJYAklyMsk7cu9nm5iT0/dhZ2lSVceA0MRLdS 4YY53Ky7I4ZTYucsNpvWhQZ4PjTuV1mik3ldJk4LbDzeSBorOd+1W/Bc3qX2RXGbPL6T VGDg== Received: by 10.50.173.106 with SMTP id bj10mr17290257igc.13.1353991840939; Mon, 26 Nov 2012 20:50:40 -0800 (PST) Received: from [192.168.1.139] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [174.112.205.165]) by mx.google.com with ESMTPS id l8sm903866igo.13.2012.11.26.20.50.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 20:50:40 -0800 (PST) Message-ID: <1353991837.2000.41.camel@nayuki.kepstin.ca> From: Calvin Walton To: Gregory Maxwell Date: Mon, 26 Nov 2012 23:50:37 -0500 In-Reply-To: <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> ,<1352328081.14547.82.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQld/7vnMPxHc9pHio/+5+u0FkYBb+iKL6Dgn9wFpkDNGpySKjuXuvQyYv1zD8jbk41WcTpT Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 04:50:43 -0000 On Mon, 2012-11-26 at 16:30 +0000, Gregory Maxwell wrote: > 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... I've since looked into this a bit more. foobar2000 uses the R128 algorithm to calculate the values to store in ReplayGain comments; the command-line tools vorbisgain and metaflac that I normally use are still based on the older ReplayGain suggested algorithm. The ReplayGain reference value is 5 dB louder than the EBU R128 standard reference value, so compensating for the difference is straightforward. > > 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. My argument is based on using a player that supports Opus playback, supports ReplayGain tags, but does not support R128 gain tags. This is the case with some current players (e.g. Rockbox, Rhythmbox). All of my existing Ogg Vorbis files with ReplayGain tags will be played back 5 dB louder than an Opus file with R128 album gain stored in the header gain field. (A workaround for this would be to use the ReplayGain preamp to apply a -5 dB gain after the ReplayGain adjustment.) Alternately, if the Opus file has a R128_TRACK_GAIN comment present, but 0 in the header gain field, it will be played back unnormalized! For the case of older versions of Rhythmbox running with a newer Gstreamer library backend that supports decoding Opus, this situation may be maintained for quite a while. > > 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. If I select to use 'Album Gain' mode for ReplayGain in the playback menu of my iPod running Rockbox: http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch7.html#x10-1270007.9 there is currently no way for the player to know whether or not the arbitrary value in the header gain field represents R128-normalized album gain or something completely different. Most players fall back to using the track gain field if the album gain is not present - but this can't work properly with the current specification of Ogg Opus. They must either assume that the user has put R128 album gain into the header gain field (I think foobar2000 currently does this), or only use track gain. My personal suggestion would be to have an R128_ALBUM_GAIN field, with the same format and similar semantics to the R128_TRACK_GAIN field. In the case where the album gain is stored in the header gain field, the R128_ALBUM_GAIN field SHOULD be present and be filled with a value of '0', indicating that no further adjustment is needed to get R128 album normalized loudness. -- Calvin Walton From calvin.walton@kepstin.ca Mon Nov 26 23:36:21 2012 Return-Path: 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 F3E8F21F853C for ; Mon, 26 Nov 2012 23:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-1.815, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_LOW=-1] 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 33jnywtkeqk0 for ; Mon, 26 Nov 2012 23:36:20 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1521F8565 for ; Mon, 26 Nov 2012 23:36:19 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so11208714ieb.31 for ; Mon, 26 Nov 2012 23:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=3X/GakxigwZ7XrfCKjjuN1IAb2Opvejsbc5FChxfBYg=; b=btKggj++Ytup69NvjPw+3WyxaPN516H+Ga1TZJ8DAx2HouYCmct2i9ZB+dDfKKzJ7k UdR+2y1HRViSXQnETdY0xPoDGSvKPWyQAZuiE7iUGEth0P7RVAFlfDjevGMlg2XuobGu fb7JRPiA7wOe/8+lDZZPVLz2HFEP0SogZQ8aI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding :x-gm-message-state; bh=3X/GakxigwZ7XrfCKjjuN1IAb2Opvejsbc5FChxfBYg=; b=JgagBOLW2zpnaUn007OIRH5UkVG3pIds7Zsqnb1UYyEewBheulm+HS6ZEUGjaiOqOK 84Fipz/sI06Ox5dIqb2E/PUQ1l45GcnzGNR9AuJL6BczGCqKEuJWBwdKiMNOUdXP+MdU G839zv9ZfCawTC8CvHTHr86v8IcgveIC4Aeo9AEjNrTosAraXTGPF3W8r/9k2cQXtM4a KzLE2KRpOrs4gKYR1xgfH6HY9ikXb4IgUYwN1Py4VEspczxkNRF2sEyVXZpc/aZb+jGL X0i8dLBuBUn6jUGcVqOH4fICTXfLIphVmMyIqvphHZjITFGH06O1kN9yNFEhTc7jO5Kh x5Sg== Received: by 10.42.176.194 with SMTP id bf2mr13028272icb.50.1354001779306; Mon, 26 Nov 2012 23:36:19 -0800 (PST) Received: from [192.168.1.139] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [174.112.205.165]) by mx.google.com with ESMTPS id eo7sm1161565igc.12.2012.11.26.23.36.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 23:36:18 -0800 (PST) Message-ID: <1354001776.2000.87.camel@nayuki.kepstin.ca> From: Calvin Walton To: Gregory Maxwell Date: Tue, 27 Nov 2012 02:36:16 -0500 In-Reply-To: <1353991837.2000.41.camel@nayuki.kepstin.ca> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> ,<1352328081.14547.82.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> <1353991837.2000.41.camel@nayuki.kepstin.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnqRCvWzrlYxPaMy1yLgSqab/rbX8amgKIen7+uqNeQsxuZzFPJdBMCMyXNU+TJwAOesalF Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 07:36:21 -0000 On Mon, 2012-11-26 at 23:50 -0500, Calvin Walton wrote: > On Mon, 2012-11-26 at 16:30 +0000, Gregory Maxwell wrote: > > > 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. > > My argument is based on using a player that supports Opus playback, > supports ReplayGain tags, but does not support R128 gain tags. This is > the case with some current players (e.g. Rockbox, Rhythmbox). > > All of my existing Ogg Vorbis files with ReplayGain tags will be played > back 5 dB louder than an Opus file with R128 album gain stored in the > header gain field. (A workaround for this would be to use the ReplayGain > preamp to apply a -5 dB gain after the ReplayGain adjustment.) > > Alternately, if the Opus file has a R128_TRACK_GAIN comment present, but > 0 in the header gain field, it will be played back unnormalized! > > For the case of older versions of Rhythmbox running with a newer > Gstreamer library backend that supports decoding Opus, this situation > may be maintained for quite a while. Sorry for the double post, but I wanted to elaborate on this a bit: This is why I'm currently putting the Vorbis-style ReplayGain tags into my Ogg Opus files - they are interoperable with existing players, and work right now. For the time being, in my personal files I'm using the following backwards- and hopefully forwards-compatible structure: New logical stream (#1, serial: 00332868): type opus Encoded with libopus 1.0.1 User comments section follows... [...] REPLAYGAIN_ALBUM_GAIN=+5.00 dB REPLAYGAIN_TRACK_GAIN=+4.72 dB REPLAYGAIN_TRACK_PEAK=0.171997 REPLAYGAIN_ALBUM_PEAK=0.184993 R128_TRACK_GAIN=-72 Opus stream 1: Pre-skip: 356 Playback gain: -15.2891 dB where the playback gain is an arbitrary number that bears a striking resemblance to the R128 album gain, R128_TRACK_GAIN is a relative adjustment to -23 LUFS reference, the REPLAYGAIN_*_GAIN comments are relative adjustments to -14 LUFS reference (literally just the corresponding R128 values +5 dB), and the REPLAYGAIN_*_PEAK tags contain the peak after playback gain is applied, but before ReplayGain is applied. (Note that the ReplayGain peak tags are required to tell the GStreamer 'rgvolume' element that it is safe to increase the volume by 5 dB without clipping; otherwise it will refuse to go above +0 dB.) This gives me working volume normalization in all of the players that I use regularly. Rhythmbox and Rockbox use the ReplayGain comments, applied after the playback gain field. foobar2000 uses the R128 track gain comment and the playback gain field (it assumes that playback gain contains the R128 album gain), adjusts both +5 dB, then uses them as ReplayGain values. But the combination certainly looks really ugly, for what that's worth :) -- Calvin Walton From ron@debian.org Mon Nov 26 23:59:22 2012 Return-Path: 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 9196621F852E for ; Mon, 26 Nov 2012 23:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 AMePEV3MZWFp for ; Mon, 26 Nov 2012 23:59:21 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9121F84E0 for ; Mon, 26 Nov 2012 23:59:20 -0800 (PST) Received: from ppp118-210-61-159.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.61.159]) by ipmail06.adl2.internode.on.net with ESMTP; 27 Nov 2012 18:29:19 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 5E36D4F8F3; Tue, 27 Nov 2012 18:29:18 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s42eapyfySFQ; Tue, 27 Nov 2012 18:29:10 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 0FACC4F902; Tue, 27 Nov 2012 18:29:10 +1030 (CST) Date: Tue, 27 Nov 2012 18:29:10 +1030 From: Ron To: Calvin Walton Message-ID: <20121127075909.GH2043@audi.shelbyville.oz> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> <1353991837.2000.41.camel@nayuki.kepstin.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1353991837.2000.41.camel@nayuki.kepstin.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 07:59:22 -0000 On Mon, Nov 26, 2012 at 11:50:37PM -0500, Calvin Walton wrote: > If I select to use 'Album Gain' mode for ReplayGain in the playback menu > of my iPod running Rockbox: > http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch7.html#x10-1270007.9 > there is currently no way for the player to know whether or not the > arbitrary value in the header gain field represents R128-normalized > album gain or something completely different. The only thing the decoder needs to know about the header gain is that it should _always_ apply it. Trying to assign some other meaning to it and then applying it selectively is precisely the kind of confusion, misbehaviour, and random difference between players that this mechanism aims to avoid. The draft says "virtually all players", because specialised applications may have reasons to want the raw data level, but the simple rule for most players is "you can't know what it means, it's the level the author of the file wanted samples decoded at, just always apply it before doing anything else". Trying to attach an 'album gain' mode selector switch to it adds the kind of chaos that this recommendation is meant to avoid: To avoid confusion with multiple normalization schemes, an Opus comment header SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags. In the absence of an ALBUM_GAIN tag, your album gain mode switch should simply do exactly nothing at all. If it tries to do something that it thinks is "smart" instead, then it's lying to you about what the album gain switch does (unless it's actually going to analyse the whole album for you on the fly...). > Most players fall back to using the track gain field if the album gain > is not present - but this can't work properly with the current > specification of Ogg Opus. They must either assume that the user has put > R128 album gain into the header gain field (I think foobar2000 currently > does this), or only use track gain. If there are players where you explicitly select "album gain" and they instead arbitrarily apply "track gain" instead, then I would say that they are already not working properly. But since we do seem to have generated some confusion here with at least one person, I wonder if we need to reword this clause in the spec: There is no Opus comment tag corresponding to REPLAYGAIN_ALBUM_GAIN. That information should instead be stored in the ID header's 'output gain' field. You seem to have confused that with "header gain may mean album gain". That's not what it means at all. What it means is "album gain is useless and most things only get it wrong". If you want your files normalised to that level, and didn't do that when you first encoded them, then you can still do it 'losslessly' by adjusting the header gain field later. That way, _every_ player, that doesn't apply some other gain of its own, will play them back with the desired "album gain". And since "album gain" is basically a euphemism for "play all tracks at the level that the artist intended, not at some false-normalised level" -- that actually corresponds fairly well to what the header gain does. If an entire album is _supposed_ to be exceptionally quiet, or similarly exceptionally loud, then you don't _want_ it normalised to some arbitrary muzak sound pressure level that is the same for all albums. Header gain lets you have all of those options, with the best guarantee we can give that it will actually work the same in all players. > My personal suggestion would be to have an R128_ALBUM_GAIN field, with > the same format and similar semantics to the R128_TRACK_GAIN field. In > the case where the album gain is stored in the header gain field, the > R128_ALBUM_GAIN field SHOULD be present and be filled with a value of > '0', indicating that no further adjustment is needed to get R128 album > normalized loudness. If you want all your albums to play at exactly the same level, regardless of what the author intended, then you can tweak the header gain field without re-encoding (and you become the new author that all players will respect the choices of). Selecting track gain does not mean that a player should ignore the header gain. It means the player should apply that relative to the already applied header gain _in addition_. Likewise, unselecting album gain should _never_ cause a player to ignore the header gain. If you are already confused with just 2 gain knobs to adjust, can you imagine how many extra permutations of confused some people will be if we add even more of them, with even more rules for when to apply them? I don't mean to dismiss your concerns here, but I get the feeling that there's some element of people talking past each other with different impressions of what the same things actually mean. And if that is the case, then we should clarify the spec to better explain that header gain is NOT "album gain", and should not be interpreted as such by any 'normal' player. All the spec is intended to say is that an author _may_ use it for that, just as they may use it to normalise to any other arbitrary level that is appropriate for the *default* playback of that file. But it's not the job of a player to know what it is supposed to mean - for a player to behave correctly, and the same as all other players, all it needs to do is just always apply it. We can't make a rule that is much simpler to always get right across all player implementations than that :) Does that makes sense? Cheers, Ron From calvin.walton@kepstin.ca Tue Nov 27 01:52:56 2012 Return-Path: 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 0818621F850E for ; Tue, 27 Nov 2012 01:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 smkuLi-jqzMF for ; Tue, 27 Nov 2012 01:52:54 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8C21F8507 for ; Tue, 27 Nov 2012 01:52:53 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so11376102ieb.31 for ; Tue, 27 Nov 2012 01:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=p62x2+rWcT8yH38hq9ceO5qgaTK8C3yA3rVx9QJDp3g=; b=mryZ2vjuW++wKsNNAQtdcErqFONfI2+tcySqSD0a5rwMVPjuT4YUl1O2tQowWoJMbO rBtaQZb//LewAuYq6xEwjhl59DCTRZH7g1t4LY1aljtjIVPoTvKCVL/VZQAo+uOOwFo8 kThgI4Ch1ehrp+pYocwp0HfeAfthdve3Domn8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=p62x2+rWcT8yH38hq9ceO5qgaTK8C3yA3rVx9QJDp3g=; b=fO7kNQE4yCHzh67kyrCGXp2azPAgGrQ+fTPBeqD5paLf8SyQa4jzGyxqEsFv370ntT zKCAK9Biih/Hcr/IhuOZT6Nm1epT6ulnqxUVtCRmhmzA+WP3ly/3pWkiFhJ7DsBHP3Fv bDHiBglYOzS7AsjvLx0rlUIMUfE/wCpieuAs6eupKBytUSwEWU4+Ys8Iuc2zuleT+3yX Kjx4GGIQ/EvaNCugLWMNAVc8M2nxJyuG6zr9ar73ZXEv25vJkWxbFGGhMNmQR5COi84S uDcAUrb5xMNGcCxjO2nQ6IuQDyi5LQGy1IjWElPbwwyfDMxt7iP3xp9gG+Dr/EQFIg9G Mu7w== Received: by 10.50.41.129 with SMTP id f1mr14754516igl.53.1354009973244; Tue, 27 Nov 2012 01:52:53 -0800 (PST) Received: from [192.168.1.106] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [174.112.205.165]) by mx.google.com with ESMTPS id gz10sm1347765igc.9.2012.11.27.01.52.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 01:52:51 -0800 (PST) Message-ID: <1354009968.10253.55.camel@ayu> From: Calvin Walton To: Ron Date: Tue, 27 Nov 2012 04:52:48 -0500 In-Reply-To: <20121127075909.GH2043@audi.shelbyville.oz> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> <1353991837.2000.41.camel@nayuki.kepstin.ca> <20121127075909.GH2043@audi.shelbyville.oz> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-ixOB8mHezg2r7mlJiqgg" X-Mailer: Evolution 3.6.0 Mime-Version: 1.0 X-Gm-Message-State: ALoCoQnbSBzaQ2Anst0B4e8KwSjFKmtfU9YEwAvEDBmmuBEJm5ii+hCnliXbOaVO3BCkV91Br+HW Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 09:52:56 -0000 --=-ixOB8mHezg2r7mlJiqgg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-11-27 at 18:29 +1030, Ron wrote: > On Mon, Nov 26, 2012 at 11:50:37PM -0500, Calvin Walton wrote: > > If I select to use 'Album Gain' mode for ReplayGain in the playback men= u > > of my iPod running Rockbox: > > http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buil= dch7.html#x10-1270007.9 > > there is currently no way for the player to know whether or not the > > arbitrary value in the header gain field represents R128-normalized > > album gain or something completely different. >=20 > The only thing the decoder needs to know about the header gain is that > it should _always_ apply it. Trying to assign some other meaning to it > and then applying it selectively is precisely the kind of confusion, > misbehaviour, and random difference between players that this mechanism > aims to avoid. This is very different from the ReplayGain tags. ReplayGain is *optional* at playback time, and is only applied if the user *explicitly* requests one or the other type of loudness normalization. The issue is coming in because there are players that already support the ReplayGain model, and they are trying to shoe-horn approximately corresponding values into Opus header and comment fields that don't share the same semantics. ReplayGain-supporting players typically have 3 settings: 1. ReplayGain off: Use the original audio levels of the file (as set by the mastering engineer/record label/artist/file encoder) 2. ReplayGain album mode: Normalize the loudness of an album, but keep track-track variations. This is the counter to the loudness wars (see below), and is useful for general listening. 3. ReplayGain track mode: Normalize all tracks to the same loudness. Useful for things like party background music randomly selected from multiple albums, or listening to music on public transit from a portable player, where a quiet song could be drowned out. Players based on the current Ogg Opus standard cannot support all 3 modes on a single file, because the playback gain field may contain either 1, 2, or something else entirely at the discretion of the person who last modified the audio file. Note that I generally want the "default" playback of the file to be at original levels, so that if I e.g. pass a file to a friend who does not use ReplayGain, they don't complain that "This file is too quiet!" Keep in mind that a file of pop music with R128 normalization might play back 15 dB (or more!) quieter than the original signal! As a result, I want my preferred playback loudness to be stored *separately* from the default value, in a place where it is only used if I explicitly select either album or track gain (and which one I choose depends on what conditions I am listening to music under.) > In the absence of an ALBUM_GAIN tag, your album gain mode switch should > simply do exactly nothing at all. If it tries to do something that it > thinks is "smart" instead, then it's lying to you about what the album > gain switch does (unless it's actually going to analyse the whole album > for you on the fly...). The reason for this is kind of a best effort fallback: You asked for music to be normalized loudness. If it can't be normalized in the manner you asked, a fallback would be to estimate a close level - Track gain is usually within 1-2 dB of album gain on most releases. If this isn't done, you could (given modern pop mastering) suddenly get a track that's 10 dB (add 5 dB if you're using R128 instead of ReplayGain) or more louder than everything else, simply because e.g. it was a single-track download and you didn't notice that your scanning tool didn't add 'album' gain to it. It's to protect your ears and/or speakers. > But since we do seem to have generated some confusion here with at least > one person, I wonder if we need to reword this clause in the spec: >=20 >=20 > There is no Opus comment tag corresponding to REPLAYGAIN_ALBUM_GAIN. > That information should instead be stored in the ID header's 'output > gain' field. >=20 >=20 > You seem to have confused that with "header gain may mean album gain". > That's not what it means at all. What it means is "album gain is useless > and most things only get it wrong". If you want your files normalised > to that level, and didn't do that when you first encoded them, then you > can still do it 'losslessly' by adjusting the header gain field later. >=20 > That way, _every_ player, that doesn't apply some other gain of its own, > will play them back with the desired "album gain". And since "album gain= " > is basically a euphemism for "play all tracks at the level that the artis= t > intended, not at some false-normalised level" -- that actually correspond= s > fairly well to what the header gain does. >=20 > If an entire album is _supposed_ to be exceptionally quiet, or similarly > exceptionally loud, then you don't _want_ it normalised to some arbitrary > muzak sound pressure level that is the same for all albums. > Header gain lets you have all of those options, with the best guarantee > we can give that it will actually work the same in all players. > If you want all your albums to play at exactly the same level, regardless > of what the author intended, then you can tweak the header gain field > without re-encoding (and you become the new author that all players will > respect the choices of). Unfortunately, if the record labels and mastering engineers get their choice of selecting the playback level, you get something called "Loudness Wars", because of the purely psychological fact that louder music sounds better. This dates back to the days of vinyl, when e.g. particularly "hot" vinyl masters would sound better when played in a jukebox. Over the ~18 years that we've had CDs, the mastering volume of pop music on CD has gone up around 10 dB. Record labels are refusing to release quieter music, because it won't sound as good as the existing loud recordings that someone already has. And online music sales have to sound as good as the CD you just ripped (The artist rarely gets a say in the matter, really...) The main point of ReplayGain in album mode is to counter this trend and even out the levels between albums, because the listener doesn't trust the mastering engineer's choice of volume. > Selecting track gain does not mean that a player should ignore the header > gain. It means the player should apply that relative to the already > applied header gain _in addition_. Likewise, unselecting album gain > should _never_ cause a player to ignore the header gain. All players that I've tested handle this correctly. Players always apply the header gain, then any other gain values on top of that. > I don't mean to dismiss your concerns here, but I get the feeling that > there's some element of people talking past each other with different > impressions of what the same things actually mean. And if that is the > case, then we should clarify the spec to better explain that header > gain is NOT "album gain", and should not be interpreted as such by any > 'normal' player. If this is the case, then there should be a separate album gain field so that there is a place to store a value which a player could interpret as such. > All the spec is intended to say is that an author _may_ use it for that, > just as they may use it to normalise to any other arbitrary level that > is appropriate for the *default* playback of that file. But it's not > the job of a player to know what it is supposed to mean - for a player > to behave correctly, and the same as all other players, all it needs to > do is just always apply it. We can't make a rule that is much simpler > to always get right across all player implementations than that :) Players have already screwed this up, by assigning additional meaning to a field which wasn't intended, since there wasn't a field corresponding to the exact meaning desired. --=20 Calvin Walton --=-ixOB8mHezg2r7mlJiqgg Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTI3MDk1 MjQ4WjAjBgkqhkiG9w0BCQQxFgQUdo8ddNA1WqoNLRk5B9nVcPgmwecwDQYJKoZIhvcNAQEBBQAE ggEAuB4nKYfakGyF6TK3DumthbBOX9ZNzDCCs52YwlZ11IFVEEpjDHG7KS0/n8jeegL/zvPsgiFe +gcd2A6GEPboPhG9TFRu89yIzey0VFItxK8hecnOBxpTSz0hCUccowtOe1FE1/K74tAu79OmDuK+ KXX1JpBjINs44Bxa+RBBsSy2NFJOvgk0swMXwi4kghcOYG4mtdYBcQYscl9kKONb/Nl2LY1ng2Yv 2ZgdT1nwp7auUxW81QoUPRsTxFKHo6onnFuvIjaVMahyM4AR4OfspyjsVRGUiuaKg1rqvkn3OOPI PJZ+wlktjCN3DuQLDpNpuORE0qeoA6aZ6zVaMyvhkQAAAAAAAA== --=-ixOB8mHezg2r7mlJiqgg-- From ron@debian.org Tue Nov 27 04:14:34 2012 Return-Path: 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 0978721F84BA for ; Tue, 27 Nov 2012 04:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 0IF1mYYdpsnC for ; Tue, 27 Nov 2012 04:14:30 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id A04D221F84B9 for ; Tue, 27 Nov 2012 04:14:29 -0800 (PST) Received: from ppp118-210-61-159.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.61.159]) by ipmail07.adl2.internode.on.net with ESMTP; 27 Nov 2012 22:44:27 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 326AC4F8F3; Tue, 27 Nov 2012 22:38:40 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tgy3D0HJjK9V; Tue, 27 Nov 2012 22:38:38 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 661EE4F902; Tue, 27 Nov 2012 22:38:38 +1030 (CST) Date: Tue, 27 Nov 2012 22:38:38 +1030 From: Ron To: Calvin Walton Message-ID: <20121127120838.GJ2043@audi.shelbyville.oz> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> <1353991837.2000.41.camel@nayuki.kepstin.ca> <20121127075909.GH2043@audi.shelbyville.oz> <1354009968.10253.55.camel@ayu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1354009968.10253.55.camel@ayu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 12:14:34 -0000 On Tue, Nov 27, 2012 at 04:52:48AM -0500, Calvin Walton wrote: > On Tue, 2012-11-27 at 18:29 +1030, Ron wrote: > > On Mon, Nov 26, 2012 at 11:50:37PM -0500, Calvin Walton wrote: > > > If I select to use 'Album Gain' mode for ReplayGain in the playback menu > > > of my iPod running Rockbox: > > > http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch7.html#x10-1270007.9 > > > there is currently no way for the player to know whether or not the > > > arbitrary value in the header gain field represents R128-normalized > > > album gain or something completely different. > > > > The only thing the decoder needs to know about the header gain is that > > it should _always_ apply it. Trying to assign some other meaning to it > > and then applying it selectively is precisely the kind of confusion, > > misbehaviour, and random difference between players that this mechanism > > aims to avoid. > > This is very different from the ReplayGain tags. ReplayGain is > *optional* at playback time, and is only applied if the user > *explicitly* requests one or the other type of loudness normalization. Header gain is not about normalisation. It is about being able to change the gain deterministically for all players, in a way that actually works the same for everyone everywhere, without needing to re-encode the file. > The issue is coming in because there are players that already support > the ReplayGain model, and they are trying to shoe-horn approximately > corresponding values into Opus header and comment fields that don't > share the same semantics. If there really are players that are doing it wrongly, then bugs should be reported to their authors. > ReplayGain-supporting players typically have 3 settings: > 1. ReplayGain off: Use the original audio levels of the file (as > set by the mastering engineer/record label/artist/file encoder) > 2. ReplayGain album mode: Normalize the loudness of an album, but > keep track-track variations. This is the counter to the loudness > wars (see below), and is useful for general listening. > 3. ReplayGain track mode: Normalize all tracks to the same > loudness. Useful for things like party background music randomly > selected from multiple albums, or listening to music on public > transit from a portable player, where a quiet song could be > drowned out. > > Players based on the current Ogg Opus standard cannot support all 3 > modes on a single file, because the playback gain field may contain > either 1, 2, or something else entirely at the discretion of the person > who last modified the audio file. No, the header gain _never_ contains 1 or 2, it is always and only an entirely discretionary post-encoding adjustment. This ensures there will never be any confusion about what it "means". > Note that I generally want the "default" playback of the file to be at > original levels, so that if I e.g. pass a file to a friend who does not > use ReplayGain, they don't complain that "This file is too quiet!" Keep > in mind that a file of pop music with R128 normalization might play back > 15 dB (or more!) quieter than the original signal! > > As a result, I want my preferred playback loudness to be stored > *separately* from the default value, in a place where it is only used if > I explicitly select either album or track gain (and which one I choose > depends on what conditions I am listening to music under.) > > > In the absence of an ALBUM_GAIN tag, your album gain mode switch should > > simply do exactly nothing at all. If it tries to do something that it > > thinks is "smart" instead, then it's lying to you about what the album > > gain switch does (unless it's actually going to analyse the whole album > > for you on the fly...). > > The reason for this is kind of a best effort fallback: You asked for > music to be normalized loudness. If it can't be normalized in the manner > you asked, a fallback would be to estimate a close level - Track gain is > usually within 1-2 dB of album gain on most releases. > > If this isn't done, you could (given modern pop mastering) suddenly get > a track that's 10 dB (add 5 dB if you're using R128 instead of > ReplayGain) or more louder than everything else, simply because e.g. it > was a single-track download and you didn't notice that your scanning > tool didn't add 'album' gain to it. It's to protect your ears and/or > speakers. If you're within 10dB of blowing your speakers, your ears are already lost. If you're relying on this to save either of them, then you'd better never change your player software, and hope nothing or nobody ever changes the current settings in it without you noticing. I'd certainly change my player if it applied track gain when I didn't ask for track gain to be applied. > > But since we do seem to have generated some confusion here with at least > > one person, I wonder if we need to reword this clause in the spec: > > > > > > There is no Opus comment tag corresponding to REPLAYGAIN_ALBUM_GAIN. > > That information should instead be stored in the ID header's 'output > > gain' field. > > > > > > You seem to have confused that with "header gain may mean album gain". > > That's not what it means at all. What it means is "album gain is useless > > and most things only get it wrong". If you want your files normalised > > to that level, and didn't do that when you first encoded them, then you > > can still do it 'losslessly' by adjusting the header gain field later. > > > > That way, _every_ player, that doesn't apply some other gain of its own, > > will play them back with the desired "album gain". And since "album gain" > > is basically a euphemism for "play all tracks at the level that the artist > > intended, not at some false-normalised level" -- that actually corresponds > > fairly well to what the header gain does. > > > > If an entire album is _supposed_ to be exceptionally quiet, or similarly > > exceptionally loud, then you don't _want_ it normalised to some arbitrary > > muzak sound pressure level that is the same for all albums. > > Header gain lets you have all of those options, with the best guarantee > > we can give that it will actually work the same in all players. > > > If you want all your albums to play at exactly the same level, regardless > > of what the author intended, then you can tweak the header gain field > > without re-encoding (and you become the new author that all players will > > respect the choices of). > > Unfortunately, if the record labels and mastering engineers get their > choice of selecting the playback level, you get something called > "Loudness Wars", because of the purely psychological fact that louder > music sounds better. This dates back to the days of vinyl, when e.g. > particularly "hot" vinyl masters would sound better when played in a > jukebox. Over the ~18 years that we've had CDs, the mastering volume of > pop music on CD has gone up around 10 dB. Record labels are refusing to > release quieter music, because it won't sound as good as the existing > loud recordings that someone already has. And online music sales have to > sound as good as the CD you just ripped (The artist rarely gets a say in > the matter, really...) > > The main point of ReplayGain in album mode is to counter this trend and > even out the levels between albums, because the listener doesn't trust > the mastering engineer's choice of volume. So you don't trust them to set the header gain to a level you don't like, but you do trust them not to set ALBUM_GAIN = +11 ? You don't need album gain to be able to fix this. > > Selecting track gain does not mean that a player should ignore the header > > gain. It means the player should apply that relative to the already > > applied header gain _in addition_. Likewise, unselecting album gain > > should _never_ cause a player to ignore the header gain. > > All players that I've tested handle this correctly. Players always apply > the header gain, then any other gain values on top of that. Then maybe there are no bugs to report to them after all ... ? > > I don't mean to dismiss your concerns here, but I get the feeling that > > there's some element of people talking past each other with different > > impressions of what the same things actually mean. And if that is the > > case, then we should clarify the spec to better explain that header > > gain is NOT "album gain", and should not be interpreted as such by any > > 'normal' player. > > If this is the case, then there should be a separate album gain field so > that there is a place to store a value which a player could interpret as > such. > > > All the spec is intended to say is that an author _may_ use it for that, > > just as they may use it to normalise to any other arbitrary level that > > is appropriate for the *default* playback of that file. But it's not > > the job of a player to know what it is supposed to mean - for a player > > to behave correctly, and the same as all other players, all it needs to > > do is just always apply it. We can't make a rule that is much simpler > > to always get right across all player implementations than that :) > > Players have already screwed this up, by assigning additional meaning to > a field which wasn't intended, since there wasn't a field corresponding > to the exact meaning desired. Now you have me confused. Did they *actually* screw this up or not? And how would making it even more complicated help them screw it up less? So far as I can see still, you're trying to find a use for an "album gain" button that your application gave you, which isn't actually of any use at all for this format, because the problem that album gain was invented to solve doesn't actually exist with this format like it does for some others. You have two very simple knobs. Default gain, and normalised gain. The latter being entirely optional for both users and players, and both of which can be changed by the user losslessly if desired. If you say you want multiple levels of normalised, then where does this stop? Should we also provide equalisation profiles for every room that you listen in and every piece of audio equipment you use to play it? Aside from "making things an overcomplicated mess like ReplayGain", what real problem cannot be solved with the degrees of freedom that the current spec already gives you? Ron From calvin.walton@kepstin.ca Tue Nov 27 08:53:06 2012 Return-Path: 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 98C7121F85A4 for ; Tue, 27 Nov 2012 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 242GdPN8n5Zc for ; Tue, 27 Nov 2012 08:53:05 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 469C421F85C5 for ; Tue, 27 Nov 2012 08:53:05 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so12106413ieb.31 for ; Tue, 27 Nov 2012 08:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kepstin.ca; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=sY6pz/a/DVcVkSAzmw9D5ORPVN0KY1vqZvwurXkIVKo=; b=U2fvFdOtEN1kjzz9A4XaJ1130G+Af57BegsjYtGx7xUhyisXNyKZTZeUAjl8LXXBXH 3pu7bdtiqEoydfbpFiAfjuFHl2SjMOho54MTdf/dBLxfq0vWFAav/0OzRj4aaHg+2KQb x1yblkY3bgghmIbIV48en9afIWIX+Y0pA7URc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:x-gm-message-state; bh=sY6pz/a/DVcVkSAzmw9D5ORPVN0KY1vqZvwurXkIVKo=; b=mUoxbawmxHaMgBo089QG6+kORNeuDLru9oAQ7dJM/DTtvt5g00b0Q9U7aYl0ihrtUz Y3Wm1ttnIQ09CWOo1G2BJcxq5WL0H9fRTYvxIcPitHXYOnHjdHjLT5EWRv/SWeQUh19n chfgxuBVcbd1e5H0M0c+cBghOczn/CNxjIoxc1lwKG1AiVm3Awcws0yeHjzoiijoaEko kDAMeMnbmvQRpn+AKYcRU1lpRzPRijRU0uQMNN2E7yUHo2MZNY0baf2YELKuunODlQgQ G6zmmZiOFVy4bXcWTRGRBFrqCKqVHs+UgAp/yrz01bNPkMCEeFmYFhibsd78CvokdrnO yy5w== Received: by 10.50.34.225 with SMTP id c1mr18625862igj.67.1354035184826; Tue, 27 Nov 2012 08:53:04 -0800 (PST) Received: from [192.168.1.106] (CPE586d8fb6db38-CM78cd8e665875.cpe.net.cable.rogers.com. [174.112.205.165]) by mx.google.com with ESMTPS id xn10sm1951067igb.4.2012.11.27.08.53.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 08:53:03 -0800 (PST) Message-ID: <1354035181.10253.88.camel@ayu> From: Calvin Walton To: Ron Date: Tue, 27 Nov 2012 11:53:01 -0500 In-Reply-To: <20121127120838.GJ2043@audi.shelbyville.oz> References: <1352307794.14547.30.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE08C500@CH1PRD0511MB432.namprd05.prod.outlook.com> <1352328081.14547.82.camel@ayu> <9B8EA46C78239244B5F7A07E163D3DFE05F88C2D@CH1PRD0511MB432.namprd05.prod.outlook.com> <1353991837.2000.41.camel@nayuki.kepstin.ca> <20121127075909.GH2043@audi.shelbyville.oz> <1354009968.10253.55.camel@ayu> <20121127120838.GJ2043@audi.shelbyville.oz> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-iC6FbjE7FmVoHxrKUyzi" X-Mailer: Evolution 3.6.0 Mime-Version: 1.0 X-Gm-Message-State: ALoCoQmiq32IQ/ipCXyxWFtlURTnEeCsb6W+p9REL8I7nFkcnDETIOWZKaGjZrhwPojLftxtY8vL Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 16:53:07 -0000 --=-iC6FbjE7FmVoHxrKUyzi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Players have already screwed this up, by assigning additional meaning t= o > > a field which wasn't intended, since there wasn't a field corresponding > > to the exact meaning desired. >=20 > Now you have me confused. Did they *actually* screw this up or not? >=20 > And how would making it even more complicated help them screw it up less? >=20 > So far as I can see still, you're trying to find a use for an "album gain= " > button that your application gave you, which isn't actually of any use at > all for this format, because the problem that album gain was invented to > solve doesn't actually exist with this format like it does for some other= s. >=20 > You have two very simple knobs. Default gain, and normalised gain. > The latter being entirely optional for both users and players, and both > of which can be changed by the user losslessly if desired. >=20 > If you say you want multiple levels of normalised, then where does this > stop? Should we also provide equalisation profiles for every room that > you listen in and every piece of audio equipment you use to play it? >=20 > Aside from "making things an overcomplicated mess like ReplayGain", what > real problem cannot be solved with the degrees of freedom that the curren= t > spec already gives you? Let me state my goals simply: 1. I want my Ogg Opus albums to play back at the same loudness as my existing albums in other formats (Vorbis, Flac, Mp3, etc.) that are using ReplayGain. 2. I would like to be able to at playback time select track-based normalization instead of my normal preferred loudness. 3. Ideally, I want to be able to give one of my files to a friend who doesn't normally use ReplayGain, without them complaining that "This is too quiet!" #1 is pretty simple to do with header gain: I just store my album ReplayGain values in the header gain field. Most of my players get this right, but foobar2000 gets this wrong, and adds +5 dB to the value when playing it because it assumes that the field contains R128 normalized levels and it is compensating. We probably still have time to get them to fix this before the rest of the world decides to follow "what foobar2000 does" for compatibility :) #2 is OK in theory using the R128_TRACK_GAIN tag, except that most of the players I use don't know how to apply it yet. This is in general not too bad, because they still apply the header gain, so the level is close... but not correct. #3 I can't do if the header gain field contains anything other than 0, really. So I end up having an extra step of stripping out my personal gain modification settings before giving away a file. Or, alternatively, I can set the header gain field to any value (0 works ok if I also remove the R128_TRACK_GAIN tag, since that tricks foobar2000 into thinking that R128 gain isn't present), add ReplayGain tags relative to the header gain value, and *everything works on all players that I use*. > > The reason for this is kind of a best effort fallback: You asked for > > music to be normalized loudness. If it can't be normalized in the manne= r > > you asked, a fallback would be to estimate a close level - Track gain i= s > > usually within 1-2 dB of album gain on most releases. > >=20 > > If this isn't done, you could (given modern pop mastering) suddenly get > > a track that's 10 dB (add 5 dB if you're using R128 instead of > > ReplayGain) or more louder than everything else, simply because e.g. it > > was a single-track download and you didn't notice that your scanning > > tool didn't add 'album' gain to it. It's to protect your ears and/or > > speakers. >=20 > If you're within 10dB of blowing your speakers, your ears are already los= t. > If you're relying on this to save either of them, then you'd better never > change your player software, and hope nothing or nobody ever changes the > current settings in it without you noticing. >=20 > I'd certainly change my player if it applied track gain when I didn't ask > for track gain to be applied. Alright, I might be exaggerating a bit here, but still... a sudden 10 dB jump in volume from one track to another while listening on headphones can be very surprising and unwelcome. On speakers it's more "annoying your roommates" than "blowing your speakers". --=20 Calvin Walton --=-iC6FbjE7FmVoHxrKUyzi Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINYjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHJjCCBg6g AwIBAgIDBQIzMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwOTI4MTQyMDU5WhcNMTMwOTI5MDIzNTUxWjBnMRkwFwYDVQQNExA2eEJWMWhST2tBdk5ENFBy MSEwHwYDVQQDDBhjYWx2aW4ud2FsdG9uQGtlcHN0aW4uY2ExJzAlBgkqhkiG9w0BCQEWGGNhbHZp bi53YWx0b25Aa2Vwc3Rpbi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTJC+ZQ ME3qUS/IW4RLaiR8YFulvIJ/VEuNwOWMuem/MJEWhwFYaFbfrGuSULThGZSR4bGQxbaRiYZTKvqT ctBviGJ8A/+vBAD0b61uVQi3/mUIN2ZX5SLxmE7K+xGFE5NpCeEoekMFRHcDt7vncfw2hPNYShfT SdajrQo5wTjroGACwnXPTu1TysMNbKFfb393vwFc+llzMBQvWhO2zczyxeca/AG2lPQvB6S+zRfQ W79IvOp/2x2EHy8WnXS9svgffrVrwdcu6IiUIDEP27lOoOkiE+2FX7O8OGqex9QfnOq5mX1HoUm0 ovMop1jmlQF2v2QpFWY7dYmIzihWok0CAwEAAaOCA7MwggOvMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU91SUkj1PegqzagVX F7dCetgrLpwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYY2Fs dmluLndhbHRvbkBrZXBzdGluLmNhMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCC Af8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYB BQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUF BwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNl cnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkg b2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBz ZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ku MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEArES0JRo1fLc3xTkqyKHzgdmfey5QcLD6nOPN qcl3C2hb9ZLynAKKKfLUPZE0jGIeoosTCusniHDfqg9uw/LyFFBOTRODW4SlC4J+mHIumqSTsVDk WzT8lIOQflBSTtKpDQQo13Y7H2BaNd7AEvFafUFtE3w5aPHtiOQjr/O1HEcNGeJ0KCEjHlwUumNb l0PF/dTqms4OlHeTm6ymDwfpyGr44doaenQg92Styx5yY2xq7IR6D/CtHUe+FkzfubTRVTc6KPtk pK6C6mcN8fzki2ZVmPcXysfGc1rwLkEywIHYPlgvIAqdNFimGNzzLTLshBR9X6g0yy6y1klysuZ2 gjGCAhswggIXAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUCMzAJBgUrDgMC GgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTI3MTY1 MzAxWjAjBgkqhkiG9w0BCQQxFgQUe6BtOixSYmtbZkzcZIDwag8kO18wDQYJKoZIhvcNAQEBBQAE ggEAL2Gd3ZaUZRXxApX1QihWLsYi9y4ZKws22toXEoUXuS+PvnhPmP4FChztloOgYxHOVIgd3cwD tTdkQnOqgTrP9h6VDcbok7yvFmvKJsY7wrtC8NtMXS5HwdhQkO4gFRytN++RGX8EWCEjgqj5vw2/ rscEYbMav/heqEaYAAFz3nAnNiMfxoKUdtnlBZIJck1rnrKi7hbwMHNaFMFYYEAAHnyNdHomLiQE j/sSdofQxWdQGZUVePG0x1gQMr7Ftd8kfhI1ioX7SYFjCICuLPEKQYHXwN5qXZaAT6afsU/7MNM4 pQdq5cpopqjJ2A4p7qwKTXQZ75MGQE2rfVhbpardgQAAAAAAAA== --=-iC6FbjE7FmVoHxrKUyzi-- From hoene@uni-tuebingen.de Thu Nov 29 08:41:35 2012 Return-Path: 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 2EF3C21F8A30 for ; Thu, 29 Nov 2012 08:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 8YZtKlWw6Xab for ; Thu, 29 Nov 2012 08:41:33 -0800 (PST) Received: from mx09.uni-tuebingen.de (mx09.uni-tuebingen.de [134.2.3.2]) by ietfa.amsl.com (Postfix) with ESMTP id A554821F8A34 for ; Thu, 29 Nov 2012 08:41:32 -0800 (PST) Received: from ChristianHoene ([50.201.8.0]) (authenticated bits=0) by mx09.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id qATGfHBH005827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Nov 2012 17:41:25 +0100 From: "Hoene" To: "'Young, Milan'" , , References: In-Reply-To: Date: Thu, 29 Nov 2012 08:41:18 -0800 Message-ID: <000601cdce50$6414e950$2c3ebbf0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CDCE0D.55F3F340" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHqNbbno/rnGfAATontRZbX4ZkaIJfH4bJQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx09) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx09); id=24401-wZusVK Subject: Re: [codec] [opus] Opus for ASR - update and questions X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:41:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CDCE0D.55F3F340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Milan Young, =20 thanks for doing the ASR testing. We would be happy to consider your results to be in included in the Opus characterization draft. Please feel free to post them to the Opus IETF mailing list, too. =20 With best regards, =20 Christian Hoene =20 =20 -- Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel +49 7071 2970532, Fax +49 7071 5220 http://kn.inf.uni-tuebingen.de/staff/hoene.html =20 Von: opus-bounces@xiph.org [mailto:opus-bounces@xiph.org] Im Auftrag von Young, Milan Gesendet: Mittwoch, 28. November 2012 12:51 An: opus@xiph.org Betreff: [opus] Opus for ASR - update and questions =20 For the last couple months, Nuance has performed extensive testing on = how the Opus codec performs in the speech recognition task. I=92m hoping to publish a full report in the coming months, but until then all I have is = a teaser. Opus performed within about 1% of the WER (Word Error Rate) of unencoded audio. This is compared to about 5% for Speex, which was the previous codec of choice. Well done to you all! =20 As Nuance considers migrating to Opus, we=92d like to consider the topic = of transport. Traditionally we=92ve relied on TCP for reasons of = reliability. Opus, with its packet redundancy features, offers an attractive = real-time alternative that we will soon be testing. But in order to apply an apples-apples comparison we need to model both data rates and latency in real world scenarios. =20 For UDP, I=92m assuming that the redundancy feature adds no additional latency. Correct? On the data rate question, I see that the Opusenc = tool provides an =93expec-loss=94 parameter with the value expressed as a = percentage. Could someone please describe how this is implemented? Are you simply removing some percentage of packets from the result, or is there a more complex model underpinning the exercise? =20 Modeling TCP data rates and latency in similarly losssy scenarios seems = much more difficult since dropped packets have cascading effects. Has anyone = on this list considered this class of comparison? Any suggestions for = modeling software that could aid my search? =20 Thank you =20 ------=_NextPart_000_0007_01CDCE0D.55F3F340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Milan Young,

 

thanks for = doing the ASR testing.

We would be happy to consider your = results to be in included in the Opus characterization = draft.

Please feel free to post them to the Opus IETF = mailing list, too.

 

With best = regards,

 

Christian = Hoene

 

 

 

Von:<= /b> = opus-bounces@xiph.org [mailto:opus-bounces@xiph.org] Im Auftrag von = Young, Milan
Gesendet: Mittwoch, 28. November 2012 = 12:51
An: opus@xiph.org
Betreff: [opus] Opus for ASR = - update and questions

 

For the last couple months, Nuance has performed extensive = testing on how the Opus codec performs in the speech recognition = task.  I’m hoping to publish a full report in the coming = months, but until then all I have is a teaser.  Opus performed = within about 1% of the WER (Word Error Rate) of unencoded audio.  = This is compared to about 5% for Speex, which was the previous codec of = choice.  Well done to you all!

 

As Nuance considers migrating to = Opus, we’d like to consider the topic of transport.  = Traditionally we’ve relied on TCP for reasons of = reliability.  Opus, with its packet redundancy features, offers an = attractive real-time alternative that we will soon be testing.  But = in order to apply an apples-apples comparison we need to model both data = rates and latency in real world scenarios.

 

For UDP, I’m assuming that = the redundancy feature adds no additional latency.  Correct?  = On the data rate question, I see that the Opusenc tool provides an = “expec-loss” parameter with the value expressed as a = percentage.  Could someone please describe how this is = implemented?  Are you simply removing some percentage of packets = from the result, or is there a more complex model underpinning the = exercise?

 

Modeling TCP data rates and latency in similarly losssy = scenarios seems much more difficult since dropped packets have cascading = effects.  Has anyone on this list considered this class of = comparison?  Any suggestions for modeling software that could aid = my search?

 

Thank you

 

------=_NextPart_000_0007_01CDCE0D.55F3F340--