From jmvalin@jmvalin.ca Thu Dec 6 13:43:49 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4765921F87D2 for ; Thu, 6 Dec 2012 13:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDMwNT5XH39u for ; Thu, 6 Dec 2012 13:43:48 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88E21F8792 for ; Thu, 6 Dec 2012 13:43:48 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 19547F217C; Thu, 6 Dec 2012 13:43:43 -0800 (PST) Message-ID: <50C1118F.9090200@jmvalin.ca> Date: Thu, 06 Dec 2012 16:43:43 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: opus@xiph.org, "codec@ietf.org" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [codec] Opus 1.0.2 is out X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 21:43:49 -0000 Opus 1.0.2 fixes an out-of-bounds read that could be triggered by a malicious Opus packet by causing an integer wrap-around in the padding code. Considering that the packet would have to be at least 16 MB in size and that no out-of-bounds write is possible, the severity is very low. This new release also has the following changes: Quality-impacting - Changed the behaviour of the PLC to always fill the caller's buffer - Properly decode in-band FEC for packets with multiple Opus frames - Hybrid mode quality improvements and fixes - Fixed bugs in the CELT mode PLC - Redundant mode transition fixes Other changes - Stack reduction - Doc fixes (many) - 16-bit fixes - Misc build fixes - New API calls: OPUS_GET_LAST_PACKET_DURATION ctl() and opus_packet_get_nb_samples() - Minor code cleanup As usual, this release is fully compliant with the Opus specification. Cheers, Jean-Marc From tlegrand@google.com Thu Dec 13 01:07:21 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDB421F8A85 for ; Thu, 13 Dec 2012 01:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.865 X-Spam-Level: X-Spam-Status: No, score=-101.865 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaiz+UF69Fih for ; Thu, 13 Dec 2012 01:07:20 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6629C21F8A60 for ; Thu, 13 Dec 2012 01:07:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1862986vbb.31 for ; Thu, 13 Dec 2012 01:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dmS7kxBWMCqCArmY1jszvFMYcId+pKRh8O2UcnM13nc=; b=kCSi/G9NmWTXLNmUe5PSzUOK9reDkJR6A8kS9EmIpVJRwiIryAwtMdTkaCYarvIJgb 2uzPGRNOOnU2f0JsieEMmqH3rdSV9tevUhTQ/PTX9ayzVhPOgWMTnpJ1KuvakU3cYDYq g5FAvlX+JSBaEOjX1K3hW4N++fNTXOof0acZ7yxBRf7rEf7p0IOMi27xVd57rvT2x6E0 fIqT1B10qhth/ruOFrnMA805dw6Ep0j+elzSQq1Evlkcxeldhfxmp5OgAWpi6DgX+TZe rZktK48LtKw5vIOzVlh1gU9OIMB6RG9pfYq6SD7XUEmZq+Y8hN4KT6ZpjNWIvYhYI1iJ 0rqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=dmS7kxBWMCqCArmY1jszvFMYcId+pKRh8O2UcnM13nc=; b=gvmHPg/bz6V+7u5g3sZsCX7zDHFl1y3vga8jqSY99QCy05p0+WN5MqDSCDgJi01Sb2 /fe2jDC5YDH9iFPW0bOE3erKBeMEZ71yU0SKxSP0s1r8F17vVXGoIcVaeghLiTefTEYI jhGy2Hjc3J2Jw/RBvnAxY6Gxob0IsLTGuc8t0UputPhHij6V/DwIas3mQl0IqoOwvhbF w8pTxTHzlRX2au03gHiMGzCg1RjYwFmAcMWgf6jMVUk7EWTbYqd55caRMGJelDpG9wbw y+bwFFptjRvMMUh6emgsm5WlvEpjOPJJVJc/rYmDPibDO/QexF8/qA15p6nv2K7Dv1it zv1Q== MIME-Version: 1.0 Received: by 10.220.151.138 with SMTP id c10mr1800820vcw.56.1355389639307; Thu, 13 Dec 2012 01:07:19 -0800 (PST) Sender: tlegrand@google.com Received: by 10.220.225.70 with HTTP; Thu, 13 Dec 2012 01:07:19 -0800 (PST) In-Reply-To: <50AABA00.6030102@xiph.org> References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> Date: Thu, 13 Dec 2012 10:07:19 +0100 X-Google-Sender-Auth: CRdJCGcu55ai28Am2yzPXijCArQ Message-ID: From: Tina le Grand To: codec@ietf.org Content-Type: multipart/alternative; boundary=f46d043893b3fbb18b04d0b83de3 X-Gm-Message-State: ALoCoQkICFis9KgNw4NrOMgC+6xNrkoCvYPqaV1UDa+QtK7uYbfSI2O0H7GtO9nXf161dyZy4hu2zeQ4qQxIRPYYYKDY8lm5vsFfVutbm5/2lMwuK4Xy8BBE5z8Jn1bODHlvEZyNh2HQsre5FhevZ2NrFgM/Nsq/79h+dunfgk7rNWJRkCOQo86C8pGRTKpv9oE3GHVcQqXF Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:07:21 -0000 --f46d043893b3fbb18b04d0b83de3 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have reviewed draft-ietf-codec-oggopus-00, and I have some questions and comments. The Ogg format is new to me, so some of my comments might not require any changes to the specification. Section 3: - In RFC 3533 "packet" is defined to be "created by the encoder of the logical bitstream and represent meaningful entities for the encoder only", but in this section it is said that "the first packet in the logical Ogg bitstream MUST contain the identification (ID) header...". This header is not part of the regular Opus bitstream, and is defined for the Ogg Opus format only. does "packet" have a different meaning in this specification? Or should it say "the first page.."? Section 5: - Would be great if you could mention the name of the two header packets in the first section. Section 5.1, list number 4: - What is a cropped Ogg Opus stream? Section 5.1, list number 5 (page 13): - What does this mean "The original sample rate of the encoder input is not preserved by the lossy compression"? You don't get perfect reconstruction, of course, but you'll get the same audio bandwidth except for the 48 kHz mode, or is there any other filtering affecting the bandwidth? Section 5.1, list number 5 (page 13): - There is a new numbered list within list number 5, which makes the document hard to read. - List number 3: Can be more clear: "...decode at the highest supported rate above the hardware's sample rate and resample." - Right after the list of 4 ways of choosing decode rate there is a fifth, that is not in the list. I think it should be merged into the list as one option. Section 5.1.1, page 17: - Family 1: Would be better if the Vorbis channel order was described in this spec as well. Section 5.2, list number 3: - NUL -> NULL? or "null" as in section 5.1 list number 2, page 12. /Tina On Tue, Nov 20, 2012 at 12:00 AM, Timothy B. Terriberry wrote: > internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Internet Wideband Audio Codec Working >> Group of the IETF. >> > > The (other) chairs declared there was consensus to adopt this draft as a > WG item and asked me to upload a new version of it. > > I have made a few minor edits from draft-terriberry-oggopus-01: > 1) Fixed up the references. > 2) Fixed a couple of typos. > 3) Replaced a "should" with a "SHOULD" in Section 4.1. > 4) Clarified the language around the starting granule position in the case > that a) there is more audio in packets that complete on the first audio > data page with a completed packet than the granule position indicates and > b) the EOS flag is set on the same page (in this case you should not count > forwards from 0, but should work backwards to figure out the real starting > granule position). > 5) Updated the acknowledgments. > > I have not incorporated any of the proposals that have been made to the > list since the initial draft was posted (e.g., seamless chaining, > replaygain tags, etc.). > > ______________________________**_________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/**listinfo/codec > --f46d043893b3fbb18b04d0b83de3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= span style=3D"color:rgb(34,34,34);font-family:arial,helvetica,sans-serif;fo= nt-size:13.63636302947998px;background-color:rgb(255,255,255)">Hi,
I = have reviewed=A0draft-ietf-codec-oggopus-00= ,=A0and I have some questions and comments. The Ogg format is new to= me, so some of my comments might not require any changes to the specificat= ion.

Section 3:=A0
- In RFC 3533 "packet" is defined to be "created= by the encoder of the logical bitstream and represent meaningful entities = for the encoder only", but in this section it is said that "the f= irst packet in the logical Ogg bitstream MUST contain the identification (I= D) header...". This header is not part of the regular Opus bitstream, = and is defined for the Ogg Opus format only. does "packet" have a= different meaning in this specification? Or should it say "the first = page.."?

Section 5:
- Would be great if you could ment= ion the name of the two header packets in the first section.

=
Section 5.1, list number 4:
- What is a cropped Ogg Op= us stream?

Section 5.1, list number 5 (page 13):
- What = does this mean "The original sample rate of the encoder input is not p= reserved by the lossy compression"? You don't get perfect reconstr= uction, of course, but you'll get the same audio bandwidth except for t= he 48 kHz mode, or is there any other filtering affecting the bandwidth?

Section 5.1, list number 5 (page 13):
- There= is a new numbered list within list number 5, which makes the=A0document=A0= hard to read.
- List number 3: Can be more clear: "...decode= at the highest supported rate above the hardware's sample rate and res= ample."
- Right after the list of 4 ways of choosing decode rate there is a fi= fth, that is not in the list. I think it should be merged into the list as = one option.

Section 5.1.1, page 17:
- Family 1: Would be better if the Vorbis channel order was described in th= is spec=A0as well.

Section 5.2, list number 3:
- NUL -> NULL? or "null" as in section 5.1 list number = 2, page 12.

/Tina

On Tue,= Nov 20, 2012 at 12:00 AM, Timothy B. Terriberry <tterribe@xiph.org>= ; wrote:
internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0 This draft is a work item of the Internet Wideband Audio Codec Working = Group of the IETF.

The (other) chairs declared there was consensus to adopt this draft as a WG= item and asked me to upload a new version of it.

I have made a few minor edits from draft-terriberry-oggopus-01:
1) Fixed up the references.
2) Fixed a couple of typos.
3) Replaced a "should" with a "SHOULD" in Section 4.1.<= br> 4) Clarified the language around the starting granule position in the case = that a) there is more audio in packets that complete on the first audio dat= a page with a completed packet than the granule position indicates and b) t= he EOS flag is set on the same page (in this case you should not count forw= ards from 0, but should work backwards to figure out the real starting gran= ule position).
5) Updated the acknowledgments.

I have not incorporated any of the proposals that have been made to the lis= t since the initial draft was posted (e.g., seamless chaining, replaygain t= ags, etc.).

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--f46d043893b3fbb18b04d0b83de3-- From ron@debian.org Thu Dec 13 21:27:47 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E2321F8882 for ; Thu, 13 Dec 2012 21:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqp3WvwHpqws for ; Thu, 13 Dec 2012 21:27:46 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 232B121F8849 for ; Thu, 13 Dec 2012 21:27:45 -0800 (PST) Received: from ppp118-210-36-206.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.36.206]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Dec 2012 15:57:44 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id F390B4F8F3; Fri, 14 Dec 2012 15:57:42 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dqihsYOCEoFT; Fri, 14 Dec 2012 15:57:41 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id A8C7B4F902; Fri, 14 Dec 2012 15:57:41 +1030 (CST) Date: Fri, 14 Dec 2012 15:57:41 +1030 From: Ron To: Tina le Grand Message-ID: <20121214052741.GC18233@audi.shelbyville.oz> References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 05:27:47 -0000 On Thu, Dec 13, 2012 at 10:07:19AM +0100, Tina le Grand wrote: > Hi, > > I have reviewed draft-ietf-codec-oggopus-00, and I have some questions and > comments. The Ogg format is new to me, so some of my comments might not > require any changes to the specification. > > Section 3: > - In RFC 3533 "packet" is defined to be "created by the encoder of the > logical bitstream and represent meaningful entities for the encoder only", > but in this section it is said that "the first packet in the logical Ogg > bitstream MUST contain the identification (ID) header...". This header is > not part of the regular Opus bitstream, and is defined for the Ogg Opus > format only. does "packet" have a different meaning in this specification? > Or should it say "the first page.."? It's actually probably "encoder" that might have the different meaning there :) Here it means the thing encoding the "ogg bitstream" which includes both the codec (Opus) packets and the metadata in the bitstream. Ogg pages contain packets, and all payload is contained in packets, including metadata not produced by the codec itself. If there's some simple text we could add to clarify this though, please do suggest something. > Section 5: > - Would be great if you could mention the name of the two header packets in > the first section. They are introduced and named in Section 3. But the "tell them what you are going to tell them" principle means repeating that in the Section 5 intro probably isn't a bad idea. > Section 5.1, list number 4: > - What is a cropped Ogg Opus stream? That's mentioned in Section 4.4. Ogg streams can generally be shortened by trimming packets off the beginning or end of the stream without needing to rewrite the entire stream portion that is retained. If a few more words to explain this are warranted, then please suggest some extra text (and the best place to put it) for that too. > Section 5.1, list number 5 (page 13): > - What does this mean "The original sample rate of the encoder input is not > preserved by the lossy compression"? You don't get perfect reconstruction, > of course, but you'll get the same audio bandwidth except for the 48 kHz > mode, or is there any other filtering affecting the bandwidth? Once the stream is encoded as Opus, there is no longer any concept of sample rate inherent in the data. It is entirely a decision of the decoder configuration what sample rate it will be reconstructed with. Bandwidth will be preserved if it chooses a sufficiently high sample rate, but it could also take a full-band 48k original signal and reconstruct that at 8kHz. It would just throw away extra information that wasn't actually lost by the encoder. If you want to know exactly what the sample rate of the original was, (regardless of the actual bandwidth of the audio it contained), then we need to store that as metadata, because Opus doesn't know it. > Section 5.1, list number 5 (page 13): > - There is a new numbered list within list number 5, which makes > the document hard to read. That's not really a numbered list, it's a 4 step procedure. That said, that procedure itself is also under review, since it is arguably not actually the optimal decision for quality at present. > - List number 3: Can be more clear: "...decode at the highest supported > rate above the hardware's sample rate and resample." > - Right after the list of 4 ways of choosing decode rate there is a fifth, > that is not in the list. I think it should be merged into the list as one > option. That's not really a 5th step in the procedure for selecting a _playback_ sample rate. It's the rationale for having this metadata field. As the first sentence says: This field is _not_ the sample rate to use for playback of the encoded data. But if there is confusion over this section, it would be good to figure out where and clear that up too. It does sort of sidetrack a little before getting to the actual use of the field, but the sidetrack is related to when a decoder should use the field and when it should just ignore it completely. > Section 5.1.1, page 17: > - Family 1: Would be better if the Vorbis channel order was described in > this spec as well. We had discussed that, but there was no clear guidance yet on whether it was better as an external reference or should be repeated again here. > Section 5.2, list number 3: > - NUL -> NULL? or "null" as in section 5.1 list number 2, page 12. NUL is the traditional name for the 0 octet in a character string, as distinct from a NULL pointer value etc. -- though it's true that it is also called a "null terminator" when it's not actually a part of the string content ... http://en.wikipedia.org/wiki/Null_character Thanks for your feedback on all this. Ron From giles@thaumas.net Wed Dec 19 12:25:34 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EC721F8530 for ; Wed, 19 Dec 2012 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWCk+OD4R3Md for ; Wed, 19 Dec 2012 12:25:33 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id D946D21F8484 for ; Wed, 19 Dec 2012 12:25:33 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so1566993pad.10 for ; Wed, 19 Dec 2012 12:25:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=gndiKgUKFuiKqfiLcp7jFWLOs4vi+iVybdIF1tJ3DWE=; b=Q+CPQwEGrl0gUeJ7WXTrsn/0peC5KAO+tYdjjBK0srr+a5WJzAzCCfbxnKA2Evj2sj 87sqq/HngTQsNKb2bDc/xJJWNb+NV3GHE3TeGUQxdfbCon1c6pQlELwMWP+jqf1G17pb wxY/4oXwMOFW7DfyK1UgPYxGUqVmcKqdqyrD+siXbU60gkFOTgs7Uysf1VEfOzBn/eoU WC9ELosEJpirwVD4zPQ5upVcmDs0wNqvSU5bWgI6py6g1+GZ4Nn9tFT0JnwpLcm3xGdd 2t2O2ojUd4jJJDfm8tsQ0qrxzJkXrAOCIXNRelJwnufAYMEBPzpgy73iFvLvdjw6qTJi aX1A== X-Received: by 10.68.239.232 with SMTP id vv8mr22080054pbc.53.1355948733233; Wed, 19 Dec 2012 12:25:33 -0800 (PST) Received: from Glaucomys.local ([207.6.217.65]) by mx.google.com with ESMTPS id ou3sm3631764pbb.46.2012.12.19.12.25.31 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 12:25:32 -0800 (PST) Message-ID: <50D222BA.1010401@thaumas.net> Date: Wed, 19 Dec 2012 12:25:30 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tina le Grand References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmsnSLZLbbuyXMP+nJ2gxE+q182tFZGfyDSZdrmfknS9if1kf9rpG5sSafIkmeob7YH+0RF Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:25:34 -0000 On 12-12-13 1:07 AM, Tina le Grand wrote: > I have reviewed draft-ietf-codec-oggopus-00, and I have some questions > and comments. Thanks, these are very helpful. > Section 5: > - Would be great if you could mention the name of the two header packets > in the first section. Done. > Section 5.1, list number 4: > - What is a cropped Ogg Opus stream? Did Ron's explaination help? I don't think referencing section 4.4 directly is helpful. What about: "When cropping the beginning of existing Ogg Opus streams, a pre-skip of at least...to ensure complete convergence in the decoder." > Section 5.1, list number 5 (page 13): > - What does this mean "The original sample rate of the encoder input is > not preserved by the lossy compression"? I didn't come up with a way to clarify this without adding three paragraphs, like Ron did. Suggestions? > Section 5.1, list number 5 (page 13): > - There is a new numbered list within list number 5, which makes > the document hard to read. I'll have to think about this one. > - List number 3: Can be more clear: "...decode at the highest supported > rate above the hardware's sample rate and resample." > - Right after the list of 4 ways of choosing decode rate there is a > fifth, that is not in the list. I think it should be merged into the > list as one option. > > Section 5.1.1, page 17: > - Family 1: Would be better if the Vorbis channel order was described in > this spec as well. Agreed. I've added a full description of the channel order for this mapping. > Section 5.2, list number 3: > - NUL -> NULL? or "null" as in section 5.1 list number 2, page 12. This is 'NUL' as in the ascii character code, but 'null-terminated' wins the google fight, so I'll use 'null' in both locations. -r