[ogg-dev] OggPCM proposal feedback

[John Koleszar]

Arc wrote:

>You're still working with the philosophy of FourCC-world, where based on 
>wether a plugin or application supports a 32-bit identifier you know if 
>it either has full support or no support.
>
>We aren't working by that philosophy.  We do not need to maintain an 
>table of predefined formats, extended each time someone wants to use a 
>new format, since no application needs to support any combination of 
>encoding parameters.
>  
>
You could pack the data into the low order part of a 32 bit word and 
treat the upper part as extended data, then people could use it like an 
enumeration if they want to. I think that this is different from the 
FourCC issue we've argued elsewhere though. The point of fully 
specifying everything is to allow applications to operate on data types 
that weren't known when they were created. It's for forward 
compatability of the applications, not the format. Arguing about whether 
to specify fields for everything now or to create enumerations for 
everything later has little bearing on what the format will be able to 
hold in the future. Actually, requiring fields constrains you a bit, 
because you have to identify all the relevant fields up front and hope 
that nobody invents a new one. Also, it's really hard to write 
applications that will operate sensibly on data types that haven't been 
invented yet, so striving for forward compatibility of the applications 
probably isn't worth much effort. Every audio lib and driver I've seen 
uses an enumeration to describe the data, and I'm sure plenty of smart 
people have had this discussion before. In the end, either way is fine 
with me, since they both fit my limited purposes, but I think this is a 
small issue compared to how to support multiple sampling rates.