similar to: OggPCM (uncompressed Ogg audio)

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

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

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

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

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.

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

Just a quick note, realizing that many interested parties on vorbis-dev may not be subscribed to ogg-dev.. We're working out the details for an OggPCM codec, an uncompressed audio interchange format which will be used by the next generation Ogg framework. You can read what's taken place on this so far on the wiki and list: http://wiki.xiph.org/RawCodecs http://wiki.xiph.org/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 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 Tue, Nov 08, 2005 at 03:33:57PM -0500, John Koleszar wrote: > > In terms of colorspaces, it seems to me that the only way to completely > describe the colorspace is to provide the transform matricies to or from > some reference colorspace. Is this a valid statement? Except there are not enough colorspaces in use to need to do this, as far as I've read at least.. a set of

On Wed, Nov 09, 2005 at 09:59:02AM +0800, illiminable wrote: > > While it's true there are a bunch of FOURCC's that represent non-raw > formats like DIVX etc, the ones which represent raw YUV types are pretty > well defined. Yes you certainly still need the width, height, aspect ratio > and frame rate. Since FourCC is an identifier for a different codec, what you are

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

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

> If you want to limit the allowable values for the FourCC field, I don't have > an issue with that, but I think it's useful for decoders to be able to tell > easily whether or not they support the format (since most decoders will > operate on the well defined formats) and useful for encoders, since most data > sources are described by a fourcc (the exception being

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

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