Talk:OggPCM Draft1

Do we need signed/unsigned data flag?

Not really. The data can be easily changed to signed as default losslessly. Unsigned 8-bit data (where 128 is the median) is easily changed to signed, and changed back if being saved as RIFF/WAV (which only supports unsigned 8-bit).

However, it wouldn't hurt to support it. Applications can be built to support one or multiple formats, thus requesting conversion if not supported by the codec.

• I don't agree with that. It just puts more conditional code into packages that would normally have only one native format and it gives them more opportunity to fail to support variants of the format. If it's fixed then a few packages will always have to modify the data, and most will never get it wrong. If it's variable then every package will have to do something sometimes, or fail occasionally. --Gumboot 01:28, 8 Nov 2005 (PST)

Do we need to record int/float data flag?

Some codecs (Vorbis) use floating point samples nativly. Others only support int. Support for int/float data flag is thus important.

Do we need to offer endian data flag?

LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fainly low-CPU process to change the endian on the application side in any event, and if the application uses the bitpacker, this isn't even an issue.

Supporting both is possible, too, but adds complexity to a format intended to be simple.

Which endian is it?

Is it worth supporting a vorbiscomment header?

It'd be useful to be able to carry information like what was decoded, or CDDB IDs, or replaygain information. Besides, if you don't put it in then five other people will do it five different ways.

How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float?

Are samples padded to some round number of bits?

Do we want/need the 32-bit data packet header?

The issue was raised on the ogg-dev mailing list of wether this is necessary. With only a single header packet, it could be considered an unneeded complication, however, additional header packets (current or future) will make this a requirement.