similar to: OggPCM proposal feedback

On Sun, Nov 13, 2005 at 10:36:14AM +1100, Erik de Castro Lopo wrote: > Here in the Xiph community things are a little askew. The people > with the code (Monty, Jean-Marc, Josh Coalson etc and the Annodex > team) seem to let Arc (who has yet to show any contribution > anywhere near the same league as any of the above) run the show > and trammple over people who show far more merit.

Silvia.Pfeiffer@csiro.au wrote: > Dear Arc, > > I feel ashamed of the xiph community. Hi Silvia, My slant on this is slightly different. The vast majority of Free Software and Open Source projects are meritocracies. Certain people get to positions of power in these projects through a combination of good coding/ debugging/documentation and simultaneously an ability to work well with

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

(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

Hi all, It seems like I should have joined in earlier. First, just in case it wasn't already clear to everyone, Arc is in no way talking on behalf of Xiph, certainly not me, and (as far as I understand) not Monty either. So his cluelessness and stubbornness represents only himself. Arc, I really dislike the way you've behaved, especially towards Zen (your off-list threat to Zen is simply

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

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

Arc wrote: > Does endian vary widely for raw audio codecs, Well there are really only two endian-nesses, big and little. 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. > or would it be reasonable > to settle

Hi all, Siliva contacted me about this OggPCM proposal and asked me to join in. For those who don't know me, I am the main author and maintainer of libsndfile and therefore know quite a bit about how uncompressed audio is stored in sound files. However even I would not consider myself an expert; there are areas to do with channel assignments that I know I am ignorant of. I am also quite

On Thu, Nov 10, 2005 at 01:35:47PM -0800, Arc wrote: > > "Please don't make determination of the data format depend on > > multiple fields. Instead use an enumeration so that something > > like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 > > and big endian 64 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. > >

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, > The flexibility of this does, though, encourage stuff like 96bit audio. > Anyone implementing a codec which uses this, and import/exports it, will > also write the appropriate conversion OggStream plugin which will allow > applications which only support, say, 16bit audio, to work with it. Do you think the noise in your 16bit application will sound different between a

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 Wed, Nov 09, 2005 at 05:33:37AM -0800, Arc wrote: > > Data pages are identified to be part of a logical bitstream through their > > serial number, so don't need any additional identifiers. Thus, Arc, I don't > > quite understand why you would require another 32 bits at the beginning of > > each data packet, when ogg pages are already covering that

Arc 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? I know some floating point DSP chips use a 48 bit float internally, but if there is more than one they are unlikely to be compatible and they certainly cannot be read by standard CPUs without having pull each value apart into

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

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