similar to: Ambisonics und OggPCM

(second try at sending this) --- 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

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

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

Arc, I always thought of you as a harmless idiot, but I no longer think you are harmless. You are now alone working on the OggPCM because everyone got tired of your power trip (I always thought some power was required to do that). Funnily enough, from the moment people gave up on you, it took only 24 hours to write a much better OggPCM definition than what you had (even though we don't

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 Tue, Nov 15, 2005 at 09:44:43AM +1100, Jean-Marc Valin wrote: > > Sorry, but that fork took over now. As I mentioned in the last email, > your version needs to be renamed ArcPCM to reflect the fact that it's a > mix of Pulse Code Modulation with your ego. No. I started OggPCM, since it was never proposed to Xiph.org it remains my trademark until which time it is accepted by

Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Martin Leese wrote: > > So what is "OggPCM"? I started this thread > > because I was puzzled why someone was > > changing a draft instead of the document > > itself. > > The original OggPCM was started by a person who really didn't > lnow what they were doing and wouldn't listen to

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

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 would be: l0, r0, l1, r1, ..... lN, rN

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

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

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

2008/9/25 e deleflie <edeleflie at gmail.com>: > Hi Vorbis-dev, > Hi, > I've been on this list for a couple of weeks, but its been quiet, so I > dont know who is who. > > My name is Etienne Deleflie, I am the creator of www.ambisonia.com, > and I am (together with the Ambisonic community) looking for a > 'delivery format' for Ambisonic data. > >

In November 2005 the discussion on OggPCM2 died down before we got around to finalizing the channel map. I thought it would be a good time to resurrect the topic. The previous threads are at http://lists.xiph.org/pipermail/ogg-dev/2005-November/000097.html and http://lists.xiph.org/pipermail/ogg-dev/2005-November/000168.html . In draft 2 of the spec, there are two types of channel maps: a

In one of the last monthly meetings it was decided that OggPCM is ready and all it needs is an implementation (for instance, in ogg123). The problem is that nobody seems available to do it. If either Martin or Sampo would like to work on it, I believe nobody will oppose. CMML and Skeleton implementations are far more urgent right now, though. I have changed the main page in the XiphWiki to

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

I have OggPCM (as currently defined) support implemented in mencoder and mplayer. I'd like to request that we settle on modifications to this header by the middle of next week or freeze the current header as the official major version 1.0, so I can get the patches cleaned up and released. We will be shipping a separate product based on this work in the near-term future, and compatability

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

Hi, The Xiph Wiki contains the four pages: OggPCM OggPCM Draft1 (with Talk page) OggPCM Draft2 OggPCM Draft3 Can I suggest that this be reduced to just one (or maybe two) pages. I suggest this because somebody has started making changes to OggPCM Draft2. My guess is that this is not desirable. Regards, Martin -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web:

John Koleszar wrote: > I have OggPCM (as currently defined) support implemented in mencoder and > mplayer. I'd like to request that we settle on modifications to this > header by the middle of next week or freeze the current header as the > official major version 1.0, so I can get the patches cleaned up and > released. One week is very little time to get public comment