Silvia.Pfeiffer@csiro.au
2005-Nov-14 12:29 UTC
[ogg-dev] OggPCM : Need more justification for chunked data
Hi Rene, we have discussed the issue of different formats per channel, e.g. different sampling rates. It was not clear whether with PCM sampling of devices this is actually a common (or even used) case. Do you know how multi-channel sound is sampled? Is it created with different widths/rates on different channels? If it is not a common case, we can leave the solution to different streams and keep it outside OggPCM. If it's common and the data comes interleaved in one stream, we should discuss including it into OggPCM. Cheers, Silvia. -----Original Message----- From: ogg-dev-bounces@xiph.org on behalf of Rene Herman Sent: Tue 11/15/2005 12:07 AM To: Jean-Marc Valin Cc: ogg-dev@xiph.org Subject: Re: [ogg-dev] OggPCM : Need more justification for chunked data Jean-Marc Valin wrote:> Two other issues that remained were: > 1) Need for minor version (Silvia and I want it, MikeS is against) > 2) Having the header 32-bit aligned vs. making the channel field 8 bitsAlternatively, make it 16-bit (or 8-bit and define the next byte as "padding") and shrink the "significant bits" field to 16 as well. Having 2^32 significant bits seems rather unuseful? I do see that the channel info encoding is in here. Not different formats/width per channel. Does that need discussion? Rene. _______________________________________________ ogg-dev mailing list ogg-dev@xiph.org http://lists.xiph.org/mailman/listinfo/ogg-dev
Rene Herman
2005-Nov-14 17:23 UTC
[ogg-dev] OggPCM : Need more justification for chunked data
Silvia.Pfeiffer@csiro.au wrote:> we have discussed the issue of different formats per channel, e.g. > different sampling rates. It was not clear whether with PCM sampling > of devices this is actually a common (or even used) case. Do you know > how multi-channel sound is sampled? Is it created with different > widths/rates on different channels?I must say I'm not at all aware of how often it is done, but for example the DVD-A specification allows for independent sampling rate and bit depth for the 6 channels. It allows for 24, 20 and 16-bit widths and 192000,96000,48000 and 176400/88200/44100 sampling rates for the front and surround channels (and adds 24000 and 22050 for the LFE channel) and allows those to be freely combined -- the rates only within one family; N * 24000 or N * 22050. Now, whether or not there would be many DVD-A's using multiple formats for the channels when/if the thing catches on as a medium is for anyone to say but it does make sense to me personally. Say, 24/96 for the front channels, 16/48 for the surround channels and, maybe, 16/24 for the LFE channel. _If_ it catches on it will probably become the main source of multiple channel PCM audio in the future (SACD is DSD, not PCM, which is probably a better idea anyway but the market decides -- possibly on neither).> If it is not a common case, we can leave the solution to different > streams and keep it outside OggPCM. If it's common and the data comes > interleaved in one stream, we should discuss including it into > OggPCM.But having said all that, if it would be a pain to support, and multiple logical streams would work just as well, that might be good enough. I don't have much insight into what the added complexity would amount to. Perhaps if the rates are limited to integer multiples that it wouldn't be too bad? Rene.