[ogg-dev] OggPCM proposal feedback

[illiminable]

----- Original Message ----- 
From: "Arc" <arc at Xiph.org>
To: <ogg-dev at Xiph.org>
Sent: Thursday, November 10, 2005 2:57 PM
Subject: Re: [ogg-dev] OggPCM proposal feedback


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

The problem i see with this, correct me if i'm wrong, but you are suggesting 
you are going to get a really large chunk of pcm and feed it into libogg 
word at a time, in order to have it's endianness possibly reversed ? And 
then on the other end, read it out word at a time ? If as you suggest this 
is primarily for interchange, then this seems a really inefficient way to 
pass data around.

The reason it should allow specification for endianness is that, if it is to 
be used as an interchange format, it needs to be easily copied around in a 
format friendly to the host processer. Requiring the byte order flipping of 
every sample seems contrary to the purpose of such a format.


> Problem with this is inflexibility.  See, not ever application must
> support every possible combination of formatting - in fact, many will
> require a very small set of parameters going in, ie, "it must be float
> of 16, 24, 32, or 64 bit" or "it must be 16 or 24 bit signed".

What you are saying is that outputs will support some set of data formats, 
and inputs will support some other set of data inputs. In other words, each 
component only supports the types it knows how to do something with. And so, 
the hypothetical situation of some new format, not in the enumeration comes 
along, and of course, the components won't support it since they only 
support their subset of data they know how to handle. So, a new value needs 
to be added to the enumeration. The result is, existing components (which 
didn't support the new format anyway), will still be in the same situation 
if they come across a new file, with an enumeration value they don't 
understand.

So, if a new format comes along which does require a new enumeration value, 
then the components are going to have to be modified to support that anyway, 
and the adding another value to the list they support is a non-issue. The 
only possible way it's inflexible is if the number of values in the 
enumeration exceeds the size of the field it has. Probably unlikely even 
with 8 bits, almost certainly unlikely for 16.


> Implementors will never, very likely, implement 32-bit unsigned int, and
> that is not an issue.  If some fool does, his data will simply not be
> accessable to any other codec or application unless he writes a
> conversion plugin, which in essence, treats the two sides (from
> OggStream's perspective) as two entirely different codecs, even if both
> are in OggPCM format.

I know you are working on OggStream, and this is the perspective you are 
taking, but other implementations ie directshow, quicktime, mplayer, 
gstreamer don't and maybe won't be using oggstream. So i think we need to 
take a bigger picture approach what assumptions are being made here.

> I guess you could chalk this up to an inherit difference in philosophy
> and purpose between OggPCM and RIFF/WAVE (.wav).. theirs is as much an
> interchange format as a storage codec, where OggPCM isn't really
> intended for storage.  FLAC (Free Lossless Audio Codec) limits to a
> certain number of formats, and all decoders can decode these formats,
> and it's well suited for storage as a /compressed/ lossless codec..

This is another issue i see as a problem, why is it only an interchange 
format ? What is the rationale for that ? There are many people who want a 
storage format. Are you suggesting that another raw storage format also be 
made ?

I think this is the wrong approach, flac and other codecs operate on a 
tighter subset, because they have to perform complex transformations on the 
data, and supporting too many types increase complexity. A raw format 
essentially needs no processing, it just needs copying into a buffer that 
supports that type of data.


> I'd really like to prefer keeping a fixed samplesize/samplerate for all
> channels.  I really doubt any Ogg audio codec is going to get that
> complicated anytime soon, and if it's really needed, a codec plugin
> /could/ be fed/provide packets from multiple OggPCM bitstreams, just
> like how a+v codecs (ie, DV) would import/export OggPCM+OggYUV.

I think this is another problem with your approach, you are assuming that 
ogg is a closed format, and that only "ogg" formats are the issue here. Ogg 
is a generic container format, other codecs can and will be used inside it. 
Making assumptions based only on the current set of xiph codecs in my opinon 
is a little narrow focussed.

Zen.