search for: oggpcm2

...ion? Publish it on the main website at xiph.org? What can be done at this point IMHO is to put a note onto the wiki page that the first header is frozen and that implementations are in progress. And make a statement on the remaining issues and discussions thereof on the discussion page. I support OggPCM2 as the only PCM format in Ogg, since the majority of discussion, contributions, and now implementations from the community came into this format and we cannot use the same identifier ("PCM") on two different specifications. Also, I haven't seen an implementation of OggPCM yet. Cheers...

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 i...

...is 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 than OggPCM. There were many more people involved in the discussion on OggPCM2 than on OggPCM and thus Erik jumped to the conclusion that it has superceded OggPCM. OggPCM2 is covering a broader field of appli...

Hi, I also think that outside of the extra headers, OggPCM2 is ready to be implemented. I suggest we make the main part (no extra headers) "officiel" now. We could always add stuff later on by bumping the minor number if really needed. If we go this way, I also suggest we rename it to OggPCM just to make sure it doesn't get confusing with the...

...is 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 than OggPCM. There were many more people involved in the discussion on OggPCM2 than on OggPCM and thus Erik jumped to the conclusion that it has superceded OggPCM. OggPCM2 is covering a broader field of appli...

Hi all, The remaining issue to be decided for the OggPCM2 spec is the support of chunked vs interleaved data. Just so that everyone understands what we are talking about, consider a stereo file that gets stored as an OggPCM file. Within an OggPCM packet, the audio samples for the left and right channels can be stored as interleaved where the samples wo...

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 requesting that the team working on OggPCM2 rename their proj...

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 accept that there are many good uses for chunked...

...and a default channel mapping for the most used >number of channels. For example, we would say that unless you include a >mapping header, then a 2-channel file is stereo with left channel >interleaved before right. I've added the idea at the bottom of >http://wiki.xiph.org/index.php/OggPCM2 . Any thoughts on this? > > > I think this is a good idea, but it may be wise to stop at stereo and not provide a preference for any of the 4+ channel formats. John

...risingly 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'...

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 all, I'm looking at the Channel Conversion Header; in particular the "Target Channel (M) x Src Channel (N) Gain array". Why are these numbers some sort of 15.16 fixed point value and not a 32 bit float? Is that because we want to make it easy to implement this on CPUs without floating point units? Erik -- +-----------------------------------------------------------+ Erik de

...hannel mappings and a default channel mapping for the most used number of channels. For example, we would say that unless you include a mapping header, then a 2-channel file is stereo with left channel interleaved before right. I've added the idea at the bottom of http://wiki.xiph.org/index.php/OggPCM2 . Any thoughts on this? Jean-Marc

On 2005-11-19, Jean-Marc Valin wrote: > Not sure this is a good idea. Remember that channel_map is just an > array (unless you want to make it a map?). So if you had a > OGG_CHANNEL_SPECIAL with an id of 1000, it would force 1000 entries in > the array. True, but remember that the channel map type implied the number of entries in the table, and also that in this organization

>> True, but remember that the channel map type implied the number of >> entries in the table, and also that in this organization you'll always >> number the logical channels consequtively since each logical channel >> indeed corresponds to an index into the array. If the channel map type >> says it's a map for 5.1, there will only be 6 slots in the table no

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 y...

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

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

...l mapping for the most used > >number of channels. For example, we would say that unless you include a > >mapping header, then a 2-channel file is stereo with left channel > >interleaved before right. I've added the idea at the bottom of > >http://wiki.xiph.org/index.php/OggPCM2 . Any thoughts on this? > > > > > > > I think this is a good idea, but it may be wise to stop at stereo and > not provide a preference for any of the 4+ channel formats. I think a default mapping would be needed just to help for the conversion header. Jean-Marc

On 2005-11-17, Erik de Castro Lopo wrote: > I did flesh out the wiki a **little** more. Is the intent clearer now? 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,