[ogg-dev] OggPCM proposal feedback

[Tuomo Latto]

Thomas Vander Stichele wrote:
>>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 conversion from a 96bit or 80bit audio file from the same
> analog source ? If the argument for keeping these fields freeform is to
> support 96bit audio, I'd say Erik is right that you shouldn't pick
> freeform fields.
> 
> As a practical matter, I don't see a direct use case for a
> file/interchange format with a 540 dB dynamical range.

Probably not practical in terms of consumer audio and video,
but maybe in other types of signals? (Ok, 540 dB is still huge.)
What sort of dynamic ranges do they use eg. in astronomy?
Of course, that might not be the target audience for Ogg container..


There's one point about padding I'd like to raise:
Have you considered the alignment on types larger than 32-bit?
If a packet header is not corretly padded, then the packet data
is not correctly aligned and you need to memcpy it to an aligned
buffer before you can use it.
Also, if the padding between the data items (say, tightly packed
96-bit floats) is wrong, you may need to process the whole packet
before you can use any of it.

I think eg. GCC people might be able to suggest some default packing
for different data types since they probably have a some sort of view
on what different architectures can handle.


-- 
Tuomo

... Quoted-Printable: a standard for mangling Internet messages
    Quoted-Unreadable: the result of applying said standard
    Unquoted-Unprintable: the comments from the recipients of the above
                           -- Memorable Quotes from Alt.Sysadmin.Recovery
                              http://ext.netg.se/~bs/stuff/ASR.Quotes2.html