Talk:OggPCM Draft1: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
'''Do we need signed/unsigned data flag?''' | '''Do we need signed/unsigned data flag?''' | ||
Not really. The data can be easily changed to signed as default (almost?) 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. | |||
'''Do we need to record int/float data flag?''' | '''Do we need to record int/float data flag?''' | ||
Can int/float data be losslessly (and easily) converted? | Can int/float data be losslessly (and easily) converted? '''No.''' | ||
The real question here is if floating point is really nessesary. Support for it could always be added in a later minor version, if it becomes nessesary. Remember that this codec is primarily for "internal use" between the application and a compressed audio codec (ie, Vorbis, FLAC, Speex). | |||
| Line 12: | Line 15: | ||
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. | 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''. | |||
Revision as of 20:45, 7 December 2004
Do we need signed/unsigned data flag?
Not really. The data can be easily changed to signed as default (almost?) 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.
Do we need to record int/float data flag?
Can int/float data be losslessly (and easily) converted? No.
The real question here is if floating point is really nessesary. Support for it could always be added in a later minor version, if it becomes nessesary. Remember that this codec is primarily for "internal use" between the application and a compressed audio codec (ie, Vorbis, FLAC, Speex).
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.