similar to: finalizing oggpcm channel maps

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

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

> 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 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. > I suggest this because somebody has started making changes to OggPCM > Draft2. That someone is me. I've asked about this on-list

On 2008-02-14, Conrad Parker wrote: > I tend to disagree with your sentiment. The specification of any > format or protocol has mandatory and recommended sections (not > "features"); MUST and SHOULD respectively for IETF and W3C stuff. Then why not make the common endianness MUST and the rest of it SHOULD? That was my sentiment, after all... -- Sampo Syreeni, aka decoy -

On 2007-12-30, Timothy B. Terriberry wrote: > In any format that is to be used on both, it is always better to pick > one and stick with it. Then recommend one single format. Nobody *has* to support all of the features present, yet it makes sense to *allow* common variances. Most of all, because: > Unless you can guarantee that you're writing streams that are only > going to

On 2007-12-30, Ian Malone wrote: > Really it's pretty trivial and hardly taxing on the processor either. > As far as I can tell the OggPCM standard was designed to provide a way > to wrap and describe arbitrary PCM data[1]. If you prefer to > distribute it in little endian all well and good. My thoughts exactly. On a related note, comments on the reworked channel mapping

I've tried to solicit discussion on this point in the past, but now I'd like the press the issue for a bit. I'd like to remove the less well developed mapping header (option 1) from the OggPCM draft, and make my/our (with Martin Leese) suggestion (option 2) the definitive one. If anybody objects, let's discuss it on-list. If not, I think it wouldn't be too bad of an idea

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,

(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

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

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

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

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

Arc wrote: > Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit > would be a "long double" C type) On x86 CPUs, "long double" is 80 bits. > I really don't like this idea, but I will entertain, formatting it as follows: > > ID Type Bits > 0 Int 8 > 1 uInt 8 > 2 Int 16 > 3 Int 24 > 4 Int

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

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 came out of the OggPCM discussion, but I think it needs to be addressed on a wider scale. Let's start here, 5 years ago.. http://lists.xiph.org/pipermail/vorbis-dev/2000-July/009513.html (I included this email, below) I emailed David (author of that email) and asked him to join this list. I'm thinking, as I look at the problem, that surround sound needs to be defined _outside_

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