Talk:OggPCM

Big endian, little endian

The article read:

"Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian)."

To which Qqq responded on November 20, 2007:

Portable players are usually ARM, which is usually little-endian. The Macintosh is now little-endian. Obviously the PC is little-endian. Clearly there is a winner. It's long past time to stop putting the bytes in an order that makes both programmers and computers do extra work for no good reason. Don't try to hold back the tide.

Perhaps so, but factually people do use OggPCM on big-endian machines. Having big-endian as an option makes sense then, and what is suggested above would then become a recommendation on how to use the format, not a necessary limitation on it. Decoy 04:07, 19 December 2007 (PST)

I am convinced by Qqq's arguments. Default should be changed to little endian. Martin Leese 11:42, 19 December 2007 (PST)

If Qqq's argument happens to be true, I'd agree with this change as well. Since I am unsure, I'd like to propose to bring this issue up in the ogg-dev mailing list.--Ivo 11:16, 29 December 2007 (PST)

Fractional sample rate

The article read:

"32 [uint] Sampling rate [Hz]"

To which Qqq responded on November 20, 2007:

-- this should be a rational with at least a 22-bit numerator and 10-bit denominator

An integer sampling rate is trouble. Audio does not always come that way. For example, audio is sometimes tied to the NTSC frame rate of 30000/1001. That 1001 can show up in the sample rate, and thus needs 10 bits. Rates with a 3 in the denominator are common too. Super Audio CD needs 22 bits to represent 2.8224 MHz. So 22 bits and 10 bits will do the job. Better would be 32 bits for both numerator and denominator of course. A float will never be quite right, though it sure beats an integer and will in fact hold exact values into the MHz. One can't express 1/3 or 1/10 as a float, so 12345.6 and 12345.6666... are undoable that way. BTW, allowing for subsonic recording would be nice.

DSD does not have to be supported, because while technically it can be viewed as high rate PCM, in practice OggPCM aims at supporting the most common forms of conventional PCM, not much more. DSD content is rare, there is no obvious reason why it would be generated by any of the free/open source software projects like Xiph, it would also need its own sample format tag, we would need to go into the specifics of bit packing, and so on. It seems like a whole lot of extra work and complexity for very little gain.

The physical header has already been finalized, so touching the sampling rate parameter is not really an option. Fractional sampling rates would again add complexity for little real benefit, and the option would be difficult to ignore if implemented. That's bad for embedded devices. The point about NTSC, drop-frame and the like is valid, granted, but given how imperfect such sources usually are, addressing the mismatch by simple resampling techniques should be sufficient.

Subsonic recording, that's IMO unnecessary generality for something intended for multimedia work.

Decoy 04:07, 19 December 2007 (PST)

Question: will this thing be lossy or lossless or both

This uncompressed codec: will it be lossy or lossless or kinda both?