similar to: OggPCM2 : chunked vs interleaved data

I made a few updates to OggPCM2 http://wiki.xiph.org/index.php/OggPCM2 reflecting the latest discussions. Could everyone have a look at it and see if they agree. Otherwise, what do you feel should be changed? Anyone wants to speak in support of chunked PCM? For all those that are just tired of this mess like me, please express yourself in the new spec I created: OggPCM3

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

> 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

On 11/15/05, Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Hi all, > > The remaining issue to be decided for the OggPCM2 spec is the support > of chunked vs interleaved data. I think interleaved is the obvious choice - that's what most audio applications are used to dealing with, it's what we need to feed to audio hardware in the end usually, etc. Whilst I

Sampo Syreeni wrote: > Secondly, I'd like to see the channel map fleshed out in more detail. Sampo, I did flesh out the wiki a **little** more. Is the intent clearer now? > (Beware of the pet peeve...) What is that 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

HI all, John Kkoleszar has asked for the option of storing data. He gave the rational that a) SIMD optimized filters b) Writing filter chains. Conrad Parker supported this say that both Core Audio and Jack operate on multiple single channel buffers. On IRC both Jean-Marc and MikeS argued that if OggPCM supports interleaved, the addition of chunked is hard to justify. My slant on the

On 2005-11-16, Jean-Marc Valin wrote: > Otherwise, what do you feel should be changed? 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. Secondly, I'd like to see the channel map fleshed out in more detail. (Beware

Rene Herman wrote: > Why store N-bit in the most significant bits and not least? Doesn't > that mean an application would likely need to shift everything down > again? One advantage of storing in the MSB's is that the relative value remains correct when processed as the larger word size. For instance, a signed 12 bit integer would use 0x400 to represent +50% amplitude. By

Hi, although the OggPCM2 draft states that it is a work in progress, it also states that the main points of contention are in optional headers. I'd like to add OggPCM2 seeking support to liboggz, which will also display correct timestamps in oggzdump and allow oggz-validate to run on OggPCM2 files for testing, while implementations are being developed. In order to do this, only the Main

Hi, I'd support the view of freezing the main header, since it helps in actually getting some implementation happening and it seems fully agreed on by everyone. FAIK, Zen has already started an implementation and if you, Conrad, implement, too, there is enough code to do validation. What do you expect now to make it an "officially frozen" specification? Publish it on the main

On 10/19/07, Sampo Syreeni <decoy@iki.fi> wrote: > On 2007-10-19, Martin Leese wrote: > > OggPCM Draft3 > > Draft 3 is obviously a joke. Draft 2 is what most of the people agreed > upon the last time around, with the channel maps left unfinished. Draft > 1 was abandoned by most people in favour of draft 2. So what is "OggPCM"? I started this thread

> Yes. Channel map type tells us what the primary interpretation of the > stored signals is. Channel definitions are there to tell which stored > channel corresponds to which abstract channel in the type. Channel > conversions define downmixes to secondary formats, as they do in MLP, > and might end up being ignored unlike the channel map. I think the channel conversion will

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

On Tue, Nov 15, 2005 at 03:10:22AM +1100, Erik de Castro Lopo wrote: > That spec is being superceded by: > > http://wiki.xiph.org/index.php/OggPCM2 The project has been forked, not superceded. Work on OggPCM is continuing, the team working on OggPCM2 is free to submit their own draft but some are not welcome to continue work on OggPCM due to their recent social conduct. I'm

This is getting very dangerous. We cannot take our flamewar to outside mailing lists without making a complete fool of ourselves. Arc, would you please refrain from doing so in future and rather come to an internal agreement beforehand? Arc, there are a few things you have missed: The discussion on OggPCM2 was friendly and constructive and there were no flame wars and the spec got much further

Hi, this message is a cross-post to the Sursound and ogg-dev mailig list. The developers on the ogg-dev list are defining the Ogg/PCM format and on Sursound list there discussion about Amisonics file formats recently. I have not been able to follow both disussion, just skimmed through. But maybe you can work together to bring Ambisonics into Ogg/PCM? :) http://wiki.xiph.org/index.php/OggPCM

> Unfortunately the ALSA API defines a number of formats which are > in practice extremely rare. In particular, any unsigned int format > larger than 8 bits. For instance, the only unsigned int type that > libsndfile supports is unsigned 8 bit. I expected this, it just seemed like a good starting point to get more than 7 formats on the table. Specifically I wanted to the logarithmic

Hi all, I updated the wiki with another rev of this format. Updates include support for 43 formats in 14 coding schemes, as derived from the ALSA API. This seemed like a good way to get a list of what the formats in common use out there are, so it should be fairly comprehensive. Modifications to the "rev 2" format: 1. Expanded the 'id' field to support more than 7 formats.

> I that this is handled pretty nicely by the "simple map" that Sampo > suggested. This is basically the same thing as the "channel map" > described on the wiki, but with the (physical,logical) channel pair > swapped. So, using the syntax from the wiki: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map

Hi all, Conrad, MikeS, Silvia, Erik, Illi, John and I have been working on another spec. It's definitely not final, but it should address several issues with the previous one. Please comment: http://wiki.xiph.org/index.php/OggPCM2 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