From nobody Mon Sep 1 04:15:52 2014 Return-Path: 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 74D001A038E for ; Mon, 1 Sep 2014 04:15: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 PVC6oBynctFe for ; Mon, 1 Sep 2014 04:15:45 -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 EAC971A0384 for ; Mon, 1 Sep 2014 04:15:44 -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; 01 Sep 2014 20:45:43 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 98E2010003E for ; Mon, 1 Sep 2014 20:45: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 idB2XoV2ezQH for ; Mon, 1 Sep 2014 20:45:40 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 689CBFF8AF for ; Mon, 1 Sep 2014 20:45:40 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 5418580470; Mon, 1 Sep 2014 20:45:40 +0930 (CST) Date: Mon, 1 Sep 2014 20:45:40 +0930 From: Ron To: codec@ietf.org Message-ID: <20140901111540.GK326@hex.shelbyville.oz> References: <53FBBCA1.8060708@xiph.org> <20140830072745.GF326@hex.shelbyville.oz> <5402B137.9070809@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/UMq2Kil1mt9IqdH7yKd3y1R7Yd4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 11:15:48 -0000 On Sun, Aug 31, 2014 at 11:29:14PM -0700, Mark Harris wrote: > 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. As a general rule I think we should be wary of carving speculative things in stone here. If there is something you can see in the existing document that might unnecessarily make something impossible later, then we should look at that - but I don't think we should be staking claims on things we might never need or use. That just increases the risk of making some fatal mistake we'll regret later. > 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. I think we're 20 years too late to be reserving a single character in a tag name with the intent of changing the rules for its content. And perversely, the more 'improbable' the character you pick for this seems, the more probable it becomes that someone else also picked it for precisely that characteristic too. If this does turn out to be the optimal solution, then it needs to be done with a much longer prefix, that has a much better chance of actually being unique. In which case, we don't need to reserve it now, since if it won't still be unique by the time someone has more formally proposed a complete solution to this, then it was also a bad choice and something different should be picked. But given the other problems with this, which Tim already pointed out some of, I suspect one of the alternative solutions is most likely to trump this one once all things are considered. In which case, we'd have reserved something uselessly, which might come back to bite us later with unintended consequences. Either way, I don't think we need to rule this option out now, but we also don't need to preemptively reserve things that its final form may or may not use. > 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. I think this has much the same problem as above. It we try to preemptively reserve or define something now, that might actually backfire and *prevent* us from implementing what could otherwise turn out to be the optimal solution to this later. It's too late to make or change any assumptions that people are already making about how to handle these sections based on the guidance for vorbis comments, and if you're worried about the overhead of base64 encoding an image, then the idea of having "padding" the size of the entire image should be horrifying. Much like tags in TIFF or other similar formats, if you can't recognise them, you can't possibly safely modify or copy them. Your only choice is to not touch that space at all, or discard anything you don't understand how to handle. There are far too many perfectly reasonable ways to handle modifying tags, and it's a fair bet that most of them are already implemented by some software or another. Fortunately we don't really have to care about that, since none of them effect the ability to decode the audio stream. If someone chooses to edit them, with a particular tool of their choice, then they'll get what they chose to have, which hopefully they chose because it's pretty close to what they wanted. I can't see how we could possibly tell existing implementations that people have been using for years "no no, you're doing it wrong" with a straight face. If we can't think of a way to retrofit this that has a reasonable prospect of compatibility with existing tools, without mandating new things in this spec, then I think we'd have rule this option out. Which is not to say out that we necessarily couldn't find a way to make this work. Just that if it requires us to define things in *this* spec now, else it wouldn't work - then it probably isn't going to be very workable anyway. Not compared to the other alternatives. > 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. But to end on a happy note, this one however, we already have :) 'When Opus is concurrently multiplexed with other streams in an Ogg container, one SHOULD use one of the "audio/ogg", "video/ogg", or "application/ogg" mime-types, as defined in [RFC5334].' Which gives us the best of both worlds. People can create an "Ogg Opus file", which is guaranteed to contain only sequential streams in a form that even the most trivial decoder can handle, or they can create an 'x/ogg' file (or stream), which requires a more capable decoder, and for which RFC 5334 already says: "Furthermore, it is RECOMMENDED that implementations that identify a logical bitstream that they cannot decode SHOULD ignore it, while continuing to decode the ones they can. Such precaution ensures backward and forward compatibility with existing and future data." Which is at least partly why I think this is the early favourite horse in this race. The foundations for it to work were already laid long ago. We might be able to think of something clever that makes one of the other option be a better choice, but if we can't, this one is the safety net that means you can take the Ogg Opus stream mapping already defined in this draft, and combine it with our yet to be defined holo-pony mapping once that's defined and lots of existing tools will only need to add support for the latter to make the combination of them work, and will correctly play the Opus stream until they do. Any other option needs to at least get to that baseline of painless to really be thought of as a serious alternative contender. Ron From nobody Fri Sep 5 15:52:48 2014 Return-Path: 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 C7E2E1A03CB; Fri, 5 Sep 2014 15:52: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] 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 Q1rY7BxaL8x6; Fri, 5 Sep 2014 15:52:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A7C1A03BB; Fri, 5 Sep 2014 15:52:43 -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.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905225243.4991.74518.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 15:52:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/codec/rxBYCQFHH4JT_uKBa7_1ufSbRsc Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-update-01.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:52:45 -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 : Updates to the Opus Audio Codec Authors : Jean-Marc Valin Koen Vos Filename : draft-ietf-codec-opus-update-01.txt Pages : 7 Date : 2014-09-05 Abstract: This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716 [RFC6716]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-opus-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-codec-opus-update-01 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 Sun Sep 7 09:31:36 2014 Return-Path: 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 F41601A0667 for ; Sun, 7 Sep 2014 09:31: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 P4XEjOApsrpQ for ; Sun, 7 Sep 2014 09:31:31 -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 92E241A066D for ; Sun, 7 Sep 2014 09:31:31 -0700 (PDT) Received: from ppp118-210-235-204.lns20.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([118.210.235.204]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Sep 2014 02:01:30 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id C806FFFD70 for ; Mon, 8 Sep 2014 02:01:27 +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 pamRkyDL-wOe for ; Mon, 8 Sep 2014 02:01:27 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 0C640FFD63 for ; Mon, 8 Sep 2014 02:01:27 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EB81B80470; Mon, 8 Sep 2014 02:01:26 +0930 (CST) Date: Mon, 8 Sep 2014 02:01:26 +0930 From: Ron To: codec@ietf.org Message-ID: <20140907163126.GZ326@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> <20140827212655.GW326@hex.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140827212655.GW326@hex.shelbyville.oz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/UWbprv56qgRUMEfDSItueypYKKY 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 16:31:34 -0000 On Thu, Aug 28, 2014 at 06:56:55AM +0930, Ron wrote: > 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. So I believe this is now the last outstanding question from the last call comments that we still have open. There were some concerns raised about this wording, but my questions about exactly what the problem Ian had with it was have so far gone unanswered, which makes it a bit tricky to try to address whatever they really were, and I haven't seen a proposed alternative wording that covers the problem Ralph and I saw with the initial proposed edit leaving it without a rationale (which this version tried to fix). So if someone still thinks this says something that it shouldn't, or isn't properly clear about what it does say, could you please give us a sufficient explanation of that so we can understand and fix the problem, or propose an alternative wording that you think does which we can discuss. Otherwise, this is so far the closest to what I think was originally intended that we have on the table to accept. If we get this one out of the way now, I think we're nearly done. Thanks, Ron From nobody Sun Sep 7 13:34:01 2014 Return-Path: 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 1B7701A0701 for ; Sun, 7 Sep 2014 13:34:00 -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 p5Ri0ZJRYqII for ; Sun, 7 Sep 2014 13:33:57 -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 D7C2A1A070A for ; Sun, 7 Sep 2014 13:33:56 -0700 (PDT) Received: from ppp118-210-235-204.lns20.adl6.internode.on.net (HELO mailservice.shelbyville.oz) ([118.210.235.204]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Sep 2014 06:03:49 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 69C36FFD70 for ; Mon, 8 Sep 2014 06:03: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 t8IHGK1EoSVt for ; Mon, 8 Sep 2014 06:03:45 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 69AF2FF88C for ; Mon, 8 Sep 2014 06:03:45 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 53F6A80470; Mon, 8 Sep 2014 06:03:45 +0930 (CST) Date: Mon, 8 Sep 2014 06:03:45 +0930 From: Ron To: codec@ietf.org Message-ID: <20140907203345.GA326@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> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140907180607.290f13ba@crunchbang> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/VHZ8DcjzZmNZAmb5NA5NCr6xVZQ 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 20:34:00 -0000 On Sun, Sep 07, 2014 at 06:06:07PM +0100, Ian Nartowicz wrote: > On Mon, 8 Sep 2014 02:01:26 +0930 > Ron wrote: > > >On Thu, Aug 28, 2014 at 06:56:55AM +0930, Ron wrote: > >> 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. > > > >So I believe this is now the last outstanding question from the last > >call comments that we still have open. > > > >There were some concerns raised about this wording, but my questions > >about exactly what the problem Ian had with it was have so far gone > >unanswered, which makes it a bit tricky to try to address whatever > >they really were, and I haven't seen a proposed alternative wording > >that covers the problem Ralph and I saw with the initial proposed > >edit leaving it without a rationale (which this version tried to fix). > > > >So if someone still thinks this says something that it shouldn't, or > >isn't properly clear about what it does say, could you please give > >us a sufficient explanation of that so we can understand and fix the > >problem, or propose an alternative wording that you think does which > >we can discuss. > > > >Otherwise, this is so far the closest to what I think was originally > >intended that we have on the table to accept. > > > >If we get this one out of the way now, I think we're nearly done. > > > > Thanks, > > Ron > > Sorry, I didn't realise there were outstanding questions. Perhaps if I give a > concrete example, it will show where I'm coming from: > > In this context, a common use will be to encode a given (probably lossless) > source into Opus. The requirement here is to (optionally) be able to play back > the Opus at the same level as the original source, even if there are R128 gain > tags present. I'm not sure what the distinction you're making about 'level' here is or why it's important for a general purpose player? [ed: Ian, you might want to skip commenting on this first lot unless there is something you *really* disagree with. I've left it here because it is important that we are on the same page about this, but if you make it past this to the bottom, I *think* I start to see what it is that you're *actually* concerned about ... ] The R128 tags are indeed a mechanism that people can use to normalise all of their recordings to some consistent level, so they'll all play back at about the same volume for a given setting that they've dialled the volume knob on their player to. They are completely optional, and we don't mandate that a player must support them (or use them even if it does), but enough people have said they wanted that for us to define a standard way to do it if you do. My understanding is that having both ALBUM_GAIN and TRACK_GAIN meets the varied requirements that people wanted for that function. But the output_gain has no such constraint or meaning attached to it. It's mandatory to apply precisely because it is part of what defines the "level of the original source" as defined by whoever mastered that recording. The *only* reason it exists is where there is no "lossless source", since it's quite conceivable that people will make devices which record directly to Opus, and no "lossless master" will ever exist. We expect most people will never need to use it, but for the case where you've accidentally recorded something at a ridiculous level (whether that is loud or quiet), this gives you a way to losslessly 'fix' that, without having to destructively do a lossy to lossy re-encoding - which would otherwise be your only option. We don't say anything about what 'level' you should fix this to if you do that. It's entirely at the discretion of whoever goes "damn, I totally screwed this recording up", and whatever they decide would be a less screwed up level. The "playback level" of that file, like any other unnormalised file, is going to be entirely under the control of the user adjusting their volume control. This just lets the person who mastered it get a file that's way out there, back in the ballpark. There should be no reason for an 'end user' to ever need or want to "turn that off" - since at best it will do almost nothing for them, and at worst it could do Something Terrible. If they want a "different" level, they turn their volume knob. If they want a "standard" level, they put the file through a tool that adds R128 tags. This isn't a "normalisation mechanism" so much as a "tool of last resort" for salvaging a botched recording that there is no other good way to save. If people can't rely on that tool working, then it's useless to them and they'll just destructively re-encode in the cases where they really would have needed it and could have used it. Does that make sense? Because if it doesn't, we need to talk about that more or explain it better in the draft - and if you think it means something different to that, then we're going to have a really hard time converging on understanding for anything else here. > This requirement will be met, one way or another for good or > for bad, my me and probably by other authors, but I'd prefer > to do it in a way that complies with the specification. Sorry if I'm appearing to be thick here, but I still don't understand what "This requirement" is? You've told me "what" you want, but not *why* that is actually needed or can't already be done with what we have. Your example above seems to hinge on there being some prior lossless source, but that's not the case where the output_gain is useful. If you have other lossless source, then generally you can simply just re-encode the file from scratch if you somehow botched the gain on the transcode, you don't need the output_gain knob to fix that. > Clearly this is not possible in all cases because there is no explicit > identification of the original source level or the total amount of gain > attributable to the R128 tags, but so long as the spec has enough flexibility > to allow a use case then I can work with it. Applying normative language to > placing one of the R128 values into the output gain and then requiring that it > be applied in all cases did not seen sufficiently flexible. Hmm. So your concern is actually with the part that suggests people MAY wish to put the base normalisation in output_gain and set R128=0? Not actually with the fact we say you MUST always apply output_gain? It's not a normative requirement that they do it that way (as opposed to instead setting output_gain=0 and R128=X) -- it was really just a clarification that the R128 tags are Optional, and that if you *do* want the "original level" to be normalised, then using output_gain would guarantee that "robustly". But yes, I think I can see how that advice may steer people toward creating files where a lossless master existed, and wasn't originally normalised but the Opus encoding is, with no certain way for people to be able to reliably "unnormalise it" again. You might for some files be able to deduce that moving the output_gain value to an R128 tag and setting output_gain=0 *could* do that, but there is no way to be certain that's true for every file (purely because the file might be of the sort I described above, but rather than pick some random level that makes it "not ridiculous" anymore, they did actually normalise it to R128 when they fixed it, and the original might still be 'dangerously' useless - though you could again apply some heuristic based on the amount of gain adjustment seen ...) That does seem to be an unintended consequence of the "For example" advice. Which although not normative in itself, might not actually be the preferred default for people to use. > The original > language of my patch left it entirely up to the encoder and subsequent tools > where to place the R128 gain values, allowing for them to be placed entirely in > the tags and therefore identified. Or not, but that's at least under the > control of the user. My main problem with that one was it removed all the context explaining when and why people might use this and left it too vague for there to be some reasonable consistency among how people interpret it (since if everyone does something different, we'll just have a complete mess, worse that if we allowed no gain tags at all). But yes, the intent was certainly not for there to be information loss somewhere as a result of doing this. So in that light, I think this part should stand: > "Implementations of this specification MUST respect the 'output gain' > field, but MAY NOT respect the comments. Because it's a simple statement that reaffirms tags are always optional and the header gain is an intrinsic part of the "original recording". But this part: > 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." Possibly needs to give some slightly different advice, at least for the case where R128 normalisation is something that someone retrofits to a recording that was previously mastered to some acceptable level, to avoid actually losing useful information about the original in that case. Does that seem like it would cover what you're worried about? Do you have some proposed language for what you'd like us to recommend people do if they want to retrofit R128 normalisation to recordings? Cheers, Ron From nobody Mon Sep 8 07:00:38 2014 Return-Path: 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 DA18A1A87E4 for ; Mon, 8 Sep 2014 07:00:35 -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_40=-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 Ac49YH_clyIl for ; Mon, 8 Sep 2014 07:00: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 5C7D11A87E7 for ; Mon, 8 Sep 2014 07:00:31 -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 6A59DF208D for ; Mon, 8 Sep 2014 07:00:30 -0700 (PDT) Message-ID: <540DB67E.8030404@xiph.org> Date: Mon, 08 Sep 2014 07:00:30 -0700 From: "Timothy B. Terriberry" 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> <53FE0054.5080207@thaumas.net> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> In-Reply-To: <20140907163126.GZ326@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/4vP8D7dSa8k9pXVEUkwnF__9-kI 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 14:00:36 -0000 Ron wrote: > So I believe this is now the last outstanding question from the last > call comments that we still have open. I think there were a few more non-normative "shoulds" that needed to be cleaned up. Did you and Ralph have some suggestions for those? I didn't see any on the list. From nobody Mon Sep 8 08:46:08 2014 Return-Path: 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 C2FE01A8877 for ; Mon, 8 Sep 2014 08:46:06 -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 P4_s6ijZNy6a for ; Mon, 8 Sep 2014 08:46:05 -0700 (PDT) Received: from know-smtprelay-omc-7.server.virginmedia.net (know-smtprelay-omc-7.server.virginmedia.net [80.0.253.71]) by ietfa.amsl.com (Postfix) with ESMTP id 14C001A8869 for ; Mon, 8 Sep 2014 08:46:04 -0700 (PDT) Received: from crunchbang ([81.103.170.84]) by know-smtprelay-7-imp with bizsmtp id ofm31o00o1pcAUZ01fm33w; Mon, 08 Sep 2014 16:46:04 +0100 X-Originating-IP: [81.103.170.84] X-Spam: 0 X-Authority: v=2.1 cv=cpwVkjIi 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=k5tU_nt-SUti6MfviC0A:9 a=FWZkCIvD01mszB-3:21 a=Vc-Cv0Jhs0K3inSM:21 a=CjuIK1q_8ugA:10 Date: Mon, 8 Sep 2014 16:46:02 +0100 From: Ian Nartowicz To: codec@ietf.org Message-ID: <20140908164602.2320a8c1@crunchbang> In-Reply-To: <20140907203345.GA326@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> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> <20140907203345.GA326@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/ceRi5LzQ-UpVvT0ObwqE-szoH78 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:46:06 -0000 >But this part: > >> 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." > >Possibly needs to give some slightly different advice, at least for the >case where R128 normalisation is something that someone retrofits to >a recording that was previously mastered to some acceptable level, to >avoid actually losing useful information about the original in that case. > >Does that seem like it would cover what you're worried about? > >Do you have some proposed language for what you'd like us to recommend >people do if they want to retrofit R128 normalisation to recordings? I hadn't considered language that goes any further than leaving the issue unspecified. Actively encouraging encoders not to put R128 gains into the output gain field seems to go directly against a key design goal for Opus. Although I'd be happy to see this particular case recognised, do we want to to second-guessing users and filling the spec with exceptions? In an ideal world I'd still like to see a solution that produces normalised output by default for all players, with sufficient information for more advanced players to "de-normalise" out a specific R128 gain when needed. --ian From nobody Mon Sep 8 09:44:49 2014 Return-Path: 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 AAC221A88B1 for ; Mon, 8 Sep 2014 09:44: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 1t8EMTab0pTG for ; Mon, 8 Sep 2014 09:44:46 -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 109CC1A88A9 for ; Mon, 8 Sep 2014 09:44:45 -0700 (PDT) Received: from ppp14-2-41-157.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.41.157]) by ipmail05.adl6.internode.on.net with ESMTP; 09 Sep 2014 02:14:44 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 669D2FFDE1 for ; Tue, 9 Sep 2014 02:14: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 O87lwfp8p2Y2 for ; Tue, 9 Sep 2014 02:14:40 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id CCDC6FFD8F for ; Tue, 9 Sep 2014 02:14:40 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id BD49C80470; Tue, 9 Sep 2014 02:14:40 +0930 (CST) Date: Tue, 9 Sep 2014 02:14:40 +0930 From: Ron To: codec@ietf.org Message-ID: <20140908164440.GA32116@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> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <540DB67E.8030404@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540DB67E.8030404@xiph.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/qLmxTWCqWBUEqrqYU6AWZ75hcIc 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:44:48 -0000 On Mon, Sep 08, 2014 at 07:00:30AM -0700, Timothy B. Terriberry wrote: > Ron wrote: > >So I believe this is now the last outstanding question from the last > >call comments that we still have open. > > I think there were a few more non-normative "shoulds" that needed to be > cleaned up. Did you and Ralph have some suggestions for those? I didn't see > any on the list. Ralph went through those and pushed changes to replace the stray lowercase shoulds with alternative language, and those looked ok to me and shouldn't be controversial. Several of them read better without the shoulds anyway and I don't think any of them change the intended meaning where they happened. There may still be a couple of MAYs that we're using in the natural language sense which might not quite fit the BCP14 sense of an "optional item", but that's possibly a question for better language lawyers than me to give an opinion on. That said, they indeed haven't been discussed or vetted here yet, and I agree they should be. Given the number of "minor editorial changes" that have occurred in response to various comments, I guess we should probably wrap up whatever language is needed to meet Ian's concern then push out another draft that people can review in its entirety? I'd certainly welcome people reviewing those things in git, but it might be a bit much to expect them to do so that way. If there's a better plan than that, I'm open to it though. Ron From nobody Mon Sep 8 10:11:47 2014 Return-Path: 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 329801A893F for ; Mon, 8 Sep 2014 10:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 8A7OQrnQs268 for ; Mon, 8 Sep 2014 10:11:43 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44ED61A88FF for ; Mon, 8 Sep 2014 10:09:50 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id rd18so1217242iec.39 for ; Mon, 08 Sep 2014 10:09: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=ghdsuZbsgg1sd6pKq6XwPONiRx5wbiyYaKXhEg2skrQ=; b=U4z19rPnlykMVqoWv8dDhXrHSAmQ09BNBzgoBmZGzgsoLSZWmoPawPHHY4ynOTMV5p D1q8G+W+uITHd+XQb77T1er0O7KVIqJvxXSI5aKVkTUL4gd9iKE8Q7L3TX1GFvxo1+d7 A8Z7m76BOO33AKXs2ahjgxtG08VAEGKk5SRrpj7SQgzrsvSBRK3O4NwD9I5NaJI+G6PU CdAPRlNzJeL3TkPYcaIxX/K4NPUkkec2efbMAAfl3lgRn/PnDIq8MbTvKYuIlXpoIWYP fd5KCD1tQkEtRws2/hDyJUL4/jPQzZDE9Afix6/feU4EQwhVtx6rIWdJ1MLp8cOWoCDV /OzQ== MIME-Version: 1.0 X-Received: by 10.50.33.73 with SMTP id p9mr443735igi.24.1410196189646; Mon, 08 Sep 2014 10:09:49 -0700 (PDT) Sender: markh.sj@gmail.com Received: by 10.107.1.81 with HTTP; Mon, 8 Sep 2014 10:09:49 -0700 (PDT) Date: Mon, 8 Sep 2014 10:09:49 -0700 X-Google-Sender-Auth: Dcu7lcyJ9l-j5oNixT7oOG3oxbU Message-ID: From: Mark Harris To: "codec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/codec/7R8XUfJQY39XKJ1UU6kFM-VAwuY Subject: [codec] draft-ietf-codec-oggopus: R128_TRACK_GAIN units X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 17:11:45 -0000 The tags R128_TRACK_GAIN and R128_ALBUM_GAIN are specified by draft-ietf-codec-oggopus-04 to contain a level adjustment as a fixed point Q7.8 value; i.e. in the 1/256 LU units that are used in the output gain field of the Ogg Opus header. Is it expected that these units would be adopted by other codecs? Because tags are most often used for codec-independent metadata such as TITLE and ARTIST, code to handle them is often shared between formats and they may be copied when transcoding or remuxing. I am concerned that if Ogg Opus uses 1/256 LU units, and another format or codec uses the much more obvious LU (dB) units, then someone may be in for a jolt (or almost complete silence) when their player interprets a value intended to be in 1/256 LU units as being in standard LU units. Because there is an existing nearly universally used standard unit, it would seem to be much better to use that unit in tag values, especially if the value is a string with no units, in order to minimize the chance that the wrong units will be used and reduce confusion for people who are viewing or editing the text tags or converting or comparing with standard ReplayGain tags. It should not be necessary to be an expert on the Ogg Opus specification in order to be able to interpret the value of these tags, since there is no reason for such information to be codec-specific or container-specific. A related issue is the reference level. The EBU R128 reference level is -23 LUFS. Prior to EBU R128 a -18 LUFS reference level was commonly used, and there are other reference levels used in some specific contexts. Because the tag is used to normalize loudness of audio from different sources, possibly using different codecs, containers, and reference level standards, it would seem more sensible to put the actual loudness measurement in the tag, and let the player adjust it as needed to match the target loudness that it is using for all audio sources. In fact EBU R128 specifically recommends that "Loudness Metadata shall correctly indicate the actual Programme Loudness", not a gain adjustment. In light of these issues, would it not be better to record a TRACK_LOUDNESS tag in LUFS and an ALBUM_LOUDNESS tag (which would have the same value for all tracks that are part of the album) also in LUFS? In order to allow a player to adjust the loudness to any desired target loudness and dynamic range, ideally the loudness range and maximum true peak level would also optionally be available in a well-defined tag in order to allow the player to insert dynamic range compression if necessary. All of these tags should be codec-independent. As specified by EBU R128, loudness, loudness range, and true peak measurements should be made according to ITU-R BS.1770 and EBU Tech 3341. - Mark From nobody Mon Sep 8 10:57:52 2014 Return-Path: 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 0B78A1A0145 for ; Mon, 8 Sep 2014 10:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 5xBySs-T1eJG for ; Mon, 8 Sep 2014 10:57:50 -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 4B94C1A0146 for ; Mon, 8 Sep 2014 10:57:46 -0700 (PDT) Received: from ppp14-2-41-157.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.41.157]) by ipmail05.adl6.internode.on.net with ESMTP; 09 Sep 2014 03:27:44 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 3B37AFFDE1 for ; Tue, 9 Sep 2014 03:27:43 +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 0HWQ-tugQ1DT for ; Tue, 9 Sep 2014 03:27:41 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 826DEFFD5D for ; Tue, 9 Sep 2014 03:27:41 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 70DD180470; Tue, 9 Sep 2014 03:27:41 +0930 (CST) Date: Tue, 9 Sep 2014 03:27:41 +0930 From: Ron To: codec@ietf.org Message-ID: <20140908175741.GB32116@hex.shelbyville.oz> References: <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE0054.5080207@thaumas.net> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> <20140907203345.GA326@hex.shelbyville.oz> <20140908164602.2320a8c1@crunchbang> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908164602.2320a8c1@crunchbang> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/7lN8OYm1Yb7hv4lLdEq6cTN2PrA 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 17:57:52 -0000 On Mon, Sep 08, 2014 at 04:46:02PM +0100, Ian Nartowicz wrote: > > >But this part: > > > >> 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." > > > >Possibly needs to give some slightly different advice, at least for the > >case where R128 normalisation is something that someone retrofits to > >a recording that was previously mastered to some acceptable level, to > >avoid actually losing useful information about the original in that case. > > > >Does that seem like it would cover what you're worried about? > > > >Do you have some proposed language for what you'd like us to recommend > >people do if they want to retrofit R128 normalisation to recordings? > > I hadn't considered language that goes any further than leaving the issue > unspecified. I don't think we should be leaving it entirely unspecified, that just guarantees that nobody will get what they wanted from adding the R128 tags in the first place, since everybody will do something different and in ways that subtly conflict with each other or produce surprising behaviour in some players. If we were to go that way, we should just say the header gain is strictly mandatory and simply remove all reference to any sort of "normalisation" tags. But some people wanted us to specify those tags, precisely to end the random state of madness that currently exists with them elsewhere. So if we do that, we should specify a way that people agree works, and doesn't have obvious problems. > Actively encouraging encoders not to put R128 gains into the > output gain field seems to go directly against a key design goal for Opus. No, I don't think that's the case. I explained what the header gain field was designed for, and it has nothing to do with "normalisation", it's purely to allow *arbitrary* lossless correction where the only other alternative might be a destructive re-encoding. The only reason you'd really want to put an R128 correction in there is if you really *always* wanted that to be the "original level" of the file. In a case where that was simply an advisory thing, and preserving the "original level" of some previous master was also important, then putting that into the advisory R128 tags seems perfectly correct to me. I don't really see how that has anything to do with the "design goals" of Opus, let alone be in conflict with them. Unless you're going to tell me that I'm still completely failing to understand what your actual concern is, the only problem I'm seeing is that we've accidentally entangled an example of how the mandatory and optional gains interact, in a way that might lead some people to encode R128 normalisation suboptimally for some cases. Which is indeed unintentional, and if so we should fix that. Probably by splitting the example of how gains interact from the advice we give about how optional R128 normalisation should be indicated. > Although I'd be happy to see this particular case recognised, > do we want to to second-guessing users and filling the spec > with exceptions? I don't see where we'd be second guessing anybody, or needing to make any exceptions at all to clarify this? The basic rules are simple. - Mandatory gain is mandatory. It's in the header. - Optional gain is optional. It's in the comment tags. - Optional gain is always in addition to mandatory gain. Where we might have made a bit of a mess that needs to be cleaned up further, is that previously people thought we would only need one R128 gain tag for TRACK_GAIN, and that "for simplicity" if people wanted ALBUM_GAIN, they would either set that level while encoding, or tweak the header gain to retrofit it. Ultimately, other people made a convincing argument for also having a separate R128_ALBUM_GAIN tag. Which really does free up the header gain to again *only* be used for its original purpose of "arbitrary lossless correction as a tool of last resort". But it appears some of the language from prior to that hasn't yet completely been untangled, and we're hinting to people that they might prefer to use the mandatory gain, because it is guaranteed to be applied and is therefore "more robust", but we're using R128 gain as an example for that -- when the people who Really Care about R128 normalisation actually do want that to remain optional. It was never the intent here that R128 normalisation should be in any way mandatory. The example was just intended to show clearly how mandatory and optional gain are combined. What I'm getting from your comments is we need an example that looks less like advice for how to add R128 normalisation, and perhaps some better advice for what the best way to add that really is - something more like "If it's optional, *always* prefer to put it in the tags, not the header gain". Am I somewhere close to the mark there? I *thought* I understood what you wanted before the first change, but then we accidentally made you sad trying to clarify that for other concerns too. > In an ideal world I'd still like to see a solution that produces normalised > output by default for all players, with sufficient information for more > advanced players to "de-normalise" out a specific R128 gain when needed. Well that should be 'easy', you just need to convince the player authors to support the R128 tags, and turn them on by default (assuming that doesn't cause their own users to revolt). Our job here is just to be clear about how you can encode a file to make that possible, when it is what you desire for that file. We need the mandatory gain for lossless correction, but that's an entirely separate issue to providing good advice for how to make the best use of the optional gain tags for normalisation. Only specialised editors should be "ignoring" the mandatory gain, but it seems quite reasonable for an ordinary end user player to be able to toggle R128 gain at the user's preference. That's always been the intent. If that's not what the words say then we should fix the words so they do. Ron From nobody Mon Sep 8 11:19:41 2014 Return-Path: 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 7502F1A026F for ; Mon, 8 Sep 2014 11:19:39 -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 dldm2GWEB-Qf for ; Mon, 8 Sep 2014 11:19:37 -0700 (PDT) Received: from know-smtprelay-omc-7.server.virginmedia.net (know-smtprelay-omc-7.server.virginmedia.net [80.0.253.71]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4B1A0263 for ; Mon, 8 Sep 2014 11:19:35 -0700 (PDT) Received: from crunchbang ([81.103.170.84]) by know-smtprelay-7-imp with bizsmtp id oiKZ1o02H1pcAUZ01iKapQ; Mon, 08 Sep 2014 19:19:34 +0100 X-Originating-IP: [81.103.170.84] X-Spam: 0 X-Authority: v=2.1 cv=cpwVkjIi 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=xNf9USuDAAAA:8 a=LQ8oMDJ46r94RIo2s-YA:9 a=WLhkYPM7sdGlEcyB:21 a=1QFK3WzY8KKmoYfM:21 a=CjuIK1q_8ugA:10 a=YPTUPuSgPjgA:10 Date: Mon, 8 Sep 2014 19:19:32 +0100 From: Ian Nartowicz To: codec@ietf.org Message-ID: <20140908191932.14706180@crunchbang> In-Reply-To: <20140908175741.GB32116@hex.shelbyville.oz> References: <53ECF0E0.9060308@xiph.org> <20140816040140.GA31682@hex.shelbyville.oz> <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE0054.5080207@thaumas.net> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> <20140907203345.GA326@hex.shelbyville.oz> <20140908164602.2320a8c1@crunchbang> <20140908175741.GB32116@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/0LQuti0eeNtbLxY03sPCa6z-6Q4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 18:19:39 -0000 On Tue, 9 Sep 2014 03:27:41 +0930 Ron wrote: >On Mon, Sep 08, 2014 at 04:46:02PM +0100, Ian Nartowicz wrote: >> >> >But this part: >> > >> >> 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." >> > >> >Possibly needs to give some slightly different advice, at least for the >> >case where R128 normalisation is something that someone retrofits to >> >a recording that was previously mastered to some acceptable level, to >> >avoid actually losing useful information about the original in that case. >> > >> >Does that seem like it would cover what you're worried about? >> > >> >Do you have some proposed language for what you'd like us to recommend >> >people do if they want to retrofit R128 normalisation to recordings? >> >> I hadn't considered language that goes any further than leaving the issue >> unspecified. > >I don't think we should be leaving it entirely unspecified, that just >guarantees that nobody will get what they wanted from adding the R128 >tags in the first place, since everybody will do something different >and in ways that subtly conflict with each other or produce surprising >behaviour in some players. > >If we were to go that way, we should just say the header gain is >strictly mandatory and simply remove all reference to any sort of >"normalisation" tags. But some people wanted us to specify those >tags, precisely to end the random state of madness that currently >exists with them elsewhere. So if we do that, we should specify >a way that people agree works, and doesn't have obvious problems. > > >> Actively encouraging encoders not to put R128 gains into the >> output gain field seems to go directly against a key design goal for Opus. > >No, I don't think that's the case. I explained what the header gain >field was designed for, and it has nothing to do with "normalisation", >it's purely to allow *arbitrary* lossless correction where the only >other alternative might be a destructive re-encoding. > >The only reason you'd really want to put an R128 correction in there is >if you really *always* wanted that to be the "original level" of the >file. In a case where that was simply an advisory thing, and preserving >the "original level" of some previous master was also important, then >putting that into the advisory R128 tags seems perfectly correct to me. > >I don't really see how that has anything to do with the "design goals" >of Opus, let alone be in conflict with them. > > >Unless you're going to tell me that I'm still completely failing to >understand what your actual concern is, the only problem I'm seeing >is that we've accidentally entangled an example of how the mandatory >and optional gains interact, in a way that might lead some people to >encode R128 normalisation suboptimally for some cases. > >Which is indeed unintentional, and if so we should fix that. > >Probably by splitting the example of how gains interact from the >advice we give about how optional R128 normalisation should be >indicated. > > >> Although I'd be happy to see this particular case recognised, >> do we want to to second-guessing users and filling the spec >> with exceptions? > >I don't see where we'd be second guessing anybody, or needing to >make any exceptions at all to clarify this? > >The basic rules are simple. > > - Mandatory gain is mandatory. It's in the header. > - Optional gain is optional. It's in the comment tags. > - Optional gain is always in addition to mandatory gain. > >Where we might have made a bit of a mess that needs to be cleaned >up further, is that previously people thought we would only need >one R128 gain tag for TRACK_GAIN, and that "for simplicity" if >people wanted ALBUM_GAIN, they would either set that level while >encoding, or tweak the header gain to retrofit it. > >Ultimately, other people made a convincing argument for also >having a separate R128_ALBUM_GAIN tag. Which really does free >up the header gain to again *only* be used for its original >purpose of "arbitrary lossless correction as a tool of last >resort". > >But it appears some of the language from prior to that hasn't >yet completely been untangled, and we're hinting to people that >they might prefer to use the mandatory gain, because it is >guaranteed to be applied and is therefore "more robust", but >we're using R128 gain as an example for that -- when the people >who Really Care about R128 normalisation actually do want that >to remain optional. > > >It was never the intent here that R128 normalisation should be >in any way mandatory. The example was just intended to show >clearly how mandatory and optional gain are combined. > >What I'm getting from your comments is we need an example that >looks less like advice for how to add R128 normalisation, and >perhaps some better advice for what the best way to add that >really is - something more like "If it's optional, *always* >prefer to put it in the tags, not the header gain". > > >Am I somewhere close to the mark there? I *thought* I understood >what you wanted before the first change, but then we accidentally >made you sad trying to clarify that for other concerns too. > > >> In an ideal world I'd still like to see a solution that produces normalised >> output by default for all players, with sufficient information for more >> advanced players to "de-normalise" out a specific R128 gain when needed. > >Well that should be 'easy', you just need to convince the player >authors to support the R128 tags, and turn them on by default >(assuming that doesn't cause their own users to revolt). > >Our job here is just to be clear about how you can encode a file >to make that possible, when it is what you desire for that file. > >We need the mandatory gain for lossless correction, but that's >an entirely separate issue to providing good advice for how to >make the best use of the optional gain tags for normalisation. > >Only specialised editors should be "ignoring" the mandatory gain, >but it seems quite reasonable for an ordinary end user player to >be able to toggle R128 gain at the user's preference. > >That's always been the intent. If that's not what the words say >then we should fix the words so they do. > I would be entirely happy if it was recommended that R128 gain values were stored in their tags and not normally in the output gain field, but I've felt resistance to that idea before. The spec itself advised the opposite and explained the reason: everyone will apply the output gain, not everyone will apply the tag gain. Do we agree about this? Might be best to wait for some other comments. --ian From nobody Mon Sep 8 12:43:28 2014 Return-Path: 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 4998A1A0362 for ; Mon, 8 Sep 2014 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-1.652, 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 XrizpHWPxVh1 for ; Mon, 8 Sep 2014 12:43:25 -0700 (PDT) Received: from mail.masque.com (mail.masque.com [173.8.226.74]) by ietfa.amsl.com (Postfix) with ESMTP id C7B381A035D for ; Mon, 8 Sep 2014 12:43:25 -0700 (PDT) Received: from [192.168.7.139] (unknown [192.168.1.241]) by mail.masque.com (Postfix) with ESMTP id 830A91602A6 for ; Mon, 8 Sep 2014 13:43:24 -0600 (MDT) Message-ID: <540E06DD.60600@masque.com> Date: Mon, 08 Sep 2014 13:43:25 -0600 From: John Ridges User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: codec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/codec/_aYEQCKFgr_aHTI_4U1FvkL4-w4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 19:43:27 -0000 On 9/8/2014 1:00 PM, codec-request@ietf.org wrote: > I would be entirely happy if it was recommended that R128 gain values were > stored in their tags and not normally in the output gain field, but I've felt > resistance to that idea before. The spec itself advised the opposite and > explained the reason: everyone will apply the output gain, not everyone will > apply the tag gain. > > Do we agree about this? Might be best to wait for some other comments. > > --ian It seems to me that the gain values are intended for two different audiences. The output gain should be something set by the audio producer, whereas the R128 gains are something usually set by the audio consumers (to normalize all the songs in a playlist to be the same loudness, for example). Naturally the output gain must be mandatory for a player, but I would vote that it makes sense that the R128 gains are optional, since only the consumer would really know why they are applying the R128 gains to begin with (and if it's a matter of an audio producer trying to get the same loudness for all the songs in his "album", and he can't fix the source material and re-encode it, then he should be using the output gain for this purpose). My two cents. John Ridges From nobody Mon Sep 8 13:11:12 2014 Return-Path: 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 D6DB41A02F2 for ; Mon, 8 Sep 2014 13:11:10 -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 L_sEF-CwP1F4 for ; Mon, 8 Sep 2014 13:11:07 -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 71F0D1A0322 for ; Mon, 8 Sep 2014 13:11:06 -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 7C07BF234B for ; Mon, 8 Sep 2014 13:11:05 -0700 (PDT) Message-ID: <540E0D59.50500@xiph.org> Date: Mon, 08 Sep 2014 13:11:05 -0700 From: "Timothy B. Terriberry" 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/codec/bMtUKzr9gD7zN5-7hCbmRSdq-dk Subject: Re: [codec] draft-ietf-codec-oggopus: R128_TRACK_GAIN units X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:11:11 -0000 As an individual... Mark Harris wrote: > output gain field of the Ogg Opus header. Is it expected that these > units would be adopted by other codecs? I can't speak for anyone else, but if _I_ were making a new codec, I wouldn't see a need to innovate here. This design has the lessons of doing this for 15+ years baked into it. > concerned that if Ogg Opus uses 1/256 LU units, and another format or > codec uses the much more obvious LU (dB) units, then someone may be in Then they should pick a different tag name. > Because there is an existing nearly universally used standard unit, it > would seem to be much better to use that unit in tag values, This was tried for ReplayGain tags. 1 dB units are far too coarse, and once you add a decimal point, people almost universally implement it incorrectly (due to various issues like atof and strtod having locale-dependent semantics, locale changes not being thread-safe in C, etc.). The choice here was a conscious one designed to avoid the failures of past mistakes. It's also got two years of deployment at this point, so there's now non-trivial costs in changing it. If we had a good reason, we could change it. But "reduced confusion" is not a good reason. Changing now will only increase confusion (another lesson I've learned from letting people talk me into such changes in the past): people will be required to support both formats forever, despite the fact that one would be "standard" and the other wouldn't be. > containers, and reference level standards, it would seem more sensible > to put the actual loudness measurement in the tag, and let the player > adjust it as needed to match the target loudness that it is using for In a system with infinite dynamic range, sure. In a system without that (like, say, the fixed-point decoder provided in the reference implementation), starting from a 0 LUFS reference means naive implementers will introduce substantial clipping distortions, and then later in the pipeline maybe they will make it quieter distortion. A good implementation will adjust downward during decoding, before clipping occurs. Baking a good default adjustment into the reference (as _all_ loudness measurements have some reference... there's no concept of a loudness measurement that doesn't) makes the naive implementation into a good implementation. Baking in anything other than the R128 recommended reference level would, as you like to say, cause confusion. > all audio sources. In fact EBU R128 specifically recommends that > "Loudness Metadata shall correctly indicate the actual Programme > Loudness", not a gain adjustment. And that is what the current values already represent. If it makes you feel better to think of the offset of 18*256 as a detail of the encoding in this file format, then go ahead. > In light of these issues, would it not be better to record a > TRACK_LOUDNESS tag in LUFS and an ALBUM_LOUDNESS tag (which would have > the same value for all tracks that are part of the album) also in > LUFS? I think it would be worse, for all of the reasons stated above. > In order to allow a player to adjust the loudness to any desired > target loudness and dynamic range, ideally the loudness range and > maximum true peak level would also optionally be available in a I can't remember if it's been said on the list before, but "true peak" is a meaningless concept for a lossy format with a non-bit-exact decoder specification, like Opus. The variation in the true peak calculation depending on your decoder implementation is theoretically unbounded. So you're guaranteed the value going into this tag is garbage. When we first drafted this spec, we also conducted a survey of all open-source software we could find that supported ReplayGain tags. Exactly 0 programs did anything sensible with the peak tags. The most sensible thing anyone did was ignore them, which fortunately was the majority of them. By leaving them out entirely, we're making it easy for people to do the right thing. The reference implementation includes a 0-delay declipping function, opus_pcm_soft_clip(). It's run by default when decoding to 16-bit integer output. You can call it yourself if you decode to float and convert to 16-bit later (as libopusfile does by default). If you don't clip, it has zero impact on the decoded output. It's an excellent choice for those who want to handle clipping without adding any more complexity to their decoding pipeline. Maybe it's possible to do better by adaptively enabling DRC and using a sophisticated reconstruction declipper like the one Monty wrote for Postfish, but anyone who can set that up properly would have been one of the smart ones who ignored the peak tags to begin with. From nobody Mon Sep 8 13:36:13 2014 Return-Path: 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 AFCF81A0372 for ; Mon, 8 Sep 2014 13:36:11 -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 w2pQVWND3awG for ; Mon, 8 Sep 2014 13:36:09 -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 3C02B1A0354 for ; Mon, 8 Sep 2014 13:36:09 -0700 (PDT) Received: from ppp14-2-41-157.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.41.157]) by ipmail05.adl6.internode.on.net with ESMTP; 09 Sep 2014 06:06:08 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 5418AFFE07 for ; Tue, 9 Sep 2014 06:06:06 +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 vV4kjboLc6BR for ; Tue, 9 Sep 2014 06:06:04 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 89748FF88F for ; Tue, 9 Sep 2014 06:06:04 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 77BA680470; Tue, 9 Sep 2014 06:06:04 +0930 (CST) Date: Tue, 9 Sep 2014 06:06:04 +0930 From: Ron To: codec@ietf.org Message-ID: <20140908203604.GC32116@hex.shelbyville.oz> References: <53FBC299.1070008@thaumas.net> <20140827153043.2ff5e031@crunchbang> <53FE0054.5080207@thaumas.net> <20140827212655.GW326@hex.shelbyville.oz> <20140907163126.GZ326@hex.shelbyville.oz> <20140907180607.290f13ba@crunchbang> <20140907203345.GA326@hex.shelbyville.oz> <20140908164602.2320a8c1@crunchbang> <20140908175741.GB32116@hex.shelbyville.oz> <20140908191932.14706180@crunchbang> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908191932.14706180@crunchbang> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/e1xBL4Q6Xr0WwLMrNLJ3s3-SQ4Y 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:36:11 -0000 On Mon, Sep 08, 2014 at 07:19:32PM +0100, Ian Nartowicz wrote: > > I would be entirely happy if it was recommended that R128 gain values were > stored in their tags and not normally in the output gain field, but I've felt > resistance to that idea before. The original push-back as I recall it was against the idea of needing a separate R128_ALBUM_GAIN tag at all -- since the original thinking was header gain could be used for that, if it wasn't already done during the initial encode, so only a separate R128_TRACK_GAIN was needed for "alternative normalisation". But now that we've also added R128_ALBUM_GAIN, it would be silly not to recommend using it in the way that the people who wanted it, wanted to be able to use it. I think any remaining language that indicates otherwise is mostly an oversight, partly because the people who proposed the changes to the text weren't the people who pushed to have this added, and partly because it was done by making minimal changes to the existing text. "We knew what we meant", but if it doesn't actually say that to others, then yes we ought to fix that. This is the problem with being too close to your own writing :/ > The spec itself advised the opposite and explained the reason: > everyone will apply the output gain, not everyone will apply the > tag gain. Right, but that's only a reason to do it that way if it's important to you that *everyone* always applies the gain you set. Which is an important use case, but not the one you've been concerned about. In the case where the gain you are indicating really is advisory, as you've said you really want the R128 normalisation to be (and which it makes sense to me that in many cases they should be), then it's absolutely appropriate to only use the tags for that. The spec doesn't currently say you *can't* do that, or even that you SHOULD NOT do it, but I agree the example given might mislead some people into doing that when it's probably not what they really wanted, or what's best for the case you describe. > Do we agree about this? Might be best to wait for some other comments. I think Ralph now also sees this in a similar way, and I think I can fairly safely say without fear of contradiction that it was never intended for R128 normalisation to be mandatory. It just took us a while to convert the Solution you were proposing into an actual Problem we could wrap our heads around, since we were reading the text as already allowing you to do this, and blind to the example's urging that maybe you shouldn't - so we couldn't see what your objection to the header gain MUST really was. I think mostly now someone just needs to proofread the troublesome bits again, and propose some text that more plainly says what we mean, what is required and why, and gives some better guidance as to what Best Practice for optional normalisation tags should be. When we can agree on that, we'll know we're really all on the same page about all of this :) Thanks! Ron From nobody Thu Sep 11 09:01:06 2014 Return-Path: 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 F2E971A8990 for ; Thu, 11 Sep 2014 09:01:03 -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 9QxObxJeLv9T for ; Thu, 11 Sep 2014 09:01:01 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A312F1A0672 for ; Thu, 11 Sep 2014 09:00:55 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tr6so7521447ieb.3 for ; Thu, 11 Sep 2014 09:00:55 -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=MkfUiP9wGzuv4O/euus1t6XtJL0oEN5fR59c9BD7+yA=; b=vg605Q8Ho+zdN8p/lKyIbUQ9ei66XT0fjn9hf78pqU5EdmWhsPxinYK/EXKWZamtJJ EOSN12lLIT5sZFd4bzoFugLWz8SRArOCVkE9/+yUdq6orobNHNK7lWcwyivbVNg64HDD 4RYrVzBQsNXAaiLSKhcYuUcA9ormR4nNk0AF8= 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=MkfUiP9wGzuv4O/euus1t6XtJL0oEN5fR59c9BD7+yA=; b=XgSlyjaZu7r+ecLZlzqYvpyCBSPB6WTmDx9T3OM1VFesQpZoYFAIMlYaAhCaPjbNRk jwQlpMiBDqoTBVPH+B1Y4LE7owq5UG8lM1RhH3sHYQeZ1djpKF9ZbHnpHa+FjFvwUSnW GfOaxPVL1JbnBnZQxBEG3eFcltYWUxjUcTozpPPYkRlZKeAaC1kjR1lq8GCbd+Jumh6F JysPZzH6dryr99DJ+D5nHTdvdxLo4p49Cp7gcaMXUV1T7wXrJahNV9noUwRlvTXrgIs6 oznnBEErjrB9FLQ1rZVMpsKE4ASQJPIZsmFWUd5tna9lcO+WOXfZGcuCo0RkHJUYmviB oFKA== X-Gm-Message-State: ALoCoQnalIwk3xAWYOXK+rFoMUzNnOwjE57X33M7FRmM46OgWOOJaeRGxYg8Nk9chPGE0CAZsdrQ X-Received: by 10.50.62.50 with SMTP id v18mr8966011igr.21.1410451254827; Thu, 11 Sep 2014 09:00:54 -0700 (PDT) Received: from sasami.ottawa.blindsidenetworks.com (OTWAON23-1242490325.sdsl.bell.ca. [74.14.229.213]) by mx.google.com with ESMTPSA id lp8sm5063391igb.9.2014.09.11.09.00.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Sep 2014 09:00:53 -0700 (PDT) Message-ID: <1410451239.8774.3.camel@kepstin.ca> From: Calvin Walton To: "Timothy B. Terriberry" Date: Thu, 11 Sep 2014 12:00:39 -0400 In-Reply-To: <540E0D59.50500@xiph.org> References: <540E0D59.50500@xiph.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.13.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/codec/34AFrzbum6ZCVhfy8ff223Mv29g Cc: "codec@ietf.org" Subject: Re: [codec] draft-ietf-codec-oggopus: R128_TRACK_GAIN units X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:01:04 -0000 On Mon, 2014-09-08 at 13:11 -0700, Timothy B. Terriberry wrote: > As an individual... > > Mark Harris wrote: > > output gain field of the Ogg Opus header. Is it expected that > > these > > units would be adopted by other codecs? > > I can't speak for anyone else, but if _I_ were making a new codec, I > wouldn't see a need to innovate here. This design has the lessons of > doing this for 15+ years baked into it. > > > concerned that if Ogg Opus uses 1/256 LU units, and another > > format or > > codec uses the much more obvious LU (dB) units, then someone may > > be in > > Then they should pick a different tag name. > Just to comment on this: The format of the "vorbiscomment" fields is very similar between at least Ogg Vorbis, FLAC, and Ogg Opus. As a result, the tags are often copied verbatim between the three formats during transcoding, and the interpretation of tag meaning based on name is usually shared between all three codecs in parsing code. As a result, without explicit code in the parser to e.g. reject or interpret differently this tag between different formats, a player that implements the R128_*_GAIN fields will as a side-effect add support for the same tag in FLAC and Ogg Vorbis. (This is the same reason that some players - at least gstreamer-based players, rockbox, and foobar2000 - currently accept and use REPLAY_GAIN tags in Ogg Opus files) Since this tag format is defined/specified in the Ogg Opus specification, it might make sense to use a prefix on the tag name - e.g. OPUS_R128_TRACK_GAIN - if the intent is that this tag is to be used only in the Ogg Opus format. This would reduce the likelihood of conflicts in the mostly-unregulated vorbiscomment namespace. If the intent is that the R128 tags are intended to be used also in FLAC and Ogg Vorbis then I think it would be best for it to be defined outside of the Opus specification, somewhere that developers can reference independently. In particular, care would be needed to describe interactions with the REPLAY_GAIN tags that are still used in these other formats. -- Calvin Walton From nobody Thu Sep 11 10:59:05 2014 Return-Path: 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 D75E11A8A73 for ; Thu, 11 Sep 2014 10:59:03 -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 81vVv-Wc34iJ for ; Thu, 11 Sep 2014 10:59:02 -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 C2E391A8A17 for ; Thu, 11 Sep 2014 10:57:57 -0700 (PDT) Received: from ppp14-2-41-157.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.41.157]) by ipmail07.adl2.internode.on.net with ESMTP; 12 Sep 2014 03:27:56 +0930 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id D55F3FFE1A for ; Fri, 12 Sep 2014 03:27:43 +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 g6b5u085QcZa for ; Fri, 12 Sep 2014 03:27:42 +0930 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 8C210FF8BF for ; Fri, 12 Sep 2014 03:27:42 +0930 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 79DD680470; Fri, 12 Sep 2014 03:27:42 +0930 (CST) Date: Fri, 12 Sep 2014 03:27:42 +0930 From: Ron To: codec@ietf.org Message-ID: <20140911175742.GJ32116@hex.shelbyville.oz> References: <540E0D59.50500@xiph.org> <1410451239.8774.3.camel@kepstin.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1410451239.8774.3.camel@kepstin.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/codec/IpgYwCOUKLK4wZHCj11KsL_lIXU Subject: Re: [codec] draft-ietf-codec-oggopus: R128_TRACK_GAIN units X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:59:04 -0000 On Thu, Sep 11, 2014 at 12:00:39PM -0400, Calvin Walton wrote: > On Mon, 2014-09-08 at 13:11 -0700, Timothy B. Terriberry wrote: > > As an individual... > > > > Mark Harris wrote: > > > output gain field of the Ogg Opus header. Is it expected that > > > these > > > units would be adopted by other codecs? > > > > I can't speak for anyone else, but if _I_ were making a new codec, I > > wouldn't see a need to innovate here. This design has the lessons of > > doing this for 15+ years baked into it. > > > > > concerned that if Ogg Opus uses 1/256 LU units, and another > > > format or > > > codec uses the much more obvious LU (dB) units, then someone may > > > be in > > > > Then they should pick a different tag name. > > > > Just to comment on this: > > The format of the "vorbiscomment" fields is very similar between at > least Ogg Vorbis, FLAC, and Ogg Opus. As a result, the tags are often > copied verbatim between the three formats during transcoding, and the > interpretation of tag meaning based on name is usually shared between > all three codecs in parsing code. > > > As a result, without explicit code in the parser to e.g. reject or > interpret differently this tag between different formats, a player > that implements the R128_*_GAIN fields will as a side-effect add > support for the same tag in FLAC and Ogg Vorbis. > > (This is the same reason that some players - at least gstreamer-based > players, rockbox, and foobar2000 - currently accept and use > REPLAY_GAIN tags in Ogg Opus files) This is of course one of the perils of people implementing 'generic' code with no sanity checking. I believe there are libraries which will happily try to force almost any codec into almost any kind of container, whether that is well defined and well behaved or not. Code reuse is great. Code without sanity checking gets to keep all the pieces. There's not much we can do about that except continue to remind people of the damage that blind application of the 'be liberal' principle does. Which isn't to say that FLAC and Vorbis and other Ogg mappings shouldn't ever recognise these tags, but that's a discussion for somewhere other than here right now. This group isn't responsible for decisions relating to those, nor have we been asked to be. > Since this tag format is defined/specified in the Ogg Opus > specification, it might make sense to use a prefix on the tag name - > e.g. OPUS_R128_TRACK_GAIN - if the intent is that this tag is to be > used only in the Ogg Opus format. This would reduce the likelihood of > conflicts in the mostly-unregulated vorbiscomment namespace. > > If the intent is that the R128 tags are intended to be used also in > FLAC and Ogg Vorbis then I think it would be best for it to be defined > outside of the Opus specification, somewhere that developers can > reference independently. In particular, care would be needed to > describe interactions with the REPLAY_GAIN tags that are still used in > these other formats. I think Tim already covered this when he said: It's also got two years of deployment at this point, so there's now non-trivial costs in changing it. If we had a good reason, we could change it. But "reduced confusion" is not a good reason. Changing now will only increase confusion (another lesson I've learned from letting people talk me into such changes in the past): people will be required to support both formats forever, despite the fact that one would be "standard" and the other wouldn't be. There's no inherent reason these tags need to remain Opus specific, this is just the first place they've been defined. If nothing else ever picks them up, that's probably not a big deal, if other things do, they can copy or reference the definition here, just as we have referenced the VorbisComment specification. Ron From nobody Wed Sep 24 13:14:27 2014 Return-Path: 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 8B8C91A044F for ; Wed, 24 Sep 2014 13:14:25 -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_40=-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 UBw7nYVx0bVL for ; Wed, 24 Sep 2014 13:14:22 -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 BC7CB1A03D0 for ; Wed, 24 Sep 2014 13:14:22 -0700 (PDT) Received: from [10.252.26.205] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1DC9DF2742 for ; Wed, 24 Sep 2014 13:14:21 -0700 (PDT) Message-ID: <5423261A.9040103@xiph.org> Date: Wed, 24 Sep 2014 13:14:18 -0700 From: "Timothy B. Terriberry" 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: <53FBBCA1.8060708@xiph.org> <20140830072745.GF326@hex.shelbyville.oz> <5402B137.9070809@xiph.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/codec/HCN1hgqJezfm85Y_KunsG2woymo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 20:14:25 -0000 Mark Harris wrote: > 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. To resolve this, I'm proposing (as an individual) the following text, to be added in a new paragraph at the end of Section 4.2: "The comment header MAY contain additional binary data which is not specified here. If the least-significant bit of the first byte of this data is 1, then editors SHOULD attempt to preserve the contents of this data when updating the tags, but if this bit is 0, all such data MAY be treated as padding, and be truncated or discarded as desired." Any binary extension for album art, etc., is going to have to be compatible with the Vorbis framing bit if we're going to use it for Vorbis as well, so I think this gives us a good extension mechanism with minimal restrictions while still allowing people to pad the comment header for in-place editing (so you can, e.g., update the comments without rewriting the whole file). Current tools use all-zero bytes for this padding, so they wouldn't have to change. From nobody Wed Sep 24 22:55:18 2014 Return-Path: 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 3D41C1A6F32 for ; Wed, 24 Sep 2014 22:55:17 -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 66R9JPoB_Tpa for ; Wed, 24 Sep 2014 22:55:15 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8201A6F2E for ; Wed, 24 Sep 2014 22:55:15 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h18so7830664igc.2 for ; Wed, 24 Sep 2014 22:55: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=TBSPQRkGvapK2CqRVJ/t6qWbpW8TaeVL+a4QMKwI0eU=; b=sFZe+3bLtFYwRxBFc7SSADNhrKCndMkSvOn6OClxQTtQiV4mVJPkL6t5KDzcT/jRvm Kf1D5MHeuxHuBBz/PI2vMHK1JN5s/f+n2RUL6UJt7lMWNE8gBOyRvmk4wD5LLsRac74S WGUqH/ah9gR/wBDnMP+paUIRqYQ4gK5op1J89rbswiByIBx3N9K9Vl9lhhcmH2mmI1Rp ln0p45ppeI5RQJNNH2R7DWPqHwrZpe5TwadVSmM6EMobpTSWh3T+5cPiQUUd1Jhr6nIu 7HFBVeSguhhp9+7x2VLZUbiJv60Ixti04GEvY1wzcWC4TxMO7xr7EtXnkRIJBdz3DAI4 Rx6Q== MIME-Version: 1.0 X-Received: by 10.43.156.20 with SMTP id lk20mr16161111icc.17.1411624515046; Wed, 24 Sep 2014 22:55:15 -0700 (PDT) Sender: markh.sj@gmail.com Received: by 10.107.11.10 with HTTP; Wed, 24 Sep 2014 22:55:14 -0700 (PDT) In-Reply-To: <5423261A.9040103@xiph.org> References: <53FBBCA1.8060708@xiph.org> <20140830072745.GF326@hex.shelbyville.oz> <5402B137.9070809@xiph.org> <5423261A.9040103@xiph.org> Date: Wed, 24 Sep 2014 22:55:14 -0700 X-Google-Sender-Auth: 0ppCao2HXuAzAhnJWzR-QVhvjWk Message-ID: From: Mark Harris To: "codec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/codec/nHuxhcuwqfEa1xM2ynOV1aBPVyU 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 05:55:17 -0000 Timothy B. Terriberry wrote: > To resolve this, I'm proposing (as an individual) the following text, to be > added in a new paragraph at the end of Section 4.2: Probably 5.2. > > "The comment header MAY contain additional binary data which is not > specified here. If the least-significant bit of the first byte of this data > is 1, then editors SHOULD attempt to preserve the contents of this data when > updating the tags, but if this bit is 0, all such data MAY be treated as > padding, and be truncated or discarded as desired." > > Any binary extension for album art, etc., is going to have to be compatible > with the Vorbis framing bit if we're going to use it for Vorbis as well, so > I think this gives us a good extension mechanism with minimal restrictions > while still allowing people to pad the comment header for in-place editing > (so you can, e.g., update the comments without rewriting the whole file). > Current tools use all-zero bytes for this padding, so they wouldn't have to > change. I support this change, as it at least allows for later extensions (including binary picture attachments) with less risk that files making use of such extensions will be mishandled by conforming tools. The first sentence is a bit unclear about the location of the binary data; for example, it might be interpreted to mean that a comment may contain additional binary data after the text. It would also be nice to keep zero-padding outside of the category of what is not specified here, as it is currently in use. I propose that the first sentence be worded as: "Immediately following the user comment list, the comment header MAY contain zero-padding or other binary data which is not specified here." - Mark From nobody Fri Sep 26 10:00:07 2014 Return-Path: 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 9F76B1A86EA for ; Fri, 26 Sep 2014 10:00:04 -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 kC4YhMMdxO04 for ; Fri, 26 Sep 2014 10:00:02 -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 918171A86EE for ; Fri, 26 Sep 2014 10:00:02 -0700 (PDT) Received: from [172.17.0.45] (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 CC785F2D90 for ; Fri, 26 Sep 2014 10:00:01 -0700 (PDT) Message-ID: <54259B91.9050202@xiph.org> Date: Fri, 26 Sep 2014 10:00:01 -0700 From: "Timothy B. Terriberry" 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: <53FBBCA1.8060708@xiph.org> <20140830072745.GF326@hex.shelbyville.oz> <5402B137.9070809@xiph.org> <5423261A.9040103@xiph.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/codec/AQQSTRBE4V93eYNXCN_rJpBd7Ss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:00:05 -0000 Mark Harris wrote: > Timothy B. Terriberry wrote: >> To resolve this, I'm proposing (as an individual) the following text, to be >> added in a new paragraph at the end of Section 4.2: > > Probably 5.2. Whups, yes. Sorry. > here, as it is currently in use. I propose that the first sentence be > worded as: > > "Immediately following the user comment list, the comment header MAY > contain zero-padding or other binary data which is not specified > here." Sounds good to me. From nobody Fri Sep 26 15:59:54 2014 Return-Path: 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 725241A1A0D for ; Fri, 26 Sep 2014 15:59:53 -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 LFrf6xeBc1AW for ; Fri, 26 Sep 2014 15:59:50 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8996A1A02EB for ; Fri, 26 Sep 2014 15:59:50 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar1so13408350iec.25 for ; Fri, 26 Sep 2014 15:59:50 -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=pbXVbhWVGwbRUYOsC6dxTUi+VbIDYUPf3xbjUVtU1vM=; b=TSYlYkECdZ+QulTXZDLPoNMz5wiLV5VhUzY8w1RhCNKXEHr6kd1Dwy9Qf5qYQYa5Sj 303zc/G5kJpaAt89/kkodQOIylxpMOC0EgnBUQpafgEpRcbr8+2G5zWtgJru4i/XoKTr GOnQPSw6fXH8oe6prVESugWGYPVGEqmpsKoXLAYWXx2cdy9YEumahzF+1kRJi1Ptz5yA dojHjPYHgH4Je02EH1hEMRaSpMFNxIpgjCEMnnjSM4l0+SBp8UJXEcqZVSwly0gwvLBi 9HU+/3Q/LMxNI1MckmPJPKgixnQ9ANtapGHc03uC7WtDIDo4hDkHf0nCAgrwZky2RNkO el5A== X-Gm-Message-State: ALoCoQlA5sjJ8tNDVRN7QqVK/9iI7ZkdJjllWeL/IW9ARxlYhnnDUhf7bzYXHLQ/9v6wJY1Bi8t8 X-Received: by 10.42.98.15 with SMTP id q15mr3945549icn.29.1411772389931; Fri, 26 Sep 2014 15:59:49 -0700 (PDT) Received: from tamias.local ([64.214.126.165]) by mx.google.com with ESMTPSA id ci9sm2968151igb.17.2014.09.26.15.59.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Sep 2014 15:59:49 -0700 (PDT) Message-ID: <5425EF82.7050501@thaumas.net> Date: Fri, 26 Sep 2014 15:58:10 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: codec@ietf.org References: <53FBBCA1.8060708@xiph.org> <20140830072745.GF326@hex.shelbyville.oz> <5402B137.9070809@xiph.org> <5423261A.9040103@xiph.org> <54259B91.9050202@xiph.org> In-Reply-To: <54259B91.9050202@xiph.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/codec/CTL_Jwa1a4ODTH2Ss4EXEL8YkPM 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 22:59:53 -0000 On 2014-09-26 10:00 AM, Timothy B. Terriberry wrote: >> "Immediately following the user comment list, the comment header MAY >> contain zero-padding or other binary data which is not specified >> here." I've added the text to the draft. -r