similar to: OggPCM format being developed

(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

Moved off OggYUV thread as this is off-topic for it.. On Wed, Nov 09, 2005 at 04:51:51PM +0800, illiminable wrote: > > > >Um, data packets consist of a 32-bit header followed by PCM data. Where > >did you get the idea that "sync" data was in the packet? > > That's what the first 32 bits of "header" are. Um, no, the first 32 bits of the header is

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

Thanks Silvia for your response :-) It's good to get constructive discussion on this, and I've been hoping to have exactly this kind of criticism re: OggPCM for some time. On Wed, Nov 09, 2005 at 10:21:04PM +1100, Silvia.Pfeiffer@csiro.au wrote: > > Data pages are identified to be part of a logical bitstream through their > serial number, so don't need any additional

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

On Wed, Nov 09, 2005 at 09:31:29AM -0800, Ralph Giles wrote: > > > > I am open to eliminating it, if it can be shown that the act of reading or > > skipping this data complicates implementation or makes it less efficient, > > however, the decidion to do so should include several people (Monty, Ralph, etc) > > who haven't joined this discussion yet. > >

On Thu, Nov 10, 2005 at 05:30:10PM +0100, oliver oli wrote: > John Koleszar wrote: > >I hadn't even heard > >of ambisonics until your post, to be honest. > > because people don't know how to distribute ambisonics. no way to play > it in a DVD player. there are no easy to use software players that > decode ambisonic files and there are no widely used audio

On Thu, Nov 10, 2005 at 10:13:19AM +1100, Erik de Castro Lopo wrote: > > a) There is no marker to distinguish little endian data > from big endian data. The original reason for this is because Ogg makes such a matter moot, since the bitpacker in libogg2 handles endian.. however, if a "chunk" packer is made available (similar to memcpy), this becomes important since

Hi Arc, illi, I think it would be advantageous if we take the emotion out of this discussion , so let's just argue technically. My experience with xiph is that we are a very friendly community and trying to help each other and listen, so let's keep that culture up. I think we all agree: it is a good idea to have an media mapping for ogg for uncompressed PCM. As for what is required in a

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

On Wed, Nov 09, 2005 at 01:14:08PM +0800, illiminable wrote: > > >I agree, which is why I wrote the OggPCM draft when we already have FLAC. > >These > >formats are not difficult to design or implement, and I think the added > >efficiency and simplicity will more than make up for it. > > Which i looked at... and i'm wondering why on earth it has a sync code

On Fri, Nov 11, 2005 at 05:29:52PM +0800, illiminable wrote: > > (quote:"and thus the subject of FourCC labeling in OggStream's native video > interchange formats is closed.") > > ... doesn't sound like community debate to me. > > Maybe i missed the meeting where you became god here. If you are going to > make claims that you somehow are in charge

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

On Fri, Nov 11, 2005 at 09:13:01AM +1100, Erik de Castro Lopo wrote: > > However, support for (ie) 48-bit-float should not have to be created, > > Where are you going to find a 48 bit float? Is there an IEEE > standard for that? It's not about what's now, it's about what could be, and nobody has been able to make good predictions, except your logic here: > If

On Fri, Nov 11, 2005 at 07:17:53PM +1100, Erik de Castro Lopo wrote: > We're talking about a file header here. Even if the header is a kilobyte in > size, it will be completely **dwarfed** by the audio data following. So why > are you counting single bits like this? Why waste? You only have to read the header once for a stream, and libogg2 provides a convient bitpacker which can

In the effort of reducing list traffic, I've consolidated two replies into one: On Tue, Nov 08, 2005 at 08:24:33PM -0800, Ralph Giles wrote: > > BTW, there are already a number of general "raw" video formats in > professional use; it's not just AVI we have as prior art. :) > I'd like to see some discussion of the merits of adopting one of those > if we

On Thu, Nov 10, 2005 at 07:03:43PM +1100, Erik de Castro Lopo wrote: > > WAV is usually little endian but there is also a (very rare) big endian > version. AIFF is usually little endian but also supports big endian > encoding. CAF, AU, IRCAM and a number of others support both endian-nesses > equally. This doesn't seem to be a large issue - a single bit in the header could

I've noticed many people manually entering .. [[User:*|*]] on the talk pages to sign their contributions.. Just a friendly note that "--~~~~" is shorthand for your signature w/ timestamp. I just recently learned that, myself. In addition, I'd like to say how awesome our little community of hackers have been oven the past week. IRC, email, the lists, and the wiki have

Sorry peeps on list.. Due to wanting to keep the number of lists on westfish limited, and at Ralph's recommendation, we'll be using ogg-dev to talk re: IceShare. I guess we'll break it onto a seperate list when it gets too active to keep it here, but for now, there's alot of crossover. -- The recognition of individual possibility, to allow each to be what she and he can be,