[ogg-dev] OggPCM2 : chunked vs interleaved data

[Jean-Marc Valin]

> One obvious thing that seems to be lacking is the granulepos mapping. As 
> suggested in Ogg documentation, for audio a simple sampling frame number 
> ought to suffice, but I think the convention should still be spelled 
> out.

I was under the (maybe wrong) impression that the Ogg spec already
covered everything that's needed for granulepos. If that's not the case,
please suggest some text.

> Secondly, I'd like to see the channel map fleshed out in more detail. 
> (Beware of the pet peeve...) IMO the mapping should cover at least the 
> channel assignments possible in WAVE files, the most common Ambisonic 
> ones, and perhaps some added channel interpretations like "surround" 
> which are commonly used but lacking in most file formats. (For example, 
> THX does not treat surround as a directional source, so the correct 
> semantics cannot be captured e.g. by WAVE files. Surprisingly neither 
> can the fact that some pair of channels is Dolby Surround encoded, as 
> opposed to some form of vanilla stereo.)

You mean describing the enums for "Channel Mapping Header" just like we
have the the format? Yes, this definitely needs to be done. My comment
about OggPCM2 being nearly done obviously didn't apply to the extra
headers (which can still be defined afterwards anyway). Some default
mappings may be useful too (e.g. by default, 2 channels is stereo and
left is encoded first).

> (As a further idea prompted by ambisonic compatibility encodings, I'd 
> also like to explore the possibility of multiple tagging. For example, 
> Dolby Surround, Circle Surround, Logic 7 and ambisonic BHJ are all 
> designed to be stereo compatible so that a legacy decoder can play them 
> as-is. But if they are tagged as something besides normal stereo, such a 
> decoder will probably just ignore them. So, there's a case to be made 
> for overlapping, preferential tags, one telling the decoder that the 
> data *can* be played as stereo, another one telling that it *should* be 
> interpreted as, say, BHJ, and so on. Object minded folks can think of 
> this as type inheritance of a kind. But of course this is more 
> food-for-thought than must-have-feature since nobody else is doing 
> anything of the sort at the moment.)

I would say that this can probably be handled by the "Channel Conversion
Header", don't you think. I was also wondering if it was a good to
actually suggest (as in "implementers SHOULD") certain default mappings,
for example in down-sampling from stereo to mono and all.

> > Anyone wants to speak in support of chunked PCM?
> 
> Actually I'd like to add a general point against it.

Good :-)

	Jean-Marc