Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt

"Timothy B. Terriberry" <> Wed, 11 July 2012 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A4E621F85EA for <>; Wed, 11 Jul 2012 11:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k8xoLKs88o10 for <>; Wed, 11 Jul 2012 11:18:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 057B021F85B4 for <>; Wed, 11 Jul 2012 11:18:53 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 7C046F21F6 for <>; Wed, 11 Jul 2012 11:19:23 -0700 (PDT)
Message-ID: <>
Date: Wed, 11 Jul 2012 11:19:23 -0700
From: "Timothy B. Terriberry" <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
References: <> <> <> <> <20120711053951.GL18009@audi.shelbyville.oz>
In-Reply-To: <20120711053951.GL18009@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
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, 11 Jul 2012 18:18:54 -0000

Ron wrote:
> might from a first linear reading of the document.  It probably
> could usefully be split into some subsections - with the pre-skip
> definition in section 5 then providing a back reference to 4.1
> about how it fits together with granule position etc.

Yes, this is a pretty good idea. Feel free to offer some suggestions for 
section titles, etc.

> Section 6 I suspect should be folded back into appropriate places
> in the rest of the document and that section dropped entirely.
> That was kind of a placeholder for various issues that came up in
> discussion, but didn't otherwise already have a place in the wiki
> where it obviously fit at the time.

The first paragraph probably belongs in Section 4 somewhere, but I 
worried that introducing it too early would confuse the issue with 
pre-skip, when the concepts are totally independent. I should probably 
also add a sentence about what to do if the seek point is before the 
first 80 ms.

The rest (discussing packet size limitations) arguably belongs in 
Section 3, but it really is a complete aside. Having it off the critical 
path for "things you need to understand to implement this specification" 
is an advantage, I think.

I may move the first paragraph out and re-title Section 6 to reflect the 
fact that it just discusses packet size limitations.

> The defined values for Channel Mapping Family might benefit from
> being moved to that field's description in 5.1 rather than being
> left until the latter part of 5.1.1 - or at least moved to the
> top of 5.1.1 where it flows directly on from that, since we refer
> to the special cases for family 0 in the descriptions of the
> mapping table fields, without having introduced family 0 except
> by way of saying "it's special".

I think I originally pushed it back because I wanted a clear definition 
of "decoded channels" vs. "output channels" in place before I tried to 
describe the restrictions associated with each mapping family. Upon 
re-reading, I agree this order creates some other problems, though. 
However, I do think it's beneficial to keep it in its own subsection.