From nobody Mon Aug  4 11:06:42 2014
Return-Path: <gmaxwell@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9AB1A00A8 for <codec@ietfa.amsl.com>; Mon,  4 Aug 2014 11:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k3Ln0Aykm04 for <codec@ietfa.amsl.com>; Mon,  4 Aug 2014 11:06:38 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9B11A005C for <codec@ietf.org>; Mon,  4 Aug 2014 11:06:38 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so11756849vcb.35 for <codec@ietf.org>; Mon, 04 Aug 2014 11:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=UZhuw2XKM59UrxEItzYczWvLUOfUipgC4WHqcT7eAvM=; b=pG9upjKVM0/bd0JzP4yxy4ikSKEb3jZ4jzX+TWCg1TuOOim7z30cpdwnAHIx3iKbq4 gj+4xZcRSGqwVXunRc/uMLRrTdLNcurOZpE7XXmF7nFU3mcA+AOZiYvnKh4Jh3YtZg02 dDpk/xYmXkejO1rNkyQL4MacZ1ZsEmOxMAlh/9wjxWzNXS4dT6HEl1LTYrDH+SisuPfk Ow176XSWWmTqNjhyIFbPm6T19qw1NMi0qpwizMH8JCW+m35DF9B0rJKQr7i/oTzeB5bZ +PDYaBSggmF9VJeDRie0a371gYwv09ZwSo+fFvdps3Kt/r/gHvok1ZtjexgVm/Tvi3Zc roJg==
MIME-Version: 1.0
X-Received: by 10.221.44.69 with SMTP id uf5mr25559427vcb.4.1407175595162; Mon, 04 Aug 2014 11:06:35 -0700 (PDT)
Sender: gmaxwell@gmail.com
Received: by 10.52.187.132 with HTTP; Mon, 4 Aug 2014 11:06:35 -0700 (PDT)
Date: Mon, 4 Aug 2014 11:06:35 -0700
X-Google-Sender-Auth: L4N8cWdsDTDwuwPMMr5Gc80Msy8
Message-ID: <CAAS2fgSL+LGVSUDN=hJ9Jxeu1u7_jrfs1E_b7U5b9Y2bF67CaA@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: codec@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/uTvxjFaYCPS0mbU4LybTAC92tzE
Subject: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:06:41 -0000

There have been a comments from a number of implementers that their
applications would like to know if "album" gain adjustment had been
performed on a track. An album gain is a feature the replaygain
tagging has which allowed the dynamics within a collection of tracks
to be preserved while still normalizing the collection overall.

Right now, the draft just recommends the encoder store it in the
header gain field=E2=80=94 which works okay but doesn't allow a player to k=
now
for sure which gain is being applied.

To clear this up I'm proposing we add a R128_ALBUM_GAIN which works
just like R128_TRACK_GAIN and which can be set to zero when the header
gain matches the album gain.

Here is a diff against the current draft:

diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopu=
s.xml
index cb1f739..9364361 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -1155,7 +1155,7 @@ The user comment strings follow the NAME=3Dvalue
format described by
  <xref target=3D"vorbis-comment"/> with the same recommended tag names.
 </t>
 <figure align=3D"center">
-  <preamble>One new comment tag is introduced for Ogg Opus:</preamble>
+  <preamble>Two new comment tags are introduced for Ogg Opus:</preamble>
 <artwork align=3D"left"><![CDATA[
 R128_TRACK_GAIN=3D-573
 ]]></artwork>
@@ -1170,32 +1170,38 @@ This tag is similar to the REPLAYGAIN_TRACK_GAIN ta=
g in
  Vorbis&nbsp;<xref target=3D"replay-gain"/>, except that the normal volume
  reference is the <xref target=3D"EBU-R128"/> standard.
 </t>
+<artwork align=3D"left"><![CDATA[
+R128_ALBUM_GAIN=3D111
+]]></artwork>
+<postamble>
+representing the volume shift needed to normalize the volume of a collecti=
on
+ of tracks.
+The gain is a Q7.8 fixed point number in dB, as in the ID header's 'output
+ gain' field.
+</postamble>
+</figure>
 <t>
-An Ogg Opus file MUST NOT have more than one such tag, and if present its
- value MUST be an integer from -32768 to 32767, inclusive, represented in
+An Ogg Opus file MUST NOT have more than one of each tags, and if present
+ their values MUST be an integer from -32768 to 32767, inclusive,
represented in
  ASCII with no whitespace.
-If present, it MUST correctly represent the R128 normalization gain relati=
ve
- to the 'output gain' field specified in the ID header.
-If a player chooses to make use of the R128_TRACK_GAIN tag, it MUST be
- applied <spanx style=3D"emph">in addition</spanx> to the 'output gain' va=
lue.
+If present, REPLAYGAIN_TRACK_GAIN MUST correctly represent the R128
+ normalization gain relative to the 'output gain' field specified in
the ID header.
+If a player chooses to make use of the R128_TRACK_GAIN tag or the
+ R128_ALBUM_GAIN, it MUST be applied <spanx style=3D"emph">in addition</sp=
anx> to
[gmaxwell@helmholtz doc]$ git diff | cat
diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopu=
s.xml
index cb1f739..9364361 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -1155,7 +1155,7 @@ The user comment strings follow the NAME=3Dvalue
format described by
  <xref target=3D"vorbis-comment"/> with the same recommended tag names.
 </t>
 <figure align=3D"center">
-  <preamble>One new comment tag is introduced for Ogg Opus:</preamble>
+  <preamble>Two new comment tags are introduced for Ogg Opus:</preamble>
 <artwork align=3D"left"><![CDATA[
 R128_TRACK_GAIN=3D-573
 ]]></artwork>
@@ -1170,32 +1170,38 @@ This tag is similar to the REPLAYGAIN_TRACK_GAIN ta=
g in
  Vorbis&nbsp;<xref target=3D"replay-gain"/>, except that the normal volume
  reference is the <xref target=3D"EBU-R128"/> standard.
 </t>
+<artwork align=3D"left"><![CDATA[
+R128_ALBUM_GAIN=3D111
+]]></artwork>
+<postamble>
+representing the volume shift needed to normalize the volume of a collecti=
on
+ of tracks.
+The gain is a Q7.8 fixed point number in dB, as in the ID header's 'output
+ gain' field.
+</postamble>
+</figure>
 <t>
-An Ogg Opus file MUST NOT have more than one such tag, and if present its
- value MUST be an integer from -32768 to 32767, inclusive, represented in
+An Ogg Opus file MUST NOT have more than one of each tags, and if present
+ their values MUST be an integer from -32768 to 32767, inclusive,
represented in
  ASCII with no whitespace.
-If present, it MUST correctly represent the R128 normalization gain relati=
ve
- to the 'output gain' field specified in the ID header.
-If a player chooses to make use of the R128_TRACK_GAIN tag, it MUST be
- applied <spanx style=3D"emph">in addition</spanx> to the 'output gain' va=
lue.
+If present, REPLAYGAIN_TRACK_GAIN MUST correctly represent the R128
+ normalization gain relative to the 'output gain' field specified in
the ID header.
+If a player chooses to make use of the R128_TRACK_GAIN tag or the
+ R128_ALBUM_GAIN, it MUST be applied <spanx style=3D"emph">in addition</sp=
anx> to
+ the 'output gain' value.
 If an encoder wishes to use R128 normalization, and the output gain is not
  otherwise constrained or specified, the encoder SHOULD write the R128 gai=
n
  into the 'output gain' field and store a tag containing "R128_TRACK_GAIN=
=3D0".
 That is, it should assume that by default tools will respect the 'output g=
ain'
  field, and not the comment tag.
 If a tool modifies the ID header's 'output gain' field, it MUST also updat=
e or
- remove the R128_TRACK_GAIN comment tag.
+ remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags.
 </t>
 <t>
 To avoid confusion with multiple normalization schemes, an Opus comment he=
ader
  SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEA=
K,
  REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags.
 </t>
-<t>
-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.
-</t>
 </section>

 </section>


From nobody Mon Aug  4 11:41:09 2014
Return-Path: <calvin.walton@kepstin.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB201A00FC for <codec@ietfa.amsl.com>; Mon,  4 Aug 2014 11:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QstNHguuCmzI for <codec@ietfa.amsl.com>; Mon,  4 Aug 2014 11:41:01 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B7F1A0110 for <codec@ietf.org>; Mon,  4 Aug 2014 11:40:04 -0700 (PDT)
Received: by mail-ig0-f171.google.com with SMTP id l13so5822414iga.10 for <codec@ietf.org>; Mon, 04 Aug 2014 11:40:04 -0700 (PDT)
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:mime-version:content-transfer-encoding; bh=ytkgxBxd0B3NrGT7GWjuDrG1N4KciiuxTg3wASK3IUk=; b=YajLcOpTFeUyKvqrB/cKXVmKJ+plq/bIWmK+iR9Rj6V4NrKWdXfBoTCrJ24UjJBDWG PlyTbn8qrlLgYGnVI41OBkG/vGejmLNIbDemNcSyDnM42+kS64ZwNRCfarnk0uilXShF zxBnYKuk9ttRJobJIlY4F4smpRu53QTiw2yCU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; bh=ytkgxBxd0B3NrGT7GWjuDrG1N4KciiuxTg3wASK3IUk=; b=KLT1kKnzqwzCVMZsTukd43Br2SBng9d3EBohFxoZ1NfBI8n6av5VFaD0ZlJI2aoPmz gM/pLQbu5WCNdUjGJUQPJOg7Y8FBWORoAw+TEK7glaV1SZY7ZPWRzjFsVtI4UIZS1hRX TlmavXcr+b01URU+I2xq69zBygpo34nRK/lilhYMkYpwf9uNTwBQiei8UKOKLQ15yRiW 4VlGppLKHowashTIAa2NRMT0mlxS4hfwcjPgE8FIJgul1TAg62MYFaL9mkdVJtdj/Bfk 5NWXYj2HS+YunPpOg+e5BLyUKpGzjPtr2PHRj8GnCynHlv3BlCo2UTw/xB4Aeb8hOvhj RMyg==
X-Gm-Message-State: ALoCoQkJoY30gWSHhFKqIpxnvEW85KW+JXamLvgDxlgkhp9NUEjeZmVPnnvAHFRV++79PDlv4NYZ
X-Received: by 10.50.142.97 with SMTP id rv1mr40513995igb.13.1407177603888; Mon, 04 Aug 2014 11:40:03 -0700 (PDT)
Received: from [10.210.0.33] ([12.160.0.155]) by mx.google.com with ESMTPSA id y14sm10638223igg.0.2014.08.04.11.40.03 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Aug 2014 11:40:03 -0700 (PDT)
Message-ID: <1407177600.963.1.camel@kepstin.ca>
From: Calvin Walton <calvin.walton@kepstin.ca>
To: Gregory Maxwell <greg@xiph.org>
Date: Mon, 04 Aug 2014 13:40:00 -0500
In-Reply-To: <CAAS2fgSL+LGVSUDN=hJ9Jxeu1u7_jrfs1E_b7U5b9Y2bF67CaA@mail.gmail.com>
References: <CAAS2fgSL+LGVSUDN=hJ9Jxeu1u7_jrfs1E_b7U5b9Y2bF67CaA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.4 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/wY9FWYuOrt9BfVX6cY7rM63ydto
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:41:06 -0000

Hi, I noticed a typo in the diff; see the inline note below.

Note that I'm still of the opinion that there should not be any language
in the spec that explicitly disallows use of the REPLAYGAIN_*_GAIN tags
as implemented in Vorbis; the use of these tags in Ogg Opus is already
interoperable with many applications including Rockbox, GStreamer-based
players like Rhythmbox, and foobar2000 (when added manually via an
external tool).

Perhaps there should be something that states that if both R128_*_GAIN
and REPLAYGAIN_*_GAIN tags are present, the application should use
either one set or the other, but not attempt to apply both.

On Thu, 1970-01-01 at 00:00 +0000, Gregory Maxwell wrote:
> There have been a comments from a number of implementers that their
> applications would like to know if "album" gain adjustment had been
> performed on a track. An album gain is a feature the replaygain
> tagging has which allowed the dynamics within a collection of tracks
> to be preserved while still normalizing the collection overall.
> 
> Right now, the draft just recommends the encoder store it in the
> header gain field— which works okay but doesn't allow a player to know
> for sure which gain is being applied.
> 
> To clear this up I'm proposing we add a R128_ALBUM_GAIN which works
> just like R128_TRACK_GAIN and which can be set to zero when the header
> gain matches the album gain.
> 
> Here is a diff against the current draft:

[...]

> -An Ogg Opus file MUST NOT have more than one such tag, and if present its
> - value MUST be an integer from -32768 to 32767, inclusive, represented in
> +An Ogg Opus file MUST NOT have more than one of each tags, and if present
> + their values MUST be an integer from -32768 to 32767, inclusive,
> represented in
>   ASCII with no whitespace.
> -If present, it MUST correctly represent the R128 normalization gain relative
> - to the 'output gain' field specified in the ID header.
> -If a player chooses to make use of the R128_TRACK_GAIN tag, it MUST be
> - applied <spanx style="emph">in addition</spanx> to the 'output gain' value.
> +If present, REPLAYGAIN_TRACK_GAIN MUST correctly represent the R128

This should be "R128_TRACK_GAIN"

> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec

-- 
Calvin Walton <calvin.walton@kepstin.ca>


From nobody Fri Aug  8 14:37:46 2014
Return-Path: <giles@thaumas.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99371A0348 for <codec@ietfa.amsl.com>; Fri,  8 Aug 2014 14:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2op-FY92kcJH for <codec@ietfa.amsl.com>; Fri,  8 Aug 2014 14:37:39 -0700 (PDT)
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C131A00E2 for <codec@ietf.org>; Fri,  8 Aug 2014 14:37:38 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id rp18so6846912iec.26 for <codec@ietf.org>; Fri, 08 Aug 2014 14:37:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k1Aapzx46v7Ikqviy0gtUU0TwVQh5+smX3DMwstY44w=; b=e8hpY9HvpaMWX+/72oRJdG30NiE8v135yfaoU2/kAsFuw78SoYo4vcaLVQPx/9bkTh Jluryo/zhMToXgZQVJ4HBTKeMsbd3oivcYsKdcddrZJYQXqFdRiZTuG2FqSerqV97d7y jZEPUfsA6jjMHghuTKNH37JO9OGwEVv0q0N+DzlHEoJhVRu44UuNtp2bZ+o41IGKw2B8 Z+3KCwd17aZQkM/P68CVnek7Uage7UpejWOtFH653LRtVAk5mGBAzAanp59M3DtQLotU 4Gg+we+ciXGmviOUy3xk54Caju3BBfa1/JD0N4e6KiYHtFs4iBLphTFkiMeqk4eISsXB x15w==
X-Gm-Message-State: ALoCoQlgC17WCLYxGV0ZMxKzWR6vWZgDIr4zbG32x6MxeXEtuRDCOIE3Gu6p+xxU2uyMB5c9lgpM
X-Received: by 10.50.118.4 with SMTP id ki4mr9229962igb.16.1407533856999; Fri, 08 Aug 2014 14:37:36 -0700 (PDT)
Received: from tamias.local (S0106185933484486.vc.shawcable.net. [174.6.214.147]) by mx.google.com with ESMTPSA id o11sm13631890igi.5.2014.08.08.14.37.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 14:37:36 -0700 (PDT)
Message-ID: <53E542D4.5090909@thaumas.net>
Date: Fri, 08 Aug 2014 14:36:20 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: codec@ietf.org
References: <CAAS2fgSL+LGVSUDN=hJ9Jxeu1u7_jrfs1E_b7U5b9Y2bF67CaA@mail.gmail.com>
In-Reply-To: <CAAS2fgSL+LGVSUDN=hJ9Jxeu1u7_jrfs1E_b7U5b9Y2bF67CaA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/77MVUYnKDNArcZfXt3OZFzN6UCs
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 21:37:44 -0000

On 2014-08-04 11:06 AM, Gregory Maxwell wrote:

> To clear this up I'm proposing we add a R128_ALBUM_GAIN which works
> just like R128_TRACK_GAIN and which can be set to zero when the header
> gain matches the album gain.

Thanks for the patch. I agree, this is a useful response to the feedback
we've received. Applied with fixes.

 -r


From nobody Fri Aug  8 23:33:28 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608C81A0B06; Fri,  8 Aug 2014 23:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve1KR_bhVQ6k; Fri,  8 Aug 2014 23:33:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C751A0AF3; Fri,  8 Aug 2014 23:33:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140809063323.22350.19657.idtracker@ietfa.amsl.com>
Date: Fri, 08 Aug 2014 23:33:23 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/dLCAfOdhxrqMvXtbj6RAxNX9fGQ
Cc: codec@ietf.org
Subject: [codec] I-D Action: draft-ietf-codec-oggopus-04.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Aug 2014 06:33:25 -0000

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           : Ogg Encapsulation for the Opus Audio Codec
        Authors         : Timothy B. Terriberry
                          Ron Lee
                          Ralph Giles
	Filename        : draft-ietf-codec-oggopus-04.txt
	Pages           : 30
	Date            : 2014-08-08

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-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-codec-oggopus-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Aug 12 07:31:09 2014
Return-Path: <jdrosen@jdrosen.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E30B1A08DE for <codec@ietfa.amsl.com>; Tue, 12 Aug 2014 07:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.422
X-Spam-Level: *
X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXWq0xBMDAfr for <codec@ietfa.amsl.com>; Tue, 12 Aug 2014 07:31:03 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21EA1A001C for <codec@ietf.org>; Tue, 12 Aug 2014 07:31:03 -0700 (PDT)
Received: from mail-pd0-f173.google.com ([209.85.192.173]:61878) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from <jdrosen@jdrosen.net>) id 1XHD6I-0003QF-Kw for codec@ietf.org; Tue, 12 Aug 2014 10:31:02 -0400
Received: by mail-pd0-f173.google.com with SMTP id w10so12650863pde.4 for <codec@ietf.org>; Tue, 12 Aug 2014 07:30:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.89.34 with SMTP id bl2mr4672380pbb.105.1407853858375; Tue, 12 Aug 2014 07:30:58 -0700 (PDT)
Received: by 10.70.87.195 with HTTP; Tue, 12 Aug 2014 07:30:58 -0700 (PDT)
Date: Tue, 12 Aug 2014 07:30:58 -0700
Message-ID: <CA+23+fFubuuvwHY1g-92QSrsqAENE+BQUX6XbRZ9d9TfG4qCiw@mail.gmail.com>
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
To: codec@ietf.org
Content-Type: multipart/alternative; boundary=047d7b66f1eb1fd3c705006f85f5
X-OutGoing-Spam-Status: No, score=-2.9
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-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/nlUluJKu5t_fNSr9QkKps_VyW8Y
Subject: [codec] Two week WGLC for draft-ietf-codec-oggopus
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 14:31:07 -0000

--047d7b66f1eb1fd3c705006f85f5
Content-Type: text/plain; charset=UTF-8

I'd like to initiate a two week WGLC for:
http://tools.ietf.org/html/draft-ietf-codec-oggopus-04

Thanks,
Jonathan R.

-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--047d7b66f1eb1fd3c705006f85f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to initiate a two week WGLC for:<div><a href=
=3D"http://tools.ietf.org/html/draft-ietf-codec-oggopus-04">http://tools.ie=
tf.org/html/draft-ietf-codec-oggopus-04</a></div><div><br></div><div>Thanks=
,</div>
<div>Jonathan R.<br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr">Jo=
nathan Rosenberg, Ph.D.<br><a href=3D"mailto:jdrosen@jdrosen.net" target=3D=
"_blank">jdrosen@jdrosen.net</a><br><a href=3D"http://www.jdrosen.net" targ=
et=3D"_blank">http://www.jdrosen.net</a></div>

</div></div>

--047d7b66f1eb1fd3c705006f85f5--


From flac@nartowicz.co.uk  Wed Aug 13 14:22:09 2014
Return-Path: <flac@nartowicz.co.uk>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A61A1A0058 for <codec@ietfa.amsl.com>; Wed, 13 Aug 2014 14:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwuZcYC1bOS8 for <codec@ietfa.amsl.com>; Wed, 13 Aug 2014 14:22:05 -0700 (PDT)
Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) by ietfa.amsl.com (Postfix) with ESMTP id D91721A0049 for <codec@ietf.org>; Wed, 13 Aug 2014 14:22:04 -0700 (PDT)
Received: from crunchbang ([81.103.170.84]) by know-smtprelay-5-imp with bizsmtp id eMN21o02u1pcAUZ01MN2Ed; Wed, 13 Aug 2014 22:22:03 +0100
X-Originating-IP: [81.103.170.84]
X-Spam: 0
X-Authority: v=2.1 cv=JIm1sq6b c=1 sm=1 tr=0 a=bYNBYWS+Sj0o/bRbN9Xjqw==:117 a=bYNBYWS+Sj0o/bRbN9Xjqw==:17 a=KEKbkQfv9EEA:10 a=ud0LK1MCnV8A:10 a=RoPK8JaNmp0A:10 a=kj9zAlcOel0A:10 a=hU221NPEAAAA:8 a=oJQSLd2CPyHzMiiBLcMA:9 a=ud5QLtxWJEuS_oWs:21 a=NzeGKWN5YTOL0YCe:21 a=CjuIK1q_8ugA:10
Date: Wed, 13 Aug 2014 22:22:01 +0100
From: Ian Nartowicz <flac@nartowicz.co.uk>
To: codec@ietf.org
Message-ID: <20140813222201.54fe7910@crunchbang>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; i486-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/5uXLtxKjqnOUqo_6jZRznD2o4wg
X-Mailman-Approved-At: Thu, 14 Aug 2014 09:56:10 -0700
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 21:24:47 -0000

After much discussion on IRC, we've come up with some further clarifications to
the use of the output gain field and R128 tags.

In section 5.1:
        Virtually all players and media frameworks should apply it by
-       default.  If a player chooses to apply any volume adjustment or
-       gain modification, such as the R128_TRACK_GAIN, R128_ALBUM_GAIN
-       (see Section 5.2) or a user-facing volume knob, the adjustment
-       MUST be applied in addition to this output gain in order to
-       achieve playback at the desired volume.
+       default.  If a player chooses to apply any gain modification,
+       such as the R128_TRACK_GAIN or R128_ALBUM_GAIN (see Section 5.2),
+       the adjustment MUST be applied in addition to this output
+       gain in order to achieve playback at the normalised volume.


In section 5.2.1:
-   If an encoder wishes to use R128 normalization, and the output gain
-   is not otherwise constrained or specified, the encoder SHOULD write
-   the R128 gain into the 'output gain' field and store a tag containing
-   "R128_TRACK_GAIN=0".  That is, it should assume that by default tools
+   The encoder should assume that by default tools
    will respect the 'output gain' field, and not the comment tag.  If a
    tool modifies the ID header's 'output gain' field, it MUST also
    update or remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags

--ian


From nobody Thu Aug 14 10:24:55 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763961A6F82 for <codec@ietfa.amsl.com>; Thu, 14 Aug 2014 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZKigNTqCVJk for <codec@ietfa.amsl.com>; Thu, 14 Aug 2014 10:24:50 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9371A02CF for <codec@ietf.org>; Thu, 14 Aug 2014 10:24:50 -0700 (PDT)
Received: from [172.17.0.43] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 87A99F251D for <codec@ietf.org>; Thu, 14 Aug 2014 10:24:49 -0700 (PDT)
Message-ID: <53ECF0E0.9060308@xiph.org>
Date: Thu, 14 Aug 2014 10:24:48 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: codec@ietf.org
References: <20140813222201.54fe7910@crunchbang>
In-Reply-To: <20140813222201.54fe7910@crunchbang>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/bZO4Q7ElYrxVCtrm45GuAGMSpA4
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 17:24:52 -0000

To capture the reasoning behind these changes...

Ian Nartowicz wrote:
> In section 5.1:
>          Virtually all players and media frameworks should apply it by
> -       default.  If a player chooses to apply any volume adjustment or
> -       gain modification, such as the R128_TRACK_GAIN, R128_ALBUM_GAIN
> -       (see Section 5.2) or a user-facing volume knob, the adjustment
> -       MUST be applied in addition to this output gain in order to
> -       achieve playback at the desired volume.
> +       default.  If a player chooses to apply any gain modification,
> +       such as the R128_TRACK_GAIN or R128_ALBUM_GAIN (see Section 5.2),
> +       the adjustment MUST be applied in addition to this output
> +       gain in order to achieve playback at the normalised volume.

Ian felt that including the volume knob example made this text unclear. 
The new text makes it explicit that 'output gain' + R128_TACK_GAIN or 
'output gain' + R128_ALBUM_GAIN gives you _normalized_ volume (as 
defined by EBU R128), which may or may not have any relation to "desired 
volume". I don't think we need to be in the business of telling players 
how to implement a volume knob, so taking the example out seemed best.

> In section 5.2.1:
> -   If an encoder wishes to use R128 normalization, and the output gain
> -   is not otherwise constrained or specified, the encoder SHOULD write
> -   the R128 gain into the 'output gain' field and store a tag containing
> -   "R128_TRACK_GAIN=0".  That is, it should assume that by default tools
> +   The encoder should assume that by default tools
>      will respect the 'output gain' field, and not the comment tag.  If a
>      tool modifies the ID header's 'output gain' field, it MUST also
>      update or remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags

This was causing confusion because it suggested that an encoder should 
_always_ prefer to put the track gain into the 'output gain' field. In 
reality we used to have text saying that using the album gain for 
'output gain' was preferred, and this was just an alternative (the 
leading "If" clause being the the important part of the sentence, not 
the SHOULD). However, this sentence is entirely redundant with the text 
from the definition of the 'output gain' field: "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." Removing 
the sentence avoids the confusion.

I've applied both sets of changes locally (using "An encoder" instead of 
"The encoder"), and they'll be included in the next update (after WGLC).

I also moved the "assume by default" sentence to the end of the 
paragraph and removed the preceding paragraph break, as the warning 
about being required to update the tags when the header value changes 
now logically follows from the declaration that these tags are relative 
to that field.


From nobody Fri Aug 15 21:01:50 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630421A0714 for <codec@ietfa.amsl.com>; Fri, 15 Aug 2014 21:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAQOYOjh1ym0 for <codec@ietfa.amsl.com>; Fri, 15 Aug 2014 21:01:45 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12C1A6F1B for <codec@ietf.org>; Fri, 15 Aug 2014 21:01:45 -0700 (PDT)
Received: from ppp14-2-60-85.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.60.85]) by ipmail05.adl6.internode.on.net with ESMTP; 16 Aug 2014 13:31:44 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 36F15FFF50 for <codec@ietf.org>; Sat, 16 Aug 2014 13:31:41 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2eG68Rc8geJq for <codec@ietf.org>; Sat, 16 Aug 2014 13:31:40 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 79AB0FFD70 for <codec@ietf.org>; Sat, 16 Aug 2014 13:31:40 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 6810380470; Sat, 16 Aug 2014 13:31:40 +0930 (CST)
Date: Sat, 16 Aug 2014 13:31:40 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140816040140.GA31682@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53ECF0E0.9060308@xiph.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/Tr5onUzbKd8ojMrIkhMFyYrhCaU
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 04:01:48 -0000

On Thu, Aug 14, 2014 at 10:24:48AM -0700, Timothy B. Terriberry wrote:
> >In section 5.2.1:
> >-   If an encoder wishes to use R128 normalization, and the output gain
> >-   is not otherwise constrained or specified, the encoder SHOULD write
> >-   the R128 gain into the 'output gain' field and store a tag containing
> >-   "R128_TRACK_GAIN=0".  That is, it should assume that by default tools
> >+   The encoder should assume that by default tools
> >     will respect the 'output gain' field, and not the comment tag.  If a
> >     tool modifies the ID header's 'output gain' field, it MUST also
> >     update or remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags
> 
> This was causing confusion because it suggested that an encoder should
> _always_ prefer to put the track gain into the 'output gain' field. In
> reality we used to have text saying that using the album gain for 'output
> gain' was preferred, and this was just an alternative (the leading "If"
> clause being the the important part of the sentence, not the SHOULD).
> However, this sentence is entirely redundant with the text from the
> definition of the 'output gain' field: "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." Removing the sentence avoids
> the confusion.
> 
> I've applied both sets of changes locally (using "An encoder" instead of
> "The encoder"), and they'll be included in the next update (after WGLC).
> 
> I also moved the "assume by default" sentence to the end of the paragraph
> and removed the preceding paragraph break, as the warning about being
> required to update the tags when the header value changes now logically
> follows from the declaration that these tags are relative to that field.

So the patch applied for this part is now:

> - If an encoder wishes to use R128 normalization, and the output gain is not
> - otherwise constrained or specified, the encoder SHOULD write the R128 gain
> - into the 'output gain' field and store a tag containing "R128_TRACK_GAIN=0".
> - That is, it should assume that by default tools will respect the 'output gain'
> - field, and not the comment tag.
>   If a tool modifies the ID header's 'output gain' field, it MUST also update or
>   remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present.
> + An encoder should assume that by default tools will respect the 'output gain'
> + field, and not the comment tag.

And I wonder two things about it:

Is that intended to be "An encoder SHOULD assume"?

And if we do want this to be normative, do we need to expand a little on
what 'tools' and 'respect' means there - since that's possibly now less
clear as a statement which stands on its own, rather than a(n intended)
clarification to the text that is being removed.

I agree with the rationale of what's intended by this change, but I'm
less sure if it's now clear to a first time reader whether 'tools'
includes both players and editors, and under what conditions the
assumptions about 'default behaviour' will apply (since if we have the
comment tags, obviously *something* might respect them sometimes).

If we're going to give (normative) guidance there, it possibly wants
to be a little more specific about what exactly it applies to.

  Ron



From nobody Mon Aug 25 00:01:55 2014
Return-Path: <markh.sj@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34361A8AAB for <codec@ietfa.amsl.com>; Mon, 25 Aug 2014 00:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIN5FqYR4qtN for <codec@ietfa.amsl.com>; Mon, 25 Aug 2014 00:01:50 -0700 (PDT)
Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com [IPv6:2607:f8b0:4001:c05::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F21E1A8AAC for <codec@ietf.org>; Mon, 25 Aug 2014 00:01:50 -0700 (PDT)
Received: by mail-ig0-f193.google.com with SMTP id h18so772129igc.4 for <codec@ietf.org>; Mon, 25 Aug 2014 00:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=Mm5JCkMS3mUi8susLfAs9FRnAdSVOzIA4XmZNwjBHqI=; b=gLkSGJFXGthjAmUFmc9K65FfrasPfiROVvvnPUxd7UMdeKPQ7iCp3ohqC7HDPpcZqQ nCblADCfLEcTwCHOVpFIte/Scdx3TP3QBlwqFsjZ63nbl0h55GjUrxWxowzfq938MgW+ uH365g8/E8aEIJLxjJs3sDChSHBlGTS95pnR8LjyGXgaWjaCJh7wVCNIKnb2foRHDQd4 N+HON7v+srJys+uJfUtKRYBwMbaoJRlBTzuwpGZifpvVvxqm9vZNxZAuOk6t5kX55iaT i5zLM4hpSiAG3uvkn1wuaceFVrO0SjYfDT4yqMfqG1z5988y5w6QfJxpd/5YGQ+JiCmw Yg5w==
MIME-Version: 1.0
X-Received: by 10.42.23.16 with SMTP id q16mr23124959icb.0.1408950109638; Mon, 25 Aug 2014 00:01:49 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Mon, 25 Aug 2014 00:01:49 -0700 (PDT)
Date: Mon, 25 Aug 2014 00:01:49 -0700
X-Google-Sender-Auth: 8sg_PrTydO5bHNhv-178gYC2LtA
Message-ID: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: "codec@ietf.org" <codec@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/kZPMv0HQQDfnPyfoRgtPQfAZ8Yk
Subject: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 07:01:54 -0000

Opus does a fantastic job at its primary goal of compressing audio,
including speech, offering a lower bitrate and latency than other
similar codecs.  This makes it an obvious choice for use in RTP and
many other uses.  However when it comes to storing music, podcasts,
and audiobooks in a file, there are additional requirements beyond
just a great codec, such as good support for attached pictures and
other metadata.

Attached pictures (also known as album art or cover art) are images
(usually in JPEG or PNG format) that are related to the audio, and are
often shown by players while the audio is playing or to help the user
choose the file to be played.  In most audio formats pictures can be
categorized into a number of picture types, with multiple pictures
allowed for most types.

Container formats like Matroska have their own format for storing
attached pictures and other metadata in the container, however Ogg
does not provide this and requires any such data to be encoded within
the packets of a media stream.

Attached pictures are not mentioned at all in the current Ogg Opus
draft (draft-ietf-codec-oggopus-04), which simply defers to the
vorbis-comment specification for the format of metadata, with a few
specific differences such as new gain tags.

When Ogg Vorbis was originally specified, it provided a way of storing
a list of text comment tags for things like the title, artist,
license, and copyright of the work, but no way to attach pictures or
binary data.  Because other formats allow attached pictures and users
wanted to add them to Ogg Vorbis files as well, a method of encoding
pictures in a text comment tag using base64 encoding was devised,
which is documented at https://wiki.xiph.org/VorbisComment#Cover_art .
This allowed pictures to be attached to Ogg Vorbis files without
impacting compatibility, but the downside is that attaching pictures
to an Ogg Vorbis file adds about 134% of the picture size to the size
of the file, compared to just over 100% of the picture size for
competing formats including MP3/ID3, iTunes/Quicktime MPEG-4, FLAC,
and Matroska-based formats.  Also, because comments are always at the
beginning of the file and can appear in any order, it is not easy to
skip the pictures and get to the audio if there are multiple large
pictures, at least when there are some other comments that may be of
interest.

Unfortunately the current Ogg Opus draft has the same issue and has no
way of attaching pictures as binary data, thus requiring the use of
the same base64-encoded comment workaround that was used for Ogg
Vorbis.  This is unbefitting of a compressed file format, which has a
primary purpose of reducing file size, and it would be unfortunate if
Ogg Opus was standardized with the same, easily-addressed limitation.
It is difficult to take a purportedly compressed file format seriously
when the first 400 KB or so of the file is a long base64 string of
text that takes significantly more space than the corresponding data
that was provided to the encoder.

I see a few different ways that this could be addressed:

 (1) Specify that comments may contain either UTF-8 or binary data,
according to some rule.  For example, if the name of the tag begins
with "@" then its value is binary data and not intended to be
displayed as text, and is otherwise UTF-8.  There is no technical
issue with storing binary data since each comment is already preceded
by a length field, but a tag name beginning with "@" would be a signal
to applications that the value should not be assumed to be UTF-8 or
displayed as text.  Pictures could then be attached using a newly
defined tag such as "@PICTURE", with a value that is the same as the
binary format used in FLAC (and the same as Ogg Vorbis before base64
encoding).

     Alternatively, ordinary tag names could be used and the value
itself could be used to indicate that it is non-UTF-8 binary data, for
example by including a null character prefix before the binary data,
or a 0xff byte prefix (which is not valid UTF-8), or a null byte
delimiter in place of "=".  However using distinct tag names seems
cleaner.

 (2) Immediately following the comments, in the same packet, allow a
picture count followed by a length and binary data for each picture,
similar to the way that comments are stored but separated from them.
Separating pictures from comments allows a more appropriate format to
be used to encode them, makes it less likely that tools will treat the
data as text, and also makes it easier to skip all attached pictures
entirely when they are not needed.  Tools based on older versions of
the draft would see anything after the original comment section as
comment padding and ignore any attached pictures.  The content of each
picture would be the same as it is for FLAC, and the same as Ogg
Vorbis without the added base64 encoding or "METADATA_BLOCK_PICTURE="
prefix.

 (3) Specify a way to store attached pictures in the file outside of
the Opus stream.  This is the way that containers such as Quicktime
and Matroska work, but to do that with Ogg would require another
stream that contains the pictures, since the Ogg container itself does
not provide metadata.

 (4) Do not address this.  Attached pictures must be base64-encoded
and written in a comment.  If users complain, recommend use of
Matroska or another container that does not have this issue.

Any thoughts on these or other ideas?

I have created a proof-of-concept implementation of (1) and (2) based
on opus-tools, at:
https://github.com/mark4o/opus-tools/tree/binary_comment (1),
https://github.com/mark4o/opus-tools/tree/pic_section (2).

 - Mark


From nobody Mon Aug 25 15:46:10 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19231A042D for <codec@ietfa.amsl.com>; Mon, 25 Aug 2014 15:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.577
X-Spam-Level: 
X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs3iMJ1C0SwX for <codec@ietfa.amsl.com>; Mon, 25 Aug 2014 15:46:03 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9301A040F for <codec@ietf.org>; Mon, 25 Aug 2014 15:45:54 -0700 (PDT)
Received: from [10.252.28.253] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1701FF24A1; Mon, 25 Aug 2014 15:45:54 -0700 (PDT)
Message-ID: <53FBBCA1.8060708@xiph.org>
Date: Mon, 25 Aug 2014 15:45:53 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: Mark Harris <mark.hsj@gmail.com>, "codec@ietf.org" <codec@ietf.org>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com>
In-Reply-To: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/BI4y-4BH1Y5uPTFYnA5f7DJqDh4
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 22:46:06 -0000

With my individual hat on...

Mark Harris wrote:
> Attached pictures are not mentioned at all in the current Ogg Opus
> draft (draft-ietf-codec-oggopus-04), which simply defers to the
> vorbis-comment specification for the format of metadata, with a few
> specific differences such as new gain tags.

The theory was that it wasn't necessary to re-invent the wheel here. 
Applications which already support Vorbis-style album art can add 
support for Opus album art with as little as one line of code (because 
they can, and do, share comment-parsing routines among 
Vorbis/Theora/Speex/etc.). This is not just a matter of engineering 
simplicity, but also speed of adoption.

>   (1) Specify that comments may contain either UTF-8 or binary data,
> according to some rule.  For example, if the name of the tag begins
> with "@" then its value is binary data and not intended to be
> displayed as text, and is otherwise UTF-8.  There is no technical

This has backwards-compatibility problems. Is this unique to Opus or 
would we expect other formats to adopt the same strategy? (see above 
about code-reuse). What would we do about existing tags that might 
already start with an '@'? How would we represent a field name that we 
want to start with an '@' (for whatever reason)?

We could also simply use a more compact form of embedding binary data in 
UTF-8, but those have higher implementation complexity (and two 
encodings to choose from is higher still).

>       Alternatively, ordinary tag names could be used and the value
> itself could be used to indicate that it is non-UTF-8 binary data, for
> example by including a null character prefix before the binary data,
> or a 0xff byte prefix (which is not valid UTF-8), or a null byte
> delimiter in place of "=".  However using distinct tag names seems
> cleaner.

Existing, naive tools are likely to mis-handle all of those things 
(e.g., copying the tag as the empty string, rejecting it as invalid and 
removing it, rejecting the whole comment packet as invalid, etc.).

>   (2) Immediately following the comments, in the same packet, allow a
> picture count followed by a length and binary data for each picture,

This is more practical, though we probably want to leave room to define 
additional types of binary data later (e.g., use the FLAC 
METADATA_BLOCK_HEADER and/or BLOCK_TYPE values). Again, I'm interested 
in the issues of code re-use for other formats. Notably, this is hard to 
make compatible with Vorbis because it encodes one non-zero "framing 
bit" after the main comment data (and mandates it be checked).

>   (3) Specify a way to store attached pictures in the file outside of
> the Opus stream.  This is the way that containers such as Quicktime
> and Matroska work, but to do that with Ogg would require another
> stream that contains the pictures, since the Ogg container itself does
> not provide metadata.

This can already be done by specifying a relative URL instead of actual 
picture data (by setting the mime type appropriately). This has the 
advantage that a single file can be used for multiple tracks, which 
provides considerably more space savings than avoiding BASE64 encoding 
as soon as you have more than 1 track from the same album. Support for 
and usage of this approach is almost non-existent. Whether that's 
because the convenience to users of having everything embedded in one 
file is worth the extra space or because of the inconvenience to 
application authors of having to (securely) deal with external files, or 
the combination of both of those effects, I don't know.

>   (4) Do not address this.  Attached pictures must be base64-encoded
> and written in a comment.  If users complain, recommend use of
> Matroska or another container that does not have this issue.

We could also choose not to address this _here_, and instead continue to 
defer to the existing vorbis-comment documentation. That wouldn't block 
publication of this draft, and give us time to get implementation 
feedback from the authors of media players and tools who would have to 
deal with this change. I think this is the approach that I personally 
prefer.


From nobody Mon Aug 25 16:12:29 2014
Return-Path: <giles@thaumas.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C701A0350 for <codec@ietfa.amsl.com>; Mon, 25 Aug 2014 16:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4xh7G6Phj0V for <codec@ietfa.amsl.com>; Mon, 25 Aug 2014 16:12:26 -0700 (PDT)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52B01A046A for <codec@ietf.org>; Mon, 25 Aug 2014 16:11:22 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id w10so21293692pde.4 for <codec@ietf.org>; Mon, 25 Aug 2014 16:11:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mD3LGCLsVWpEqRf/oAVH/4a0RCuPwCSevN4jd5qGSsA=; b=Gdrf1glq+yAjQlcFZ5MCoL2etYXfi2lPWOwOClnwI/am4LX7XB76GByXUF4Dy52W2e RST9AYXuSJ+2tQk2+3UwPaBLiONZN4qCXa6COLS8F/s1WuSJzqHmtTE8Z+yQgXQclWrg /YbLDj5tQpvlr6nH2hS1fc6ZKOw2Vu/2mKwkj0zRUeEq2dWIz/eQ/S4DH4pxogDCU93z MPAdr1cMGawDn8PqFHp+Kd8qM/4QRYnhykXOtluS4Q7atopYxovsTp1daDtaD/NfWo8n jHf9TkU1H5gZK3409gG7IMgTcEmCG4Uw/6XLb2+pikzasY8EX/aHZYE+1Kjx7IH+vBui 9HUQ==
X-Gm-Message-State: ALoCoQnui9vuytRh9mbQMxZQIrQhAs5MAov8cHWw3F+7ayDKEQ9//cfP7gWvaaHl+ST1pKH+jJIn
X-Received: by 10.68.69.3 with SMTP id a3mr32742857pbu.94.1409008282636; Mon, 25 Aug 2014 16:11:22 -0700 (PDT)
Received: from tamias.local ([64.214.126.165]) by mx.google.com with ESMTPSA id g7sm1579708pdj.7.2014.08.25.16.11.21 for <codec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 16:11:21 -0700 (PDT)
Message-ID: <53FBC299.1070008@thaumas.net>
Date: Mon, 25 Aug 2014 16:11:21 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: codec@ietf.org
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz>
In-Reply-To: <20140816040140.GA31682@hex.shelbyville.oz>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/I4uMxbQ_3htOIhvPbF5R-gjUiIs
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 23:12:28 -0000

On 2014-08-15 9:01 PM, Ron wrote:

> So the patch applied for this part is now:
> 
>> - If an encoder wishes to use R128 normalization, and the output gain is not
>> - otherwise constrained or specified, the encoder SHOULD write the R128 gain
>> - into the 'output gain' field and store a tag containing "R128_TRACK_GAIN=0".
>> - That is, it should assume that by default tools will respect the 'output gain'
>> - field, and not the comment tag.

I agree this part is confusing. I think it's too terse to offer good
guidance.

>>   If a tool modifies the ID header's 'output gain' field, it MUST also update or
>>   remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present.

This seems helpful in avoiding broken files.

>> + An encoder should assume that by default tools will respect the 'output gain'
>> + field, and not the comment tag.

I read this as a non-normative should. Would it be better:

"By default, implementations of this specification MUST respect the
'output gain' field, but MAY NOT respect the comments. Encoder authors
are advised to take this into account. For example, to produce R128
normalized files it's more reliable for post-processing application to
update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
than to put the normalized value directly in the comment."

This removes the normative suggestion of 'should' while maintaining the
suggestion and rationale.

 -r


From nobody Tue Aug 26 06:06:51 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4901A6FF2 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 06:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6XoE89FPic0 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 06:06:45 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id E9B8B1A6FEC for <codec@ietf.org>; Tue, 26 Aug 2014 06:06:43 -0700 (PDT)
Received: from ppp121-45-6-245.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.6.245]) by ipmail07.adl2.internode.on.net with ESMTP; 26 Aug 2014 22:36:43 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 5AC6EFFEA5 for <codec@ietf.org>; Tue, 26 Aug 2014 22:36:30 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PF9a85zh4YYZ for <codec@ietf.org>; Tue, 26 Aug 2014 22:36:29 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 99439FFD84 for <codec@ietf.org>; Tue, 26 Aug 2014 22:36:29 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 822C880470; Tue, 26 Aug 2014 22:36:29 +0930 (CST)
Date: Tue, 26 Aug 2014 22:36:29 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140826130629.GQ326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53FBC299.1070008@thaumas.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/-yUjBbkLgujHPiox1FPRvj2__D4
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 13:06:48 -0000

On Mon, Aug 25, 2014 at 04:11:21PM -0700, Ralph Giles wrote:
> On 2014-08-15 9:01 PM, Ron wrote:
> 
> > So the patch applied for this part is now:
> > 
> >> - If an encoder wishes to use R128 normalization, and the output gain is not
> >> - otherwise constrained or specified, the encoder SHOULD write the R128 gain
> >> - into the 'output gain' field and store a tag containing "R128_TRACK_GAIN=0".
> >> - That is, it should assume that by default tools will respect the 'output gain'
> >> - field, and not the comment tag.
> 
> I agree this part is confusing. I think it's too terse to offer good
> guidance.
> 
> >>   If a tool modifies the ID header's 'output gain' field, it MUST also update or
> >>   remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present.
> 
> This seems helpful in avoiding broken files.

Yes, I agree that part stands as a sensible MUST.  About the only thing
I could niggle about there might be s/update/correct/, but I don't
personally think it's unclear what that indicates you should do or why
(though I'm probably too close to this to be a good judge of that for
other readers).  And if we say 'correct' we might need a few words on,
or a simple example of, what 'correct' actually is.


> >> + An encoder should assume that by default tools will respect the 'output gain'
> >> + field, and not the comment tag.
> 
> I read this as a non-normative should. Would it be better:

I couldn't really decide whether that ought to be normative or not,
mostly because I couldn't draw a useful distinction between "you
SHOULD assume this because the standard says so" and "you should
assume this because it's about the only sensible thing you can".

Either way what we're really saying is "unless you have a good
reason to believe otherwise, this is what you should expect",
which fits with both normative and 'ordinary' use.

(partly that question was in the context of us having a few other
non-normative keywords we need to clean up still, I don't feel
strongly about it going either way here)


> "By default, implementations of this specification MUST respect the
> 'output gain' field, but MAY NOT respect the comments.

I'd be inclined to drop the "By default" there, unless we're going
to expand on what the exceptions to the 'default' might be.

> Encoder authors are advised to take this into account.

In which case the normative language probably makes that sentence
redundant.

> For example, to produce R128
> normalized files it's more reliable for post-processing application to
> update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
> than to put the normalized value directly in the comment."

Should the example there be ALBUM_GAIN rather than track gain
(consistent with what we recommended before these changes, and
with what is probably preferred in the absence of finer grained
recalibration)?

Maybe s/it's more reliable/it would be more robust/ ?
(the distinction I see there being between what real apps
_actually_ do in practice now and in the future, and what
the standard guarantees you as being baseline support ...
I don't have data on which is really more reliable, but I
can tell you what the standard guarantees is most likely).

But yes, I think that addresses the missing context I saw,
assuming it doesn't also revert whatever it was Ian found
confusing to remove it in the first place :)

  Ron



From nobody Tue Aug 26 06:24:20 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E691A6FD6 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 06:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPfI2SU2_cFf for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 06:24:15 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 652261A6FD3 for <codec@ietf.org>; Tue, 26 Aug 2014 06:24:15 -0700 (PDT)
Received: from ppp121-45-6-245.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.6.245]) by ipmail07.adl2.internode.on.net with ESMTP; 26 Aug 2014 22:54:14 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 313B2FFEA5; Tue, 26 Aug 2014 22:54:02 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pEucyHZI2f95; Tue, 26 Aug 2014 22:54:01 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 830CAFFBA7; Tue, 26 Aug 2014 22:54:01 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 6E0AC80470; Tue, 26 Aug 2014 22:54:01 +0930 (CST)
Date: Tue, 26 Aug 2014 22:54:01 +0930
From: Ron <ron@debian.org>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Message-ID: <20140826132401.GR326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53FBBCA1.8060708@xiph.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/Zl1DEtJbRVNrVIyk_5HU8liKGB8
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 13:24:18 -0000

On Mon, Aug 25, 2014 at 03:45:53PM -0700, Timothy B. Terriberry wrote:
> With my individual hat on...
> 
> Mark Harris wrote:
> >Attached pictures are not mentioned at all in the current Ogg Opus
> >draft (draft-ietf-codec-oggopus-04), which simply defers to the
> >vorbis-comment specification for the format of metadata, with a few
> >specific differences such as new gain tags.
> 
> The theory was that it wasn't necessary to re-invent the wheel here.
> Applications which already support Vorbis-style album art can add support
> for Opus album art with as little as one line of code (because they can, and
> do, share comment-parsing routines among Vorbis/Theora/Speex/etc.). This is
> not just a matter of engineering simplicity, but also speed of adoption.
> 
> >  (1) Specify that comments may contain either UTF-8 or binary data,
> >according to some rule.  For example, if the name of the tag begins
> >with "@" then its value is binary data and not intended to be
> >displayed as text, and is otherwise UTF-8.  There is no technical
> 
> This has backwards-compatibility problems. Is this unique to Opus or would
> we expect other formats to adopt the same strategy? (see above about
> code-reuse). What would we do about existing tags that might already start
> with an '@'? How would we represent a field name that we want to start with
> an '@' (for whatever reason)?
> 
> We could also simply use a more compact form of embedding binary data in
> UTF-8, but those have higher implementation complexity (and two encodings to
> choose from is higher still).
> 
> >      Alternatively, ordinary tag names could be used and the value
> >itself could be used to indicate that it is non-UTF-8 binary data, for
> >example by including a null character prefix before the binary data,
> >or a 0xff byte prefix (which is not valid UTF-8), or a null byte
> >delimiter in place of "=".  However using distinct tag names seems
> >cleaner.
> 
> Existing, naive tools are likely to mis-handle all of those things (e.g.,
> copying the tag as the empty string, rejecting it as invalid and removing
> it, rejecting the whole comment packet as invalid, etc.).
> 
> >  (2) Immediately following the comments, in the same packet, allow a
> >picture count followed by a length and binary data for each picture,
> 
> This is more practical, though we probably want to leave room to define
> additional types of binary data later (e.g., use the FLAC
> METADATA_BLOCK_HEADER and/or BLOCK_TYPE values). Again, I'm interested in
> the issues of code re-use for other formats. Notably, this is hard to make
> compatible with Vorbis because it encodes one non-zero "framing bit" after
> the main comment data (and mandates it be checked).
> 
> >  (3) Specify a way to store attached pictures in the file outside of
> >the Opus stream.  This is the way that containers such as Quicktime
> >and Matroska work, but to do that with Ogg would require another
> >stream that contains the pictures, since the Ogg container itself does
> >not provide metadata.
> 
> This can already be done by specifying a relative URL instead of actual
> picture data (by setting the mime type appropriately). This has the
> advantage that a single file can be used for multiple tracks, which provides
> considerably more space savings than avoiding BASE64 encoding as soon as you
> have more than 1 track from the same album. Support for and usage of this
> approach is almost non-existent. Whether that's because the convenience to
> users of having everything embedded in one file is worth the extra space or
> because of the inconvenience to application authors of having to (securely)
> deal with external files, or the combination of both of those effects, I
> don't know.
> 
> >  (4) Do not address this.  Attached pictures must be base64-encoded
> >and written in a comment.  If users complain, recommend use of
> >Matroska or another container that does not have this issue.
> 
> We could also choose not to address this _here_, and instead continue to
> defer to the existing vorbis-comment documentation. That wouldn't block
> publication of this draft, and give us time to get implementation feedback
> from the authors of media players and tools who would have to deal with this
> change. I think this is the approach that I personally prefer.

I think that sounds like the best approach to me too.

There are real things that can be improved there, but none of them are
actually specific to the Opus Ogg mapping, and any solution to them
that gets buy-in from implementors does seem likely to be something
they'd also want to reuse more widely with other mappings as well.

Whether we'd eventually want to bring that work back here to formalise
a new proposed standard for "Ogg metadata" is a separate question,
but either way it seems like a work that could (and should) occur
independently of OggOpus, and that could apply to many other things
in addition to it.  The important question for this draft is have we
adequately defined the needed codec mapping to encapsulate it in Ogg.

  Ron



From nobody Tue Aug 26 13:25:38 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7791A8823 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 13:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level: 
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AZmke7ceiAr for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 13:25:36 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EADD1A87EE for <codec@ietf.org>; Tue, 26 Aug 2014 13:25:36 -0700 (PDT)
Received: from [10.252.28.253] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 782EEF202C for <codec@ietf.org>; Tue, 26 Aug 2014 13:25:35 -0700 (PDT)
Message-ID: <53FCED3F.3080608@xiph.org>
Date: Tue, 26 Aug 2014 13:25:35 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: codec@ietf.org
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140826130629.GQ326@hex.shelbyville.oz>
In-Reply-To: <20140826130629.GQ326@hex.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/8z4DChxRV5LujauR7ijBouLCA9s
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 20:25:38 -0000

Ron wrote:
> (partly that question was in the context of us having a few other
> non-normative keywords we need to clean up still, I don't feel

Now's the time to get those cleaned up. Care to propose resolutions to 
the list for them?


From nobody Tue Aug 26 13:26:18 2014
Return-Path: <gmaxwell@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A851A87F0 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 13:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HFca3iUfRLC for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 13:26:16 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F63F1A86F8 for <codec@ietf.org>; Tue, 26 Aug 2014 13:26:16 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id rp18so12363447iec.19 for <codec@ietf.org>; Tue, 26 Aug 2014 13:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qszOeviFWuUF20jSPqs9mogMQUa9/5KvUOQpyPczN44=; b=h9t4Ro2ARnAXIylO1wqHWpwNoI5PzCP7dwv1U0tSImSHXffzLHbzxH7s24WoQu09+Z EPkw60TkEeHPAf+sTDi9VMp8V+6hbtcVSeKDY2VGMICEOhEsIiR31QLJXmAAZkzx+PLY gLZnebWIo6TV7jXA8rYWS/UA0K8/YOnErKWJaZeA7DM0bTRl46H1JT1TEPIH0SLUCDzK lx1/I+cjXNar+UO/uNbZjeP/eKr2ighGLXfKkPSAPE0ZO+7AaAVZpj9Uf/ptnmv2H+Sr 8vMQxymLB65Pp6QryWqZ9m0dXoZU+D7MSG7ZQ2g1ezF5KX4k9FdYFUt/YpJk7A7e3h9+ v9OQ==
MIME-Version: 1.0
X-Received: by 10.42.67.133 with SMTP id t5mr9907991ici.62.1409084775689; Tue, 26 Aug 2014 13:26:15 -0700 (PDT)
Sender: gmaxwell@gmail.com
Received: by 10.107.14.67 with HTTP; Tue, 26 Aug 2014 13:26:15 -0700 (PDT)
In-Reply-To: <20140826130629.GQ326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140826130629.GQ326@hex.shelbyville.oz>
Date: Tue, 26 Aug 2014 13:26:15 -0700
X-Google-Sender-Auth: ZopzaUWB0Qb_oqKr4myUAdpHs6k
Message-ID: <CAAS2fgQZc6pNMRRf-1Zo73r9kR5Gu0VqrzLNKw_b2eXqs_GbOg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Ron <ron@debian.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/01d4Bdh94EcFopoXm0PpuQS45h4
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 20:26:17 -0000

On Tue, Aug 26, 2014 at 6:06 AM, Ron <ron@debian.org> wrote:
>> For example, to produce R128
>> normalized files it's more reliable for post-processing application to
>> update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
>> than to put the normalized value directly in the comment."
>
> Should the example there be ALBUM_GAIN rather than track gain
> (consistent with what we recommended before these changes, and
> with what is probably preferred in the absence of finer grained
> recalibration)?

Is there a reason we shouldn't just have two examples?


From nobody Tue Aug 26 16:34:54 2014
Return-Path: <basilgohar@librevideo.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27861A00B5 for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 16:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8zWjjzK7bGO for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 16:34:45 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3991A017A for <codec@ietf.org>; Tue, 26 Aug 2014 16:34:44 -0700 (PDT)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 344C9657804 for <codec@ietf.org>; Tue, 26 Aug 2014 19:34:42 -0400 (EDT)
Message-ID: <53FD198E.8040103@librevideo.org>
Date: Tue, 26 Aug 2014 19:34:38 -0400
From: Basil Mohamed Gohar <basilgohar@librevideo.org>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: codec@ietf.org
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <20140826132401.GR326@hex.shelbyville.oz>
In-Reply-To: <20140826132401.GR326@hex.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/u4XuFrYt_q35L0yCYyJBpOc__9k
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 23:34:52 -0000

On 08/26/2014 09:24 AM, Ron wrote:
> On Mon, Aug 25, 2014 at 03:45:53PM -0700, Timothy B. Terriberry wrote:
>> With my individual hat on...
>>
>> Mark Harris wrote:
>>> Attached pictures are not mentioned at all in the current Ogg Opus
>>> draft (draft-ietf-codec-oggopus-04), which simply defers to the
>>> vorbis-comment specification for the format of metadata, with a few
>>> specific differences such as new gain tags.
>>
>> The theory was that it wasn't necessary to re-invent the wheel here.
>> Applications which already support Vorbis-style album art can add support
>> for Opus album art with as little as one line of code (because they can, and
>> do, share comment-parsing routines among Vorbis/Theora/Speex/etc.). This is
>> not just a matter of engineering simplicity, but also speed of adoption.
>>
>>>  (1) Specify that comments may contain either UTF-8 or binary data,
>>> according to some rule.  For example, if the name of the tag begins
>>> with "@" then its value is binary data and not intended to be
>>> displayed as text, and is otherwise UTF-8.  There is no technical
>>
>> This has backwards-compatibility problems. Is this unique to Opus or would
>> we expect other formats to adopt the same strategy? (see above about
>> code-reuse). What would we do about existing tags that might already start
>> with an '@'? How would we represent a field name that we want to start with
>> an '@' (for whatever reason)?
>>
>> We could also simply use a more compact form of embedding binary data in
>> UTF-8, but those have higher implementation complexity (and two encodings to
>> choose from is higher still).
>>
>>>      Alternatively, ordinary tag names could be used and the value
>>> itself could be used to indicate that it is non-UTF-8 binary data, for
>>> example by including a null character prefix before the binary data,
>>> or a 0xff byte prefix (which is not valid UTF-8), or a null byte
>>> delimiter in place of "=".  However using distinct tag names seems
>>> cleaner.
>>
>> Existing, naive tools are likely to mis-handle all of those things (e.g.,
>> copying the tag as the empty string, rejecting it as invalid and removing
>> it, rejecting the whole comment packet as invalid, etc.).
>>
>>>  (2) Immediately following the comments, in the same packet, allow a
>>> picture count followed by a length and binary data for each picture,
>>
>> This is more practical, though we probably want to leave room to define
>> additional types of binary data later (e.g., use the FLAC
>> METADATA_BLOCK_HEADER and/or BLOCK_TYPE values). Again, I'm interested in
>> the issues of code re-use for other formats. Notably, this is hard to make
>> compatible with Vorbis because it encodes one non-zero "framing bit" after
>> the main comment data (and mandates it be checked).
>>
>>>  (3) Specify a way to store attached pictures in the file outside of
>>> the Opus stream.  This is the way that containers such as Quicktime
>>> and Matroska work, but to do that with Ogg would require another
>>> stream that contains the pictures, since the Ogg container itself does
>>> not provide metadata.
>>
>> This can already be done by specifying a relative URL instead of actual
>> picture data (by setting the mime type appropriately). This has the
>> advantage that a single file can be used for multiple tracks, which provides
>> considerably more space savings than avoiding BASE64 encoding as soon as you
>> have more than 1 track from the same album. Support for and usage of this
>> approach is almost non-existent. Whether that's because the convenience to
>> users of having everything embedded in one file is worth the extra space or
>> because of the inconvenience to application authors of having to (securely)
>> deal with external files, or the combination of both of those effects, I
>> don't know.
>>
>>>  (4) Do not address this.  Attached pictures must be base64-encoded
>>> and written in a comment.  If users complain, recommend use of
>>> Matroska or another container that does not have this issue.
>>
>> We could also choose not to address this _here_, and instead continue to
>> defer to the existing vorbis-comment documentation. That wouldn't block
>> publication of this draft, and give us time to get implementation feedback
>> from the authors of media players and tools who would have to deal with this
>> change. I think this is the approach that I personally prefer.
> 
> I think that sounds like the best approach to me too.
> 
> There are real things that can be improved there, but none of them are
> actually specific to the Opus Ogg mapping, and any solution to them
> that gets buy-in from implementors does seem likely to be something
> they'd also want to reuse more widely with other mappings as well.
> 
> Whether we'd eventually want to bring that work back here to formalise
> a new proposed standard for "Ogg metadata" is a separate question,
> but either way it seems like a work that could (and should) occur
> independently of OggOpus, and that could apply to many other things
> in addition to it.  The important question for this draft is have we
> adequately defined the needed codec mapping to encapsulate it in Ogg.
> 
>   Ron

Some thoughts:

1.  If the last option is preferred by most, then let's get to work on
canvassing the existing players that we think are best suited to this,
rather than letting it languish and becoming forgotten.  In other words,
let's make this our own itch and scratch it.

2.  Isn't there already a specification for Kate that allows usage of
images in Ogg?  Hackish, I know, but that might lend some guidance on a
way (good or bad?) to encode binary image data.

3.  Does Ogg Skeleton have any mechanism or "spot" for this kind of
binary image data?

Personally, I don't think the 33% inflation due to base64 encoding
aspect is that big of a deal.  I'd be interested to know if there are
cases where the image data becomes large in comparison to the audio data
in an OggOpus file, and that might make it more relevant to pursue a
more optimal solution.


-- 
Libre Video
http://librevideo.org


From nobody Tue Aug 26 16:54:41 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85A41A01EB for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 16:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKcGCl4H4hZq for <codec@ietfa.amsl.com>; Tue, 26 Aug 2014 16:54:37 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2281A00AA for <codec@ietf.org>; Tue, 26 Aug 2014 16:54:37 -0700 (PDT)
Received: from [10.252.28.253] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 017DCF22D3 for <codec@ietf.org>; Tue, 26 Aug 2014 16:54:35 -0700 (PDT)
Message-ID: <53FD1E3B.5020008@xiph.org>
Date: Tue, 26 Aug 2014 16:54:35 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: codec@ietf.org
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <20140826132401.GR326@hex.shelbyville.oz> <53FD198E.8040103@librevideo.org>
In-Reply-To: <53FD198E.8040103@librevideo.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/spPqcluLgJQLA2_Asi3jmW03uhY
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 23:54:39 -0000

Basil Mohamed Gohar wrote:
> 1.  If the last option is preferred by most, then let's get to work on
> canvassing the existing players that we think are best suited to this,
> rather than letting it languish and becoming forgotten.  In other words,
> let's make this our own itch and scratch it.

At a minimum, I planned to bring it up with VLC/libav/FFmpeg/etc. 
developers at VideoLAN Dev Days next month.


From nobody Wed Aug 27 07:30:57 2014
Return-Path: <flac@nartowicz.co.uk>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8531A06CC for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 07:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDkSv85XyjCs for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 07:30:46 -0700 (PDT)
Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) by ietfa.amsl.com (Postfix) with ESMTP id BA4A11A06DB for <codec@ietf.org>; Wed, 27 Aug 2014 07:30:45 -0700 (PDT)
Received: from crunchbang ([81.103.170.84]) by know-smtprelay-2-imp with bizsmtp id jqWj1o01F1pcAUZ01qWkzR; Wed, 27 Aug 2014 15:30:44 +0100
X-Originating-IP: [81.103.170.84]
X-Spam: 0
X-Authority: v=2.1 cv=MI/umapl c=1 sm=1 tr=0 a=bYNBYWS+Sj0o/bRbN9Xjqw==:117 a=bYNBYWS+Sj0o/bRbN9Xjqw==:17 a=KEKbkQfv9EEA:10 a=ud0LK1MCnV8A:10 a=RoPK8JaNmp0A:10 a=kj9zAlcOel0A:10 a=hU221NPEAAAA:8 a=gh7d8CtTAAAA:8 a=A_2ddQx5bAP0ifLQ_iMA:9 a=82cMei_0jNFtWA2O:21 a=txzQMHKmgxJcD2zG:21 a=CjuIK1q_8ugA:10 a=clUD5SDhlIcA:10
Date: Wed, 27 Aug 2014 15:30:43 +0100
From: Ian Nartowicz <flac@nartowicz.co.uk>
To: codec@ietf.org
Message-ID: <20140827153043.2ff5e031@crunchbang>
In-Reply-To: <53FBC299.1070008@thaumas.net>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; i486-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/yE_kNYU_uOWQqtbFgWacqxah2j0
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 14:30:49 -0000

On Mon, 25 Aug 2014 16:11:21 -0700
Ralph Giles <giles@thaumas.net> wrote:

>On 2014-08-15 9:01 PM, Ron wrote:
>
>> So the patch applied for this part is now:
>> 
>>> - If an encoder wishes to use R128 normalization, and the output gain is not
>>> - otherwise constrained or specified, the encoder SHOULD write the R128 gain
>>> - into the 'output gain' field and store a tag containing
>>> "R128_TRACK_GAIN=0".
>>> - That is, it should assume that by default tools will respect the 'output
>>> gain'
>>> - field, and not the comment tag.
>
>I agree this part is confusing. I think it's too terse to offer good
>guidance.
>
>>>   If a tool modifies the ID header's 'output gain' field, it MUST also
>>> update or remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if
>>> present.
>
>This seems helpful in avoiding broken files.
>
>>> + An encoder should assume that by default tools will respect the 'output
>>> gain'
>>> + field, and not the comment tag.
>
>I read this as a non-normative should. Would it be better:
>
>"By default, implementations of this specification MUST respect the
>'output gain' field, but MAY NOT respect the comments. Encoder authors
>are advised to take this into account. For example, to produce R128
>normalized files it's more reliable for post-processing application to
>update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
>than to put the normalized value directly in the comment."
>
>This removes the normative suggestion of 'should' while maintaining the
>suggestion and rationale.
>
> -r

This seems like a step backwards to me.  That MUST is a requirement
that wasn't present before.  An earlier statement is "Virtually all players
and media frameworks should apply it by default.", which I think is the
appropriate guidance.

>I'd be inclined to drop the "By default" there, unless we're going
>to expand on what the exceptions to the 'default' might be.

I agree with Ron that saying "By default" and "MUST" in the same sentence is
confusing, but I think the solution is not to say MUST.  There are exceptions
to the default.  Trying to specify them all here would seem an impossible feat
of guesswork, but since they exist then MUST is too strong.

>Is there a reason we shouldn't just have two examples?
Possibly, but if you start down that path you need more than two examples.
Either tag or both may be present, with or without a pre-existing output gain
value.

The intention of this change, after much discussion, was specifically not to
constrain how an encoder should split an R128 gain between the output gain
field and the tags.  Hence: advice rather than normative language.  Part of the
reason is quickly apparent in the discussion of whether to place the track gain
or album gain in the output gain field, and the answer was not to specify.

--ian


From nobody Wed Aug 27 08:59:21 2014
Return-Path: <giles@thaumas.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C6F1A0B02 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 08:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sm2-4NbMCIy for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 08:59:17 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1162D1A0AF8 for <codec@ietf.org>; Wed, 27 Aug 2014 08:59:17 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id rd18so530010iec.0 for <codec@ietf.org>; Wed, 27 Aug 2014 08:59:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KB5CgnwpQyF8eJAj2AKvxmxkRqjDhh6DLC79zITKdso=; b=QQxeplmQbv4Ni60Kl34hS0VWxe+nwkSfS2RGUEZJM/zRPKbq2hobmxVlgd9B1GPqlS mXBYBiXBPsjAL+fqaluA9KpML2fqJnrsp7UtvlTI7P+3YsDej8GjOiFLXp+hXbZrGj3B 9V4vXTp9Fh2esxvt7REKPnArMjLifSKg+Dpg6qYLTb7RKyMelpsTuLGZbMTSpgGWs6iz zBZc5Lu8Ge3+av5moLZilFxwW0laerB1tl9DkjD8C7hDlHJ77HBzIwqGcCxXfRcyD6g3 3YFHHOMrOB/N9uTuSWAEIvIjB165+NsPoB9t/tM+2ZndD7pNmyh1rqlZIwhjMWFyKSdn EvBw==
X-Gm-Message-State: ALoCoQldK1rolOGWVtltbQqJSwbbb9QNENVSR5AsD37sb75qfqyXQDp5v8RhtAjuwxsZmbasLluJ
X-Received: by 10.43.53.198 with SMTP id vr6mr3051499icb.74.1409155156495; Wed, 27 Aug 2014 08:59:16 -0700 (PDT)
Received: from tamias.local (S0106185933484486.vc.shawcable.net. [174.6.214.147]) by mx.google.com with ESMTPSA id rr3sm4546802igb.19.2014.08.27.08.59.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 08:59:15 -0700 (PDT)
Message-ID: <53FE0054.5080207@thaumas.net>
Date: Wed, 27 Aug 2014 08:59:16 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ian Nartowicz <flac@nartowicz.co.uk>, codec@ietf.org
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang>
In-Reply-To: <20140827153043.2ff5e031@crunchbang>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/8OAHEaNjeG9lKT1ftn9rdDYb6Cs
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 15:59:19 -0000

On 2014-08-27 7:30 AM, Ian Nartowicz wrote:

> This seems like a step backwards to me.  That MUST is a requirement
> that wasn't present before.  An earlier statement is "Virtually all players
> and media frameworks should apply it by default.", which I think is the
> appropriate guidance.

That's another one of those non-normative 'should' clauses we'd like to
resolve. The intention was that players MUST apply the gain; the
exception was for things like transcoders or DAW systems which could
propagate the gain without altering the decoded data. Can you think of
others?

I was trying to clarify that here, while leaving similar wiggle room in
the word 'respect'.

>> Is there a reason we shouldn't just have two examples?

Only brevity. The previous example used album gain because it was
offering guidance on how to record album gain in the absence of an
R128_ALBUM_GAIN tag. I switched to track gain because I thought that was
the more common normalization.

"Implementations of this specification MUST respect the 'output gain'
field, but MAY NOT respect the comments. Encoder authors are advised to
take this into account. For example, it is more robust for a
post-processing application to performing track normalization to update
the 'output gain' field and write a comment 'R128_TRACK_GAIN=0' than to
put the normalization value directly in the comment."

 -r


From nobody Wed Aug 27 14:21:34 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299F41A0303 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 14:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htq9LdWpN-eE for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 14:21:31 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 13B841A0141 for <codec@ietf.org>; Wed, 27 Aug 2014 14:21:30 -0700 (PDT)
Received: from ppp121-45-6-245.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.6.245]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Aug 2014 06:51:30 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id B335EFFF44; Thu, 28 Aug 2014 06:51:16 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id niYmeUzuHqQi; Thu, 28 Aug 2014 06:51:14 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 931A2FF82C; Thu, 28 Aug 2014 06:51:14 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7EE8380470; Thu, 28 Aug 2014 06:51:14 +0930 (CST)
Date: Thu, 28 Aug 2014 06:51:14 +0930
From: Ron <ron@debian.org>
To: Ian Nartowicz <flac@nartowicz.co.uk>
Message-ID: <20140827212114.GV326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140827153043.2ff5e031@crunchbang>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/hjbRbH-uK9GaCxxtvy6SwJqQo5w
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 21:21:33 -0000

On Wed, Aug 27, 2014 at 03:30:43PM +0100, Ian Nartowicz wrote:
> On Mon, 25 Aug 2014 16:11:21 -0700 Ralph Giles <giles@thaumas.net> wrote:
> 
> >"By default, implementations of this specification MUST respect the
> >'output gain' field, but MAY NOT respect the comments. Encoder authors
> >are advised to take this into account. For example, to produce R128
> >normalized files it's more reliable for post-processing application to
> >update the 'output gain' field and write a comment 'R128_TRACK_GAIN=0'
> >than to put the normalized value directly in the comment."
> >
> >This removes the normative suggestion of 'should' while maintaining the
> >suggestion and rationale.
> 
> This seems like a step backwards to me.  That MUST is a requirement
> that wasn't present before.  An earlier statement is "Virtually all players
> and media frameworks should apply it by default.", which I think is the
> appropriate guidance.

It really always has been intended as a MUST (but we know there are some
VERY RARE exceptions where you won't).

No general purpose player should ever provide a button to disable this.

The floating point version of Opus can ostensibly record samples in the
range of +/- FLT_MAX, and while the reference implementation places some
arbitrary "you've got to be kidding" lower bound on that, it's still
several times greater than the fixed point range, and there is no reason
an alternative implementation might not allow a larger range.

There's at least one test sample that is way below the range of hearing
without the output gain applied, and is only audible after it is, and
there is no reason that real world samples might not exist in the
opposite configuration - where they play at a normal level with the
gain applied, but would blow your speakers and eardrums out without it.

If someone played such a sample, which they thought they knew what it
contained having played it elsewhere, in a player that disables this,
you're potentially going to make them very, very sad.  Or at the very
least, surprised and annoyed.

The output gain is a guarantee to whoever mastered the recording that
"by default" this is the output level that will be seen.  It lets them
take the raw data of their latest rocket launch or atomic test and
'losslessly' adjust the gain to more reasonable listening levels, for
whatever they decide is 'reasonable' for that file, making it suitable
for more general use without needing to re-encode it.


> >I'd be inclined to drop the "By default" there, unless we're going
> >to expand on what the exceptions to the 'default' might be.
> 
> I agree with Ron that saying "By default" and "MUST" in the same sentence is
> confusing, but I think the solution is not to say MUST.

My 'objection' to the "By default" was actually that it watered down the
MUST without providing specific guidance as to why most implementers
shouldn't assume they are the special snowflakes the exceptions apply to.

Your confusion in thinking that it's not really a MUST for a general
purpose player, is exactly why I think we need to strengthen and
clarify that to avoid having inconsistent players and sad users :)

> There are exceptions to the default.  Trying to specify them all here
> would seem an impossible feat of guesswork, but since they exist then
> MUST is too strong.

I don't think we need to specify them exhaustively to be able to give
some guidance for what they might be (or perhaps more importantly,
what they definitely are NOT).

In a general sense, really the *only* exception is: "I want to analyse
the raw signal level, in order to further adjust the output_gain and/or
other gain reference tags".

As soon as you say "I want to play this to a listening human", your
exception to the MUST is null and void.  They have a volume knob
which does that job, and it adjusts the level after the output_gain
correction is made (or possibly automatically with guidance from
the comment tags).


Personally, I think that exception is obvious enough in its own right
and well within the existing language elsewhere that we can simply
say MUST with no exceptions here (ie. an encoder that is going to
set the output_gain obviously must be able to measure the raw level
it is going to apply that to -- but that's not the same as playing
it to a listener at that level).

If we need some further language to clarify that though, then yes
we definitely ought to add it.  I can elaborate on the intention,
but we really do need you to tell us what vital clue is missing
that means that isn't clear in your reading of it.  If you think
we should drop the MUST, then clearly something is still not clear
enough here yet :)


> The intention of this change, after much discussion, was specifically not to
> constrain how an encoder should split an R128 gain between the output gain
> field and the tags.

That's actually never been constrained, and nothing in the language
proposed here should have changed that.  The output_gain has *never*
been constrained to any particular calibration other than "what the
person who made this file thinks is best", and any R128 gain was
*always* to be applied after the output_gain correction.

> Hence: advice rather than normative language.

We're providing advice about how you might use R128 tags and whether
or not a player needs to respect them.  The output_gain always has
been, and MUST be, normative and mandatory for all players at all
times.

> Part of the reason is quickly apparent in the discussion of whether to
> place the track gain or album gain in the output gain field, and the
> answer was not to specify.

I thought the only confusion there was "how do I turn off album gain
if there isn't an explicit album gain tag?" - given that you MUST NOT
disable the output_gain, which may or may not have been calibrated to
R128 album gain levels.

You still MUST NOT turn off output gain, even if R128_ALBUM_GAIN=0
is explicitly specified, since the raw file still could be at "I'm
50 meters from ground zero of an atomic test" levels.  That still
doesn't imply *anything* about what the output_gain is or means.

But we've given you an explicit album gain tag now that you can
switch on or off if it's not zero.  I'm not sure what the remaining
confusion really is, but indeed, let's find it and clear it up.

  Cheers,
  Ron



From nobody Wed Aug 27 14:27:11 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF961A0722 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 14:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJr6hmSPi1L5 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 14:27:09 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE971A02A3 for <codec@ietf.org>; Wed, 27 Aug 2014 14:27:09 -0700 (PDT)
Received: from ppp121-45-6-245.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.6.245]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Aug 2014 06:57:08 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 25935FFF44; Thu, 28 Aug 2014 06:56:56 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EFys3qx0dRxo; Thu, 28 Aug 2014 06:56:55 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 9502FFFD70; Thu, 28 Aug 2014 06:56:55 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 85E0C80470; Thu, 28 Aug 2014 06:56:55 +0930 (CST)
Date: Thu, 28 Aug 2014 06:56:55 +0930
From: Ron <ron@debian.org>
To: Ralph Giles <giles@thaumas.net>
Message-ID: <20140827212655.GW326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE0054.5080207@thaumas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53FE0054.5080207@thaumas.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/-RFfc1zMGbtB4taaBv_XhdeSpeA
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 21:27:10 -0000

On Wed, Aug 27, 2014 at 08:59:16AM -0700, Ralph Giles wrote:
> 
> "Implementations of this specification MUST respect the 'output gain'
> field, but MAY NOT respect the comments. Encoder authors are advised to
> take this into account. For example, it is more robust for a
> post-processing application to performing track normalization to update
> the 'output gain' field and write a comment 'R128_TRACK_GAIN=0' than to
> put the normalization value directly in the comment."

s/to performing/performing/ ?  Or maybe "that is performing"?

But yeah, modulo whatever still seems to be misleading Ian,
that seems about right to me.

  Ron



From nobody Wed Aug 27 15:54:46 2014
Return-Path: <flac@nartowicz.co.uk>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9F61A01D2 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 15:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-S1ecMbwTJ2 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 15:54:41 -0700 (PDT)
Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) by ietfa.amsl.com (Postfix) with ESMTP id 44C101A0151 for <codec@ietf.org>; Wed, 27 Aug 2014 15:54:40 -0700 (PDT)
Received: from crunchbang ([81.103.170.84]) by know-smtprelay-2-imp with bizsmtp id jyue1o01y1pcAUZ01yufSc; Wed, 27 Aug 2014 23:54:39 +0100
X-Originating-IP: [81.103.170.84]
X-Spam: 0
X-Authority: v=2.1 cv=MI/umapl c=1 sm=1 tr=0 a=bYNBYWS+Sj0o/bRbN9Xjqw==:117 a=bYNBYWS+Sj0o/bRbN9Xjqw==:17 a=KEKbkQfv9EEA:10 a=ud0LK1MCnV8A:10 a=RoPK8JaNmp0A:10 a=kj9zAlcOel0A:10 a=hU221NPEAAAA:8 a=tkKQBNAWq-XDekDwCj0A:9 a=3SwqxaF5wcGUcyXn:21 a=p07tGZv5LudfkD6d:21 a=CjuIK1q_8ugA:10
Date: Wed, 27 Aug 2014 23:54:38 +0100
From: Ian Nartowicz <flac@nartowicz.co.uk>
To: codec@ietf.org
Message-ID: <20140827235438.1eb21a89@crunchbang>
In-Reply-To: <20140827212114.GV326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <20140827212114.GV326@hex.shelbyville.oz>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; i486-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/wYRUk1LuGjYBn_oVT_WDwVCiqjs
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 22:54:44 -0000

<snip>

>I thought the only confusion there was "how do I turn off album gain
>if there isn't an explicit album gain tag?" - given that you MUST NOT
>disable the output_gain, which may or may not have been calibrated to
>R128 album gain levels.
>
>You still MUST NOT turn off output gain, even if R128_ALBUM_GAIN=0
>is explicitly specified, since the raw file still could be at "I'm
>50 meters from ground zero of an atomic test" levels.  That still
>doesn't imply *anything* about what the output_gain is or means.
>
>But we've given you an explicit album gain tag now that you can
>switch on or off if it's not zero.  I'm not sure what the remaining
>confusion really is, but indeed, let's find it and clear it up.
>
>  Cheers,
>  Ron
>
And so we're back to square one.

There's no confusion here.  I have pointed up a perfectly reasonable and
widespread requirement to sometimes, at the user's choice, play back music *as
encoded* (and sometimes normalised to R128).  You don't accept that this
is a legitimate requirement, even making up bizarre examples to somehow refute
real things that are happening in real software.

I do understand the desire for "just works" level adjustment in the majority of
software, but I ask for recognition that some specialist software requires more
stringent control of the playback parameters.  I even offered what I believe is
a better all-round solution of the output gain setting the desired playback
level and the two tags each containing the *entire* R128 normalisation
adjustment, to be subtracted out if desired while still leaving the rest of the
output gain in place.

Whenever we get close to a form of words that accepts this requirement as a
possibility, albeit far short of properly supporting it, it slips away again.
I'm out of ideas.

--ian


From nobody Wed Aug 27 16:23:34 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1141A011B for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 16:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIfDqQ_u1pD3 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 16:23:31 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7781A0110 for <codec@ietf.org>; Wed, 27 Aug 2014 16:23:31 -0700 (PDT)
Received: from [10.252.28.253] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7B7C5F240C for <codec@ietf.org>; Wed, 27 Aug 2014 16:23:30 -0700 (PDT)
Message-ID: <53FE6872.60200@xiph.org>
Date: Wed, 27 Aug 2014 16:23:30 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: codec@ietf.org
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang>
In-Reply-To: <20140827153043.2ff5e031@crunchbang>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/tMN5VAH0ROVRa0lk8MFopJg3IRo
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 23:23:33 -0000

Ian Nartowicz wrote:
> This seems like a step backwards to me.  That MUST is a requirement
> that wasn't present before.  An earlier statement is "Virtually all players
> and media frameworks should apply it by default.", which I think is the
> appropriate guidance.

I agree with Ian. The point was to clean up usage of an un-capitalized 
RFC 2119 keyword that we all agree was not meant to be normative. We 
shouldn't be adding NEW normative requirements in its place.

We have not to this point had any problem getting players to apply the 
output gain by default with the current spec language (and Greg 
Maxwell's test files that tell people their player is broken if they 
don't implement this). We've had to cajole a few, but once we have, I 
believe it has been fixed in every case.

-With my individual hat on


From nobody Wed Aug 27 16:31:01 2014
Return-Path: <gmaxwell@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827491A011F for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 16:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcAQREHmc-dy for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 16:30:56 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D731A011B for <codec@ietf.org>; Wed, 27 Aug 2014 16:30:56 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id h3so117305igd.5 for <codec@ietf.org>; Wed, 27 Aug 2014 16:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5aMWsyrgd4rpdunqZ6VDrdLzmobMcvILGwW8JTn+4XA=; b=iZRSX5Sd3iHiNTxcTvONBzR6YKDShkiPgkFOYENOB6vxPnBaWCepQcN+VkYINfEWoT gZUok/X4eKTilAsKgT8wiGGCWaxEiYk4PTkIPOwWiseTD+FSS0kQVy8L8gix1JAj1S9Q WhsM+gwQG3F3TGN9yOnikCNNJWPRaCjgiKNPG9MetiMj3q0dyiN8x0AnJZ2ZWZJdKIGC YQMRCFL6zE1hK13vIcd4nFZZC62OP/ACJrFuLGzGddD2mnE0MvMBtzIli4Oco2bFFlcY 3vDgKv6Tq5w9FLwoHy3uBMEwhoJhwXqBrM52E4e1Sc0hEOdS1oguUrdn2+B3oyNisRuy CEAw==
MIME-Version: 1.0
X-Received: by 10.42.83.131 with SMTP id h3mr987550icl.77.1409182255676; Wed, 27 Aug 2014 16:30:55 -0700 (PDT)
Sender: gmaxwell@gmail.com
Received: by 10.107.14.67 with HTTP; Wed, 27 Aug 2014 16:30:55 -0700 (PDT)
In-Reply-To: <53FE6872.60200@xiph.org>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE6872.60200@xiph.org>
Date: Wed, 27 Aug 2014 16:30:55 -0700
X-Google-Sender-Auth: XNiHBiV8_DqcNZduU6qysc8Y9K4
Message-ID: <CAAS2fgTTtq7Zp6y=2sxE5EGLMbQhkDo1=c2=aA-V_MQ0=dgjMw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/A5N6W74CvwLgm7jvbpEQYFEK3yE
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 23:31:00 -0000

On Wed, Aug 27, 2014 at 4:23 PM, Timothy B. Terriberry
<tterribe@xiph.org> wrote:
> Ian Nartowicz wrote:
>>
>> This seems like a step backwards to me.  That MUST is a requirement
>> that wasn't present before.  An earlier statement is "Virtually all
>> players
>> and media frameworks should apply it by default.", which I think is the
>> appropriate guidance.
>
>
> I agree with Ian. The point was to clean up usage of an un-capitalized RF=
C
> 2119 keyword that we all agree was not meant to be normative. We shouldn'=
t
> be adding NEW normative requirements in its place.
>
> We have not to this point had any problem getting players to apply the
> output gain by default with the current spec language (and Greg Maxwell's
> test files that tell people their player is broken if they don't implemen=
t
> this). We've had to cajole a few, but once we have, I believe it has been
> fixed in every case.
>
> -With my individual hat on

Part of the reason for this is that the libopus as of 1.1 (IIRC) makes
it very easy to handle this=E2=80=94 you just make a ctl and pass the conte=
nt
of the tag, and libopus handles the gain internally... so no DSP for
implementers. (And it handles it in a way that expands the dynamic
range for fixed point).

Alas, not even RFC6919 has a "MUST unless you actually know better".


From nobody Wed Aug 27 17:33:23 2014
Return-Path: <jmvalin@jmvalin.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5221A0166 for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 17:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level: 
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQUim2-T1njg for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 17:33:22 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194931A010A for <codec@ietf.org>; Wed, 27 Aug 2014 17:33:21 -0700 (PDT)
Received: from panoramix.jmvalin.ca (modemcable167.97-201-24.mc.videotron.ca [24.201.97.167]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 12E58F210E; Wed, 27 Aug 2014 17:33:20 -0700 (PDT)
Message-ID: <53FE78D0.5060900@jmvalin.ca>
Date: Wed, 27 Aug 2014 20:33:20 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Gregory Maxwell <greg@xiph.org>,  "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE6872.60200@xiph.org> <CAAS2fgTTtq7Zp6y=2sxE5EGLMbQhkDo1=c2=aA-V_MQ0=dgjMw@mail.gmail.com>
In-Reply-To: <CAAS2fgTTtq7Zp6y=2sxE5EGLMbQhkDo1=c2=aA-V_MQ0=dgjMw@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/zctRSJ84-Gd5G3XSUcNB-lAGSO0
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 00:33:23 -0000

> Alas, not even RFC6919 has a "MUST unless you actually know better".

No, but 2119 does and it's spelled S-H-O-U-L-D :-)

	Jean-Marc


From nobody Wed Aug 27 20:41:00 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E9D1A031A for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 20:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yks10oxeznJF for <codec@ietfa.amsl.com>; Wed, 27 Aug 2014 20:40:55 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 01A251A0319 for <codec@ietf.org>; Wed, 27 Aug 2014 20:40:54 -0700 (PDT)
Received: from ppp121-45-6-245.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.6.245]) by ipmail05.adl6.internode.on.net with ESMTP; 28 Aug 2014 13:10:53 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 84948FFEED for <codec@ietf.org>; Thu, 28 Aug 2014 13:10:52 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zBGzlhbNwOm4 for <codec@ietf.org>; Thu, 28 Aug 2014 13:10:51 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id AE037FF94F for <codec@ietf.org>; Thu, 28 Aug 2014 13:10:51 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 9B4F380470; Thu, 28 Aug 2014 13:10:51 +0930 (CST)
Date: Thu, 28 Aug 2014 13:10:51 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140828034051.GX326@hex.shelbyville.oz>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <20140827212114.GV326@hex.shelbyville.oz> <20140827235438.1eb21a89@crunchbang>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140827235438.1eb21a89@crunchbang>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/GIc4HYNkexMy66wbnUGOAM-28cc
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 03:40:57 -0000

On Wed, Aug 27, 2014 at 11:54:38PM +0100, Ian Nartowicz wrote:
> <snip>
> 
> >I thought the only confusion there was "how do I turn off album gain
> >if there isn't an explicit album gain tag?" - given that you MUST NOT
> >disable the output_gain, which may or may not have been calibrated to
> >R128 album gain levels.
> >
> >You still MUST NOT turn off output gain, even if R128_ALBUM_GAIN=0
> >is explicitly specified, since the raw file still could be at "I'm
> >50 meters from ground zero of an atomic test" levels.  That still
> >doesn't imply *anything* about what the output_gain is or means.
> >
> >But we've given you an explicit album gain tag now that you can
> >switch on or off if it's not zero.  I'm not sure what the remaining
> >confusion really is, but indeed, let's find it and clear it up.
> >
> >  Cheers,
> >  Ron
>
> And so we're back to square one.

Well, if you think that, then maybe it's *you* not making your case
clearly to us :)

> There's no confusion here.  I have pointed up a perfectly reasonable and
> widespread requirement to sometimes, at the user's choice, play back music *as
> encoded* (and sometimes normalised to R128).

The output_gain is part of the encoding (not a tag that can be freely
stripped away or ignored).  If you want to play the music *as encoded*
that includes the hardware gain.

If it doesn't, and that isn't "guaranteed", then you've basically made
that useless to anyone mastering a recording, and their only option
for robust behaviour in the face of people who insist on making players
that ignore it is to completely re-encode it from scratch.

Which leaves us not only back with the original problem that this was
designed to solve, but with a worse than useless field in the header
that nobody will actually know how it really behaves in the real world.
And you don't get what you want from it either, because the person who
mastered it, irretrievably destroyed that information when they made
their track "guaranteed to work on broken players too".
Everyone loses if you add uncertainty here.

There is one gain knob that is entirely at the discretion of the person
mastering the recording.  We've now given you two that users and players
can fiddle with to their heart's content.

Why do you need yet another one, and why should people making masters
not have one they can rely on to be an integral part of the encoding?


> You don't accept that this is a legitimate requirement, even making up
> bizarre examples to somehow refute real things that are happening in
> real software.

The only requirement that you made clear to me was you wanted a
separate, clearly defined R128_ALBUM_GAIN as well as the track gain.

We've given you that.

If you're going to handwave about other "perfectly reasonable and
widespread requirements", you're going to have to actually give some
examples to make that case.  Especially if it comes at the cost of
the perfectly reasonable requirement for people mastering tracks to
be able to losslessly fix something that was originally (and quite
possibly accidentally) recorded at an entirely unlistenable and
unreasonable level.

We've given you examples of the originally intended use.  You can
brand them bizarre if you like, but badly captured original
recordings that need level adjustment to be actually useable are
hardly something unheard of.  Why force people to re-encode a live
opus capture to make it useable, when they can trivially correct
it instead?

What specific counterexample do you have that is so important it
should make that effectively impossible to do reliably?

  Ron



From nobody Thu Aug 28 07:55:18 2014
Return-Path: <lennox@cs.columbia.edu>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77C1A06F7 for <codec@ietfa.amsl.com>; Thu, 28 Aug 2014 07:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQaoiQBs1mRk for <codec@ietfa.amsl.com>; Thu, 28 Aug 2014 07:55:13 -0700 (PDT)
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id BB4931A06BF for <codec@ietf.org>; Thu, 28 Aug 2014 07:55:13 -0700 (PDT)
Received: from compute01.cs.columbia.edu (compute01.cs.columbia.edu [128.59.11.31]) by mailbackend.panix.com (Postfix) with ESMTP id 2E16E2EFF1; Thu, 28 Aug 2014 10:55:12 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21503.17104.519869.67662@compute01.cs.columbia.edu>
Date: Thu, 28 Aug 2014 10:55:12 -0400
To: Ralph Giles <giles@thaumas.net>
In-Reply-To: <53FBC299.1070008@thaumas.net>
References: <20140813222201.54fe7910@crunchbang> <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net>
X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu)
From: lennox@cs.columbia.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/VXdqsKcEVLhoLb0armZUx4QhsEs
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 14:55:15 -0000

On Monday, August 25 2014, "Ralph Giles" wrote to "codec@ietf.org" saying:

> "By default, implementations of this specification MUST respect the
> 'output gain' field, but MAY NOT respect the comments. Encoder authors
> are advised to take this into account.

"MAY NOT" isn't an RFC 2119 keyword, because it's ambiguous in English.  I
assume you mean "MAY ignore the comments", not "MUST NOT respect the
comments"?

-- 
Jonathan Lennox
lennox@cs.columbia.edu


From nobody Thu Aug 28 09:05:22 2014
Return-Path: <giles@thaumas.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4711A877C for <codec@ietfa.amsl.com>; Thu, 28 Aug 2014 09:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBXUh8T56-dh for <codec@ietfa.amsl.com>; Thu, 28 Aug 2014 09:05:19 -0700 (PDT)
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E641A87A3 for <codec@ietf.org>; Thu, 28 Aug 2014 09:05:03 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id h18so8258482igc.12 for <codec@ietf.org>; Thu, 28 Aug 2014 09:05:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gSLZvYQOqJq/bd0ncpuTZmg6GPe0E9qIAl6eIn+/Hdk=; b=ctfixoeg8LP/xjKPIoYrgvykSc3XiVRtWmudEBe3DXgtxzfbQdsNNNF/7gP7mYXyi2 1XxpAU883UPKEcwR69Rzb/8dEKv4FWwKJy6xelltLiDV7jb5Jg0wP0oDoNfZQHnG7nh+ qzk9hCymLftxI2pOgOSLy2wVMQpPmUFmC6aFX/Ag5Pt/FsCTDGZx4aWfIv579R+3uz6m Xqs0apvUdyfdpIboEHNUvK3uPHu5tsHwZ2dqNKDy2++NhKAedNdS+XiAyUN3GqbvYAPs Pgg32V3Kla/Ihw48EG/RBIP1ZuXsO3YoTtkbb7Cwsd7U0HFMrUBPK9Mu+CMGq5CHzg3c 4T8Q==
X-Gm-Message-State: ALoCoQmUZJaVtJx4P3AIbfbokmp2MyxF+OvtdRLHJdZ4KHLi7vyJqwgyRPLc2gVhtxiL/ZtfkuBq
X-Received: by 10.50.111.225 with SMTP id il1mr6664066igb.28.1409241902364; Thu, 28 Aug 2014 09:05:02 -0700 (PDT)
Received: from tamias.local ([64.214.126.165]) by mx.google.com with ESMTPSA id m4sm41909992igr.20.2014.08.28.09.05.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 09:05:01 -0700 (PDT)
Message-ID: <53FF532C.3080006@thaumas.net>
Date: Thu, 28 Aug 2014 09:05:00 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: lennox@cs.columbia.edu
References: <20140813222201.54fe7910@crunchbang>	<53ECF0E0.9060308@xiph.org>	<20140816040140.GA31682@hex.shelbyville.oz>	<53FBC299.1070008@thaumas.net> <21503.17104.519869.67662@compute01.cs.columbia.edu>
In-Reply-To: <21503.17104.519869.67662@compute01.cs.columbia.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/R9skBauw7uivjAHh0B3hrHpFvM0
Cc: codec@ietf.org
Subject: Re: [codec] draft-ietf-codec-oggopus and "album" gain
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 16:05:20 -0000

On 2014-08-28 7:55 AM, lennox@cs.columbia.edu wrote:
> "MAY NOT" isn't an RFC 2119 keyword, because it's ambiguous in English.  I
> assume you mean "MAY ignore the comments", not "MUST NOT respect the
> comments"?

Good point! Thanks.

 -r


From nobody Fri Aug 29 22:38:20 2014
Return-Path: <markh.sj@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9401A875D for <codec@ietfa.amsl.com>; Fri, 29 Aug 2014 22:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCgherKqhPKm for <codec@ietfa.amsl.com>; Fri, 29 Aug 2014 22:38:15 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768E91A8764 for <codec@ietf.org>; Fri, 29 Aug 2014 22:38:15 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id h3so182716igd.3 for <codec@ietf.org>; Fri, 29 Aug 2014 22:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x0qwIBNl6QzQJvBEBsraGRnJQBm61mTLTzNX1T/X3Sg=; b=EoJs14pIbx30vLSwntI/iqyuSCrA1XJfkz4LtXsrZ18jOy6XF6PvIbooo56ur/2h7o Y3YN/Y+eVt/v23tMK0ZUumO7hWZ1/w5oS6hBLcsq/3FakTY14cft/LvGoSnuOBzTBTlO kyodHLo4ADO7C7eFtcrpogTHtaDmRh6Kg63b52IO934/PEnHGvA/H1C37kKXBglO2N7m 4RjiDWEYmkNQsuRgpyj3HFfCv2PzEGk+2DmiAZsscwvjsFFaNWqFzIjwqPsrXkxwiLBT xmID/2QZaOiebkyDiHEerszRJPo6pI8y7Z9qgdfSeW4XbTgx252cfnGJXhEZ8Qp3/HHw +GnQ==
MIME-Version: 1.0
X-Received: by 10.43.111.6 with SMTP id em6mr15854723icc.21.1409377094854; Fri, 29 Aug 2014 22:38:14 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Fri, 29 Aug 2014 22:38:14 -0700 (PDT)
In-Reply-To: <53FBBCA1.8060708@xiph.org>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org>
Date: Fri, 29 Aug 2014 22:38:14 -0700
X-Google-Sender-Auth: 3r9IvS1WFCtYSorGm_wc7IBX72A
Message-ID: <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, Basil Mohamed Gohar <basilgohar@librevideo.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/Danj4WBbPL4UQuJIvjVXt9AAdQg
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 05:38:18 -0000

Timothy B. Terriberry wrote:
> Mark Harris wrote:
>>
>> Attached pictures are not mentioned at all in the current Ogg Opus
>> draft (draft-ietf-codec-oggopus-04), which simply defers to the
>> vorbis-comment specification for the format of metadata, with a few
>> specific differences such as new gain tags.
>
>
> The theory was that it wasn't necessary to re-invent the wheel here.
> Applications which already support Vorbis-style album art can add support
> for Opus album art with as little as one line of code (because they can, and
> do, share comment-parsing routines among Vorbis/Theora/Speex/etc.). This is
> not just a matter of engineering simplicity, but also speed of adoption.


Use of vorbis-comment is fine for its intended purpose, and to be
clear I do not suggest that something else be used for short,
text comments such as TITLE, ALBUM, or ARTIST.  The referenced
vorbis-comment document explicitly states that it is meant for
short, text comments, not arbitrary metadata.  You don't use a
hammer in place of a screwdriver just because you have a hammer
handy and have found that it can get the screw into the hole.  I
can understand the reasoning behind trying to shoehorn attached
pictures into comments for Ogg Vorbis, as the Ogg Vorbis encapsulation
format was designed before attached pictures were common and it had
already been finalized for a number of years; this was one of the
few options available.  However it is clear that vorbis-comment was
not intended for this kind of data and that the efficiency of this
encoding for attached pictures is significantly worse than what is
available with other common audio file formats.

As for sharing code, native FLAC also uses Vorbis-style comments
for short text tags and a binary format for attached pictures; in
fact it is the same binary format that is being suggested.  I don't
see why an application supporting Ogg Opus and FLAC, or just Ogg
Opus, should need to include code for base64 encoding and decoding
attached pictures just because that was needed by a different older
format.  If an application supports both Ogg Vorbis and Ogg Opus
then it will need to support both the old and new styles of gain
tags as well as the old and new styles of picture tags.  The format
of the new picture data is the same as the old except that the
base64 encoding is no longer needed, so it is easy to support both
just as it is easy to support both gain tags.  It is also easy to
distinguish the old and new styles without having to know which to
expect.  So code sharing should not be an issue.


>
>
>>   (1) Specify that comments may contain either UTF-8 or binary data,
>> according to some rule.  For example, if the name of the tag begins
>> with "@" then its value is binary data and not intended to be
>> displayed as text, and is otherwise UTF-8.  There is no technical
>
>
> This has backwards-compatibility problems. Is this unique to Opus or would
> we expect other formats to adopt the same strategy? (see above about
> code-reuse).


Like the new gain tags, applications could decide to support the
new tags with older formats, although I wouldn't expect the new
tags to be recommended for older formats that already have another
well established standard.  On the other hand, if there are other
reasons to create a new incompatible version of the older standard
(e.g. TransOgg :)) then it would make sense to recommend use of the
new tags in the new version.


>              What would we do about existing tags that might already start
> with an '@'? How would we represent a field name that we want to start with
> an '@' (for whatever reason)?


The vorbis-comment specification explicitly allows new unregisterd
"nonstandard" tag names, and does not offer any system of ensuring
unique tag names, so this is an issue with the design of the
vorbis-comment specification in that it is always possible that
someone else has used the same tag name for another purpose.  If
this is considered to be a serious compatibility issue then the
design of vorbis-comment is seriously flawed, because no one would
then be able to introduce new tags since they may already be in use
with a different purpose or syntax.

If there is known existing usage of tag names beginning with @,
with text values, then a different indicator should be chosen for
binary tags.  However even if such tags exist I would not expect
it to be an issue, as this should have little effect other than the
way in which these tags, if unrecognized, are displayed and edited
by default.  I would expect that most applications do not do anything
with unrecognized tags and should be completely unaffected.  Any
ability to copy and delete tags should also also not be impacted.


>
> We could also simply use a more compact form of embedding binary data in
> UTF-8, but those have higher implementation complexity (and two encodings to
> choose from is higher still).


Even writing the picture data in binary form, attaching pictures
in Ogg still adds more overhead than any other non-Ogg format that
I tried (results below), primarily due to the Ogg lacing for the
picture data.  However, despite being dead last the binary format
is close enough to be competitive.

  Overhead of attaching 300 KB PNG image:
    MP3/ID3:                 + 0.04% of image size
    Matroska:                + 0.06% of image size
    FLAC:                    + 0.09% of image size
    M4A/iTunes:              + 0.32% of image size
    Ogg Opus base64 comment: +33.95% of image size
    Ogg Opus binary comment: + 0.46% of image size

If the format is not even competitive with other popular encapsulation
formats in common feature areas at the time of standardization,
what that tells me is that it is not ready for standardization yet,
as that will just lock in the bad decisions.  If we were talking
about a difficult problem that required serious tradeoffs in order
to address then it may be worth just acknowledging that other
encapsulation formats are better suited to such uses, however that
would be unfortunate for something that is easily addressed with
no tradeoffs required.

What is really nice about the Opus codec is that it does not require
any compromise; it is freely available and offers the best quality
available for a wide variety of applications from low-latency
low-bitrate speech to transparent quality multi-channel music, which
previously required several non-free codecs and careful codec
selection in order to choose something that will work well for all
use cases.  A standardized encapsulation format that similarly
required no compromise for all of the common use cases would make
an appropriate match.  An encapsulation format with two to three
orders of magnitude more overhead than anything else for a commonly
used feature that can account for a significant portion of actual
files would be an especially poor choice.


>
>>   (2) Immediately following the comments, in the same packet, allow a
>> picture count followed by a length and binary data for each picture,
>
>
> This is more practical, though we probably want to leave room to define
> additional types of binary data later (e.g., use the FLAC
> METADATA_BLOCK_HEADER and/or BLOCK_TYPE values). Again, I'm interested in
> the issues of code re-use for other formats. Notably, this is hard to make
> compatible with Vorbis because it encodes one non-zero "framing bit" after
> the main comment data (and mandates it be checked).


A block type sounds great.  I was just trying to minimize the changes
by keeping the binary format identical to what Ogg Vorbis passed to the
base64 encoder.

Although something similar could be done for Ogg Vorbis, this is
probably not the place to discuss that.  Anyone who has implemented
the current Ogg Opus draft knew that they were implementing a draft
version of the standard that is subject to change, but that is not
the case for Ogg Vorbis.


>
>
>>   (3) Specify a way to store attached pictures in the file outside of
>> the Opus stream.  This is the way that containers such as Quicktime
>> and Matroska work, but to do that with Ogg would require another
>> stream that contains the pictures, since the Ogg container itself does
>> not provide metadata.
>
>
> This can already be done by specifying a relative URL instead of actual
> picture data (by setting the mime type appropriately). This has the
> advantage that a single file can be used for multiple tracks, which provides
> considerably more space savings than avoiding BASE64 encoding as soon as you
> have more than 1 track from the same album. Support for and usage of this
> approach is almost non-existent. Whether that's because the convenience to
> users of having everything embedded in one file is worth the extra space or
> because of the inconvenience to application authors of having to (securely)
> deal with external files, or the combination of both of those effects, I
> don't know.


While that may be useful in some cases, I think there is still a
strong need for the ability to keep everything related to the track
in a single file.  That makes it easier to copy to a phone or other
playback device, easier to make available for download or sharing,
easier to ensure security and privacy, and less likely to break when
files are moved or copied.  To be clear I was referring to some way of
attaching the pictures to the same file.


>
>
>>   (4) Do not address this.  Attached pictures must be base64-encoded
>> and written in a comment.  If users complain, recommend use of
>> Matroska or another container that does not have this issue.
>
>
> We could also choose not to address this _here_, and instead continue to
> defer to the existing vorbis-comment documentation. That wouldn't block
> publication of this draft, and give us time to get implementation feedback
> from the authors of media players and tools who would have to deal with this
> change. I think this is the approach that I personally prefer.


If this is not addressed prior to the standard being finalized, it
becomes very difficult to add later.  Ogg Vorbis is still much worse
at this than other formats even after so long because it was not
part of the design, and a kludge was needed in order to add it
afterwards without affecting compatibility.  Now there is an
opportunity to address this in a cleaner manner for Ogg Opus
encapsulation.  This opportunity should not be squandered and the
same mistakes repeated once again.


Basil Mohamed Gohar wrote:
> 2.  Isn't there already a specification for Kate that allows usage of
> images in Ogg?  Hackish, I know, but that might lend some guidance on a
> way (good or bad?) to encode binary image data.


It looks like Kate can support timed text and timed images, but
not attached pictures that are not associated with particular times.


>
> 3.  Does Ogg Skeleton have any mechanism or "spot" for this kind of
> binary image data?


I do not see anything related in Ogg Skeleton.


> I'd be interested to know if there are
> cases where the image data becomes large in comparison to the audio data


I just checked some audio files that I have locally on this computer.
Considering only commercially sold music, the ratio of attached
picture size (in binary form) to compressed audio size was as high
as 26.28%.  (This was on a 48 second MP3 interlude track that is
part of an album, with a single attached picture.)  The largest
attached picture I found was a 1.9 MB PNG, although that was on a
podcast episode, not commercially sold music.

If it is expected that Ogg Opus will be taken seriously as a
compressed audio format then it would do well to avoid adding 34%
to these sizes for no added benefit.


 - Mark


From nobody Sat Aug 30 00:27:53 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B811A884E for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 00:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy6B-Nhh6_J6 for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 00:27:49 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 695A81A8854 for <codec@ietf.org>; Sat, 30 Aug 2014 00:27:49 -0700 (PDT)
Received: from ppp121-45-54-132.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.54.132]) by ipmail06.adl6.internode.on.net with ESMTP; 30 Aug 2014 16:57:48 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 686D3FFF3F for <codec@ietf.org>; Sat, 30 Aug 2014 16:57:46 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3do3g6uvuGtQ for <codec@ietf.org>; Sat, 30 Aug 2014 16:57:45 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id B1CA1FF9AC for <codec@ietf.org>; Sat, 30 Aug 2014 16:57:45 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id A219A80470; Sat, 30 Aug 2014 16:57:45 +0930 (CST)
Date: Sat, 30 Aug 2014 16:57:45 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140830072745.GF326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/s4cIdefBIi6ibYMIcpVP335_la4
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 07:27:52 -0000

On Fri, Aug 29, 2014 at 10:38:14PM -0700, Mark Harris wrote:
> Timothy B. Terriberry wrote:
> > We could also choose not to address this _here_, and instead continue to
> > defer to the existing vorbis-comment documentation. That wouldn't block
> > publication of this draft, and give us time to get implementation feedback
> > from the authors of media players and tools who would have to deal with this
> > change. I think this is the approach that I personally prefer.
> 
> If this is not addressed prior to the standard being finalized, it
> becomes very difficult to add later.

I don't see why you think this is so?  Ogg was designed from the outset
to be easily extensible to carry and multiplex any sort of data.

There are all sorts of things that people might want to append to an
Opus track, and we clearly can't define, let alone imagine, all of
them here and today, since some of them haven't even been invented yet.

If you think something is missing from our ability to generically
extend this to include other 'non-opus' data at a later date, then
perhaps we ought to consider that.  But I think getting bogged down
on finalising the codec mapping to Ogg, because we don't have things
that weren't part of the charter of this group, that nobody has wanted
enough to raise before now, and that there are no published and tested
implementations of, is scope creep that ought to be a separate matter
of study, with a separate proposed standard as a properly generic
extension to RFC 3533 and/or RFC 5334.

Otherwise where does this stop?  We can't give people a published
Ogg mapping for Opus until we have optimal support for embedded
pony holograms?  I'm sure someone somewhere thinks that's a very
important feature.  Like alternate image encodings though, I don't
see why a standard for that can't be created later that will work
in a standard way for anything in an Ogg container, not just Opus.
Which seems like a far better outcome than kludging something in
here at the last minute, doesn't it?

What are we missing that makes that impossible?

  Ron



From nobody Sat Aug 30 08:06:00 2014
Return-Path: <markh.sj@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1051A8A64 for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 08:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_gt7nwG1t8i for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 08:05:57 -0700 (PDT)
Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B631A8A63 for <codec@ietf.org>; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
Received: by mail-ig0-f194.google.com with SMTP id r2so1321191igi.1 for <codec@ietf.org>; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=C24nNYkPbv0tInvung+bn4yrC//GgrRhabMWMLTji7I=; b=N2BykkkfFo4I4d4f7xYYj2gt/BEh3JJwp7imSGNqIS4Dl7JxAYe/rO/HfIvhYeuTLi n7X3k7ItVGPQAyQfwjuYxnHlbjARMEvHjZeiCNfCgVbx25E6UVFXDi7U9QCdryJb81Pu aATrVCFWAkA80CBVzpoqOVQJv1Gcfz+ulU2tuSiA8VzNbFgOZr4xqlBS2k6iqrQEc66f ivVvQ8nkEms3MoRU7d6BSFLvjK4gDOu78aeaAYUFqakKcfbgIwcNlRKvnEFF7MZxdHn4 ZdL6KDuNEHDzqBUZWmsN0gZPQYlxfq/hGf44tWgYPukzRLe4FGGImfugl9aN3SJTMDV9 NJCQ==
MIME-Version: 1.0
X-Received: by 10.50.26.66 with SMTP id j2mr11167865igg.45.1409411156273; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
In-Reply-To: <20140830072745.GF326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz>
Date: Sat, 30 Aug 2014 08:05:56 -0700
X-Google-Sender-Auth: O8PsU5swaSc9yaGyZn2Nd14IlUQ
Message-ID: <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: "codec@ietf.org" <codec@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/A9HYLwtFY4CjGxsOUNIrfF_V0EY
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 15:05:58 -0000

Ron wrote:
> On Fri, Aug 29, 2014 at 10:38:14PM -0700, Mark Harris wrote:
>> If this is not addressed prior to the standard being finalized, it
>> becomes very difficult to add later.
>
> I don't see why you think this is so?  Ogg was designed from the outset
> to be easily extensible to carry and multiplex any sort of data.

Yes, arbitrary binary data is allowed by Ogg, and none of my proposals
involved changes to Ogg.  This is about Ogg Opus files as defined by
the draft draft-ietf-codec-oggopus-04.  The current version of the
draft does include some binary metadata within an Ogg Opus stream,
such as channel mappings, but does not provide any mechanism for
adding additional metadata to the Ogg Opus stream in a binary format.
Furthermore the current draft does not permit an Ogg Opus file to
contain any other multiplexed streams (section 10).

> What are we missing that makes that impossible?

If the draft included a way to add arbitrary binary metadata to the
Ogg Opus stream, or allowed an Ogg Opus file to contain attached
pictures that are stored in another multiplexed stream, then the
details of the picture format could be specified outside of this
specification.

 - Mark


From nobody Sat Aug 30 09:21:29 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62341A8A99 for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 09:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS1tbDbKxhUl for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 09:21:24 -0700 (PDT)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id A6F971A8A96 for <codec@ietf.org>; Sat, 30 Aug 2014 09:21:23 -0700 (PDT)
Received: from ppp121-45-54-132.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.54.132]) by ipmail04.adl6.internode.on.net with ESMTP; 31 Aug 2014 01:51:22 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 6A3EBFFF3F for <codec@ietf.org>; Sun, 31 Aug 2014 01:51:20 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ITMFH0taKVeR for <codec@ietf.org>; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 9869EFF8BF for <codec@ietf.org>; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 820B380470; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Date: Sun, 31 Aug 2014 01:51:19 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140830162119.GG326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/iTEQ929cjyOp6o3UmPCfDeYGUtc
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 16:21:25 -0000

On Sat, Aug 30, 2014 at 08:05:56AM -0700, Mark Harris wrote:
> Ron wrote:
> > On Fri, Aug 29, 2014 at 10:38:14PM -0700, Mark Harris wrote:
> >> If this is not addressed prior to the standard being finalized, it
> >> becomes very difficult to add later.
> >
> > I don't see why you think this is so?  Ogg was designed from the outset
> > to be easily extensible to carry and multiplex any sort of data.
> 
> Yes, arbitrary binary data is allowed by Ogg, and none of my proposals
> involved changes to Ogg.  This is about Ogg Opus files as defined by
> the draft draft-ietf-codec-oggopus-04.  The current version of the
> draft does include some binary metadata within an Ogg Opus stream,
> such as channel mappings, but does not provide any mechanism for
> adding additional metadata to the Ogg Opus stream in a binary format.
> Furthermore the current draft does not permit an Ogg Opus file to
> contain any other multiplexed streams (section 10).

Am I reading a different Section 10 to you?
I don't see anywhere that it prohibits that, and it explicitly defers
to the other RFCs which define how that should be done.

All it says is they are 'not strictly "Ogg Opus files"' - in the same
way that vorbis muxed with theora (or anything else) are "not strictly
Vorbis files".  You use the same mapping as defined here for the Opus
streams, and include whatever else you want along with them.

People have already been doing this for video with Opus.


> > What are we missing that makes that impossible?
> 
> If the draft included a way to add arbitrary binary metadata to the
> Ogg Opus stream, or allowed an Ogg Opus file to contain attached
> pictures that are stored in another multiplexed stream, then the
> details of the picture format could be specified outside of this
> specification.

The OggOpus draft refers to the RFCs which define how to do that.
Which is why I'm suggesting that one option if you want still
pictures, is to define a generic Ogg mapping for them - which could
then be used with any other format that also has an Ogg mapping,
including this one.

There may be better ways to do that, but any optimal way should not
be Opus specific, it should be reusable for any Ogg stream.  This
standard shows you the mapping for an Opus audio stream.  Ogg lets
you combine that with any other stream that anyone might define in
the future.

Since the number of possible permutation for that is unbounded, it
makes perfect sense to me that each reusable part should be defined
separately, and we already have the general rules for combining them.

If there's something in this draft that would block that somehow,
I'm not seeing it yet.  If the codec mapping itself is ok (and we've
got lots of implementations of it now, with no new issues shaking
out from them about that part of it), then anything extra is really
just a "how do we make this work with RFC 3533" problem, isn't it?

  Ron



From nobody Sat Aug 30 16:03:42 2014
Return-Path: <markh.sj@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329F11A6EDE for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 16:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01dXlHEU8_q8 for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 16:03:38 -0700 (PDT)
Received: from mail-ie0-x242.google.com (mail-ie0-x242.google.com [IPv6:2607:f8b0:4001:c03::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6941A6EDC for <codec@ietf.org>; Sat, 30 Aug 2014 16:03:38 -0700 (PDT)
Received: by mail-ie0-f194.google.com with SMTP id rl12so1372431iec.9 for <codec@ietf.org>; Sat, 30 Aug 2014 16:03:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=JSkW8r96Ze3zB3T4vq+CQz8Ocg2uvGcySuF+APkLhgk=; b=jnBzme61jh15noiGyxhFmSTASSrRccmXB6IaOCJmRzA52TJdddnsWWw1ScPrnA2Ym9 PvZKsSHOTyG7mFEI7aJA73epVmsiRY0m82Z0DxWyrv3iOHJPn1nRMk/Jk3FJSBw+VasO Xb0vu8HGVwk0dkW3Pse9UFOxNQLd8xxOfKyFh9dsFqZuhYvcghCIgXbV/6Q85NXUoX4f 8JYwYta3YjkpFyJLQ3ExDAoPC0Se/Tvu2OsbKwsjkDzpZhtwaPFWmYGLh2mjW9K8c6Mz 8HqIG1tPdS7qmHzdlZyZy/lo8d4d6wvD6kg+ImME7u4yeGvKrz3ffsaakkCaYGr4KErR pG0w==
MIME-Version: 1.0
X-Received: by 10.50.36.38 with SMTP id n6mr12681531igj.24.1409439816460; Sat, 30 Aug 2014 16:03:36 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Sat, 30 Aug 2014 16:03:36 -0700 (PDT)
In-Reply-To: <20140830162119.GG326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com> <20140830162119.GG326@hex.shelbyville.oz>
Date: Sat, 30 Aug 2014 16:03:36 -0700
X-Google-Sender-Auth: vI73STtZ5FE_DRALdjLdEwjHiAY
Message-ID: <CAMdZqKH+-Z8T+1LzMOfZGpY1fyAp_k+m6E=nG5oXEeud+X1NgA@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: "codec@ietf.org" <codec@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/a24TrBRH9T_fZPgnNG25YyVN-9k
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 23:03:41 -0000

Ron wrote:
> Which is why I'm suggesting that one option if you want still
> pictures, is to define a generic Ogg mapping for them - which could
> then be used with any other format that also has an Ogg mapping,
> including this one.

I have no objection to adding the pictures in a separate multiplexed
stream; in fact that is my proposal (3).  That is the only one that I
did not specify with enough detail to create interoperable
implementations, because it is a much larger change to the way that
opus-tools currently attaches pictures, and I therefore did not expect
that approach to be favored.  However if there is consensus that that
is the way to go, I can propose something more concrete, and in that
case the only change that I think is needed in the Ogg Opus draft is
to allow these streams in an "Ogg Opus file".  In particular, when
attached pictures are not specifically mentioned, no requirements or
recommendations (such as recommended file extension) should depend on
whether attached pictures are present.

> There may be better ways to do that, but any optimal way should not
> be Opus specific, it should be reusable for any Ogg stream.

Oh I agree completely that this should ideally not be codec-specific.
Not only attached pictures but also tags such as TITLE and ARTIST,
channel mapping, output gain, and loudness/gain required for
normalization would ideally all be maintained by the container and not
be specific to any codec.  The reason that I proposed adding attached
pictures in the codec-specific stream is because Ogg does not provide
metadata at the container level, and all of the metadata I mentioned
is currently being stored on a codec-specific page of the
codec-specific stream.  I would love to see all of this moved out of
the codec-specific stream and into an extensible codec-independent
format elsewhere in the file, and the codec-specific stream reduced to
only what is truly codec-specific, but that is not the direction that
was taken for other metadata.

 - Mark


From nobody Sat Aug 30 22:23:10 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9F1A6FBB for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 22:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p124NbMo-YW for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 22:23:04 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632441A6FB9 for <codec@ietf.org>; Sat, 30 Aug 2014 22:23:04 -0700 (PDT)
Received: from [172.17.0.43] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 8CC31F210B for <codec@ietf.org>; Sat, 30 Aug 2014 22:23:03 -0700 (PDT)
Message-ID: <5402B137.9070809@xiph.org>
Date: Sat, 30 Aug 2014 22:23:03 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: "codec@ietf.org" <codec@ietf.org>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
In-Reply-To: <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/YEzDjlYEX-98g3Fm7DcQ8g3NTys
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 05:23:07 -0000

Mark Harris wrote:
> If the draft included a way to add arbitrary binary metadata to the
> Ogg Opus stream, or allowed an Ogg Opus file to contain attached

There are two possibilities:

1) A proposal for adding binary metadata breaks already-encoded files, 
in which case I don't think we should do it, considering people have 
been producing those files for over two years now under the expectation 
that they would continue to work, or

2) A proposal for adding binary metadata does not break already-encoded 
files, in which case we have exactly the future extension mechanism you 
want (emphasis on "future").

Your Proposal 3 obviously qualifies. I believe Proposal 4 could be made 
to work (some care is required around the Vorbis issue, and to not paint 
ourselves into a corner later, but those are details).

-As an individual


From nobody Sun Aug 31 09:06:34 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A375F1A0370 for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 09:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSligMJW-5Wr for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 09:06:29 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC071A038C for <codec@ietf.org>; Sun, 31 Aug 2014 09:06:28 -0700 (PDT)
Received: from ppp121-45-54-132.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.54.132]) by ipmail06.adl6.internode.on.net with ESMTP; 01 Sep 2014 01:36:27 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 645FDFFF35 for <codec@ietf.org>; Mon,  1 Sep 2014 01:36:25 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fib74UeJus3F for <codec@ietf.org>; Mon,  1 Sep 2014 01:36:24 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 77A5DFF9AC for <codec@ietf.org>; Mon,  1 Sep 2014 01:36:24 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 6545080470; Mon,  1 Sep 2014 01:36:24 +0930 (CST)
Date: Mon, 1 Sep 2014 01:36:24 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140831160624.GH326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com> <20140830162119.GG326@hex.shelbyville.oz> <CAMdZqKH+-Z8T+1LzMOfZGpY1fyAp_k+m6E=nG5oXEeud+X1NgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMdZqKH+-Z8T+1LzMOfZGpY1fyAp_k+m6E=nG5oXEeud+X1NgA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/MU8ubq7QPAFjdlaxmDlIxFes1Hk
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 16:06:31 -0000

On Sat, Aug 30, 2014 at 04:03:36PM -0700, Mark Harris wrote:
> Ron wrote:
> > Which is why I'm suggesting that one option if you want still
> > pictures, is to define a generic Ogg mapping for them - which could
> > then be used with any other format that also has an Ogg mapping,
> > including this one.
> 
> I have no objection to adding the pictures in a separate multiplexed
> stream; in fact that is my proposal (3).  That is the only one that I
> did not specify with enough detail to create interoperable
> implementations, because it is a much larger change to the way that
> opus-tools currently attaches pictures, and I therefore did not expect
> that approach to be favored.  However if there is consensus that that
> is the way to go, I can propose something more concrete, and

I think it's a bit early, and there hasn't yet been enough thorough
investigation of the available backward compatible options, to declare
this is "the way to go", but I do think there's general recognition
that this is one of the options on table for that which could be
investigated further, and could be made to work if it turns out to
be the best available option.

And which wouldn't require changes to this draft once there was a
real consensus among the various stakeholders about an extension
that met all of their various needs for something like this (not
just still picture data).

> in that
> case the only change that I think is needed in the Ogg Opus draft is
> to allow these streams in an "Ogg Opus file".  In particular, when
> attached pictures are not specifically mentioned, no requirements or
> recommendations (such as recommended file extension) should depend on
> whether attached pictures are present.

Most of this draft only talks about and defines the "Ogg Opus stream",
ie. the Ogg mapping needed for a single stream of Opus audio.  Which is
the minimal amount of extra data needed to actually play such a stream.

The comment header allows for the inclusion of arbitrary other metadata
but that data is strictly optional.  Tools can freely ignore it, or
strip it away, and the stream still remains valid and playable.  That
data is in a format that existing tools already knew how to handle,
(and to some extent, in some tools, expect for Ogg audio streams).

The only place we talk about an "Ogg Opus file" (with one exception,
which I think is a 'typo' that should instead say stream, and will
address in a separate mail), is where we say you can mux one or more
Ogg Opus streams together to store them in a file.

Which I think is the correct interpretation, since it indicates they
contain *only* Ogg Opus streams.  A minimal tool which recognises only
the Opus stream mapping is all that is required to handle such files.


Obviously you can also create files which mux an Ogg Opus stream with
other streams, for video, or subtitles, or still pictures, or anything
else - and when you do that, they become a more complex media type,
as defined by RFC 5334, and they become some other kind of file, which
requires something more than a minimal Ogg player to render.

Also obviously, we can more specifically define certain combinations
of those things in the future too "Opus with Daala", "Opus with still
pictures (possibly in a slide show)", "Opus with dancing holo-ponies",
whatever people care to create.  But you're going to need a more
specifically capable player to correctly render those, and it does
seem like they should be noted as distinct for the convenience of end
users as well in any case.  That doesn't make them "second class" or
otherwise frowned upon or illegal, they're just different.

The file extension is exactly such a convenience.  No player should
*ever* rely purely on it to know what the content of a file is.
It's just a hint to users that "A minimal Opus-only player should
be able to play this for you" and nothing more.


I think trying to define (and include or exclude) such things here in
detail is putting the cart before the holo-pony.  Once we have an Ogg
mapping for Daala, and for other arbitrary binary data etc. then
a separate document can define the normative and informational rules
for how such things should be combined with Ogg Opus streams and what
they should be called when in the newly defined form.

I think we leave open the most scope for being able to do that well
if this draft just confines itself to the Opus mapping, and leaves
more complex combinations (including with things that don't exist
yet) to future documents to define.  We just need to make sure we
haven't accidentally made something impossible here - which I don't
think we have (or can't yet see if we do).


> > There may be better ways to do that, but any optimal way should not
> > be Opus specific, it should be reusable for any Ogg stream.
> 
> Oh I agree completely that this should ideally not be codec-specific.
> Not only attached pictures but also tags such as TITLE and ARTIST,
> channel mapping, output gain, and loudness/gain required for
> normalization would ideally all be maintained by the container and not
> be specific to any codec.  The reason that I proposed adding attached
> pictures in the codec-specific stream is because Ogg does not provide
> metadata at the container level, and all of the metadata I mentioned
> is currently being stored on a codec-specific page of the
> codec-specific stream.  I would love to see all of this moved out of
> the codec-specific stream and into an extensible codec-independent
> format elsewhere in the file, and the codec-specific stream reduced to
> only what is truly codec-specific, but that is not the direction that
> was taken for other metadata.

Ogg is purely a generic framing format.  Like TLV, it provides simple
rules that lets a generic tool parse a stream, even if that stream
includes things it doesn't know anything about, to cherry pick the
things that it does out of it.  Unlike TLV, it strikes a balance
between being efficient for small data packets and being able to
contain arbitrarily huge ones in the same format.

And unlike most other media containers, it was designed with the
ability to be streamed right from the outset too.

Which really means that the best format for metadata in any given
use scenario *is* somewhat specific to that scenario.  (ie. it's
totally useless to have all your metadata in container-defined
headers at the beginning of a file if people can join a stream
at any point during its playback, and it's pointless to have
something like "track gain" for a video stream).

For the first few codecs that were mapped to it, the value of
trying to guess and implement a metadata format that would be
properly future-proof was limited.  For the next few, the line
of least resistance was to "do what the other codecs did",
reusing what was good, fixing what turned out to be a mistake
as appropriate.  And much of that was done in an era when the
extra meta-data was always deliberately minimal, since we only
had, like, 100MB disks, if we were the lucky ones!

So yes, the time might well be right to look back on all of the
things that we currently have using it, and devise some format
that can both be used for new mappings that are created, and
retro-fitted to older ones, by and for tools that support it.

Ogg Skeleton was an early attempt along those lines for adding
multi-stream metadata, but it never really seemed to get a lot
of traction, for reasons I don't profess to really know.


But all of that is why I think this draft should confine itself
to just specifying the mapping for Opus streams, and why adding
"enhanced" meta-data should be done as an extension of RFC 3533
in close consultation with the people who'd actually have to
want it and implement it for it to become more generally useful.

I think you've made some good points about that, but I don't
think this group are the ones you need to convince and this
document is the place we need to specify it, in order for that
to really happen now.

Ideally I'd like to see this conversation move from "does this
belong in the Ogg Opus draft", to engagement of the various
interested parties in the merits and needs of the various
options for it (and associated things that haven't been raised
here at all yet), and if there is real momentum for that, to
the question of whether it should become a new milestone for
this group to create a separate document on that (or if not,
where that work should instead best be done).

  Ron



From nobody Sun Aug 31 09:22:02 2014
Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CBA1A03F6 for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 09:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yITO4XzWjnP8 for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 09:21:58 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B35421A03D1 for <codec@ietf.org>; Sun, 31 Aug 2014 09:21:57 -0700 (PDT)
Received: from ppp121-45-54-132.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.54.132]) by ipmail06.adl6.internode.on.net with ESMTP; 01 Sep 2014 01:51:57 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 2D3C1FFF35 for <codec@ietf.org>; Mon,  1 Sep 2014 01:51:56 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dtXQcb-RtBHo for <codec@ietf.org>; Mon,  1 Sep 2014 01:51:55 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id A7DFCFFD7E for <codec@ietf.org>; Mon,  1 Sep 2014 01:51:55 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 92F5380470; Mon,  1 Sep 2014 01:51:55 +0930 (CST)
Date: Mon, 1 Sep 2014 01:51:55 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140831162155.GI326@hex.shelbyville.oz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/EJ90Huw_t61DssiYKRWIuem0y8M
Subject: [codec] R128 tags, per-file or per-stream?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 16:22:00 -0000

In Section 5.2.1 we currently say:

 "An Ogg Opus file MUST NOT have more than one of each tag"

I think that should instead say:

 "An Ogg Opus stream MUST NOT have more than one of each tag"


Since in Section 10 we say:

 "An "Ogg Opus file" consists of one or more sequentially
  multiplexed segments, each containing exactly one Ogg
  Opus stream."

And it doesn't make any sense to me that a file containing multiple
streams should not have these tags apply individually to each stream
(should they have them).


The above change would be consistent with our use of "Ogg Opus stream"
almost everywhere that talks about the mapping, and with "Ogg Opus file"
only where we talk about (possibly) combining streams, mime-types and
filename extensions.

Does anyone have any reason to think we need to say something different
to that here?  I'm assuming the current text was a 'typo', but I don't
know offhand if someone actually intended it to mean something other
than that.

  Ron



From nobody Sun Aug 31 11:20:58 2014
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFDF1A8989 for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 11:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level: 
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xb9c_x4tQGe for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 11:20:54 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1951A8A96 for <codec@ietf.org>; Sun, 31 Aug 2014 11:20:53 -0700 (PDT)
Received: from [172.17.0.43] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3B5E9F218C for <codec@ietf.org>; Sun, 31 Aug 2014 11:20:53 -0700 (PDT)
Message-ID: <54036784.704@xiph.org>
Date: Sun, 31 Aug 2014 11:20:52 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: codec@ietf.org
References: <20140831162155.GI326@hex.shelbyville.oz>
In-Reply-To: <20140831162155.GI326@hex.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/Z1wowZesRIxiQN_SYr4EjWVfw34
Subject: Re: [codec] R128 tags, per-file or per-stream?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 18:20:56 -0000

Ron wrote:
> Does anyone have any reason to think we need to say something different
> to that here?  I'm assuming the current text was a 'typo', but I don't
> know offhand if someone actually intended it to mean something other
> than that.

No, I think you're right. Just fix it.


From nobody Sun Aug 31 11:24:37 2014
Return-Path: <giles@thaumas.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65EC1A8AA3 for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 11:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PT-r1njLSaj for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 11:24:34 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885A81A8AA2 for <codec@ietf.org>; Sun, 31 Aug 2014 11:24:34 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id z10so4303508pdj.31 for <codec@ietf.org>; Sun, 31 Aug 2014 11:24:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=55PHGixXoIM4HpZcDUyt0DDwpWT9cbjOgXqj5RIygzs=; b=jdxMTF/H5lgcGlnayYD+aWqcoe5MCbjaaLuqYf68dlzv1St8Zkjo2wZ6x88OgitaMh w0FO/Jl0Hf/VIqoayMYw/mDiwt2dx6D5JbcS1y6Sq61r9kW/A313+MnpYS02xt/cZ8Jf kFMw4yBbczag62MTWt7Ryp4DELKBFr2W95OpQels4/qCEizzqpDhmup5EOyHQfupNU8z R+Uhgwk2o8Smd7DGjXk1AdBqPYSf+aEFivJaaRW9v3zoDmJnvjFoRdlPYQzhshiskHyc oIG21xJLJ/1Xutvrn6YBTy/muD4ikYX0lpQrxZWbg3uH3cA0sOqNpNfZCUDgwoZR2++Z 9d7w==
X-Gm-Message-State: ALoCoQkdurvXtbvsgGKsHndlAqpzZVxw+FqxX8msX3BNU1/vXnhcjd7vOUeyIKjTYhaxgcEnADos
X-Received: by 10.68.139.232 with SMTP id rb8mr32796037pbb.20.1409509474077; Sun, 31 Aug 2014 11:24:34 -0700 (PDT)
Received: from tamias.local (S0106185933484486.vc.shawcable.net. [174.6.214.147]) by mx.google.com with ESMTPSA id mx3sm8703773pdb.81.2014.08.31.11.24.33 for <codec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 11:24:33 -0700 (PDT)
Message-ID: <54036864.4050208@thaumas.net>
Date: Sun, 31 Aug 2014 11:24:36 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: codec@ietf.org
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com> <20140830162119.GG326@hex.shelbyville.oz>
In-Reply-To: <20140830162119.GG326@hex.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/c3PROhdSipm8lzKFjVvnZOLj88Q
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 18:24:36 -0000

On 2014-08-30 9:21 AM, Ron wrote:

> All [sec. 10] says is they are 'not strictly "Ogg Opus files"'

We do use the phrase "Ogg Opus files" in section 5.2.1 as well, so you
could argue either way. I want that flexibility so unless there's an
objection I'll limit use of that term to section 10.

It's nevertheless true that implementations of this draft have so far
been focussed on a single logical stream per chain segment.

 -r


From nobody Sun Aug 31 23:29:20 2014
Return-Path: <markh.sj@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32A51A007F for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 23:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIz8_TTIOd_j for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 23:29:15 -0700 (PDT)
Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2951A0061 for <codec@ietf.org>; Sun, 31 Aug 2014 23:29:15 -0700 (PDT)
Received: by mail-ie0-f195.google.com with SMTP id at20so1743069iec.2 for <codec@ietf.org>; Sun, 31 Aug 2014 23:29:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=etf5WXSOy1W3J5Vjzffnw4I8xzFWY0utZr+X1IDo9xU=; b=WczvpoPO3mjMCDw4cTL4la3eTOrWTp3olWgjwSgqTusqdhQntKsZPmvfceVRKUBRtG ZuVZ6UcK7+c3YaSNkGin/6fsJU1yyQlkUTydK/DtyOKxJtiC7SnWOSYrCgMFqZOL6rFC VEEhFkNTPoS0gPQO+WH0p4uMlg9VInZxgLsapOX0l3+uHyYu4tU7QpcsZ2RV0GwPBfEo Jw2OrBGYQib0UkTqoQ9L4BfXm+xYuqftQWC7e9a4Hke+hVGc0bTILBXKj24rmvnhQKLv P07j7Gr4HoPt0SprfMqNIril2lYnzPYkMhTIV6uWb67or7ZS4cl+W3pGlvuKKaICnToj mcVQ==
MIME-Version: 1.0
X-Received: by 10.42.114.130 with SMTP id g2mr5035601icq.46.1409552954507; Sun, 31 Aug 2014 23:29:14 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Sun, 31 Aug 2014 23:29:14 -0700 (PDT)
In-Reply-To: <5402B137.9070809@xiph.org>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com> <5402B137.9070809@xiph.org>
Date: Sun, 31 Aug 2014 23:29:14 -0700
X-Google-Sender-Auth: hfj-d86CxI-InRtkaLRMw7AB7-k
Message-ID: <CAMdZqKFFKf-vWYfQHzkbyr5H24UKE0e=D84ykc_u0K1a+Ep4HA@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: "codec@ietf.org" <codec@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/d0cRw2_r5HCHGhNOg05kRhhfpQo
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 06:29:17 -0000

Timothy B. Terriberry wrote:
> There are two possibilities:
>
> 1) A proposal for adding binary metadata breaks already-encoded files, in
> which case I don't think we should do it, considering people have been
> producing those files for over two years now under the expectation that they
> would continue to work, or
>
> 2) A proposal for adding binary metadata does not break already-encoded
> files, in which case we have exactly the future extension mechanism you want
> (emphasis on "future").


None of my proposals should break already-encoded files, so that
should not be an issue.  I think that the only potential issue is that
insufficient guidance in the Ogg Opus draft may lead to newly encoded
files being handled poorly by older tools that are not aware of later
extensions.  It would be best for this document to provide additional
guidance even if details such as anything specific to attached
pictures is specified later in another document.

For proposal (1) (tags named with an initial "@" are binary rather
than UTF-8): even if no tags are specified in the document, the
document should state that values of tags whose name begins with "@"
need not conform to UTF-8, so that binary tags can be defined later
without having conforming tools reject them as invalid or treating
such tags poorly.  For the record, Firefox and Chrome do not seem to
have any issue playing files with such tags.  Only tools that try to
validate the UTF-8 or that assume that all tags are UTF-8 text should
be impacted, and if they do things like display or allow editing of
arbitrary tags they may want to provide a different way of doing that
for binary tags.  Tools are likely to already provide different
display or editing mechanisms for certain tags such as
METADATA_BLOCK_PICTURE, but currently the only way they can do that is
to check for specific tag names.  A naming convention allows tools to
provide a somewhat more appropriate display and editing capability
even for unknown future tags if they so choose.

For proposal (2) (new OpusTags section for binary blocks, separate
from comments): even if the format of pictures and any other binary
blocks are defined later in another document, this document should
provide guidance for tools that wish to modify tags in an existing
file or provide padding for other tools to do so without re-writing
the whole file.  Currently no such guidance is provided, which could
lead to interoperability failure between some tools which write files
and other tools that modify existing files, if they have different
assumptions about the data in the OpusTags packet following the
comment table.  For example without any guidance different tools
modifying tags in the file might assume that additional data in the
packet should be retained, or that it may be overwritten with the
unused portion left as-is, or may be overwritten with the unused
portion zero'd.  This makes it difficult to ensure that any extension
to this packet will be handled reasonably by any conforming tool.

For proposal (3) (use a different multiplexed stream): it might be
nice if the document had at least a SHOULD-level suggestion that
playback of an Ogg Opus stream not be impacted by the presence of
unrecognized multiplexed streams.

 - Mark