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

Ron <> Wed, 11 July 2012 05:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC04511E80BA for <>; Tue, 10 Jul 2012 22:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oSYqxnQtU3hR for <>; Tue, 10 Jul 2012 22:39:30 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by (Postfix) with ESMTP id 1566611E80BF for <>; Tue, 10 Jul 2012 22:39:29 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EACYR/U95LQwo/2dsb2JhbABFt36BCIIgAQEFOhwhEgsYLhQYDYhDvUOLQIJSgxwDiEeFHodQAYESiXWEfoJv
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 11 Jul 2012 15:09:58 +0930
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id A0EDA4F8F3 for <>; Wed, 11 Jul 2012 15:09:56 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id 7VG4uHDNoybt for <>; Wed, 11 Jul 2012 15:09:51 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id E1F024F8FE; Wed, 11 Jul 2012 15:09:51 +0930 (CST)
Date: Wed, 11 Jul 2012 15:09:51 +0930
From: Ron <>
Message-ID: <20120711053951.GL18009@audi.shelbyville.oz>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] 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 05:39:34 -0000

On Thu, Jul 05, 2012 at 04:55:28PM -0700, Timothy B. Terriberry wrote:
> Ralph Giles wrote:
> >Thanks for writing this up! As Tim says, this draft is already
> Well, I had a bunch of help. This has been percolating for a while
> at
> >I think it would be better to swap sections 4 and 5. In particular, the
> Of course, this means the reader has none of the concepts needed to
> understand the pre-skip field when it is introduced (in particular,
> the 48 kHz decoding rate assumption, the difference between granule
> position and PCM sample position, etc.). We could forward-reference
> it, but it will remain completely mysterious until they get to the
> granule position section.

The order this is currently presented in seems fairly correct and
logical to me, in the sense that we have:

 1. - Introduction (refers the reader to the Ogg RFC as the basic
      first thing they need to know something about).

 3. & 4. - Expands on Ogg concepts that Ogg leaves to the codec
           mapping to define.

 5. - Defines the detail of things that are 'completely new' for
      this mapping.

I agree that section 4 is kind of long, and talks about more than
just granule position, but the order the information is presented
there seems roughly correct too for understanding as much as you
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.

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 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'm likewise interested in how this reads to other people too
though, since being clear to people who haven't read it before
is obviously the goal :)