On Wednesday, September 08, 2010 11:02:27 am Owen Rudge wrote:
*(BYTE *) dst = (clamp(le32(*(const float *)src), -1, 1)) * 127 +0.5;
Is it safe to call le32 on a float? Especially one that's going to be used more? If the system is big-endian, the float/integer will need to be in big- endian to be processed.
I'm also not sure that the conversion math is correct. In this case, -1.0 would get converted to -126.5 (or -32766.5, etc), instead of -128 (or -32768, etc). As well, I don't think the rules for converting a negative float value to an unsigned integer are that straight forward. I seem to recall mention that some systems will actually give 0 in that case.
You may have to go the long way and do something like: float v = *(const float*)src; if(v < -1.0f) *(__int8*)dst = -128; if(v < 0.0f) *(__int8*)dst = v*128.0f; if(v > 1.0f) *(__int8*)dst = 127; if(v >= 0.0f) *(__int8*)dst = v*127.0f;
..and similarly for 16/24/32 bit.
On 08/09/2010 15:41, Chris Robinson wrote:
Is it safe to call le32 on a float? Especially one that's going to be used more? If the system is big-endian, the float/integer will need to be in big- endian to be processed.
The raw data should be in a little-endian format. But you're right that it would probably have to be converted to big-endian to be processed, and then converted back to be stored.
I'm also not sure that the conversion math is correct. In this case, -1.0 would get converted to -126.5 (or -32766.5, etc), instead of -128 (or -32768, etc). As well, I don't think the rules for converting a negative float value to an unsigned integer are that straight forward. I seem to recall mention that some systems will actually give 0 in that case.
I realise now that I actually made a mistake in using WORD, DWORD, etc, as - with the exception of 8-bit audio - all of the destination buffers are signed. So hopefully we shouldn't have an issue with negative values being multiplied incorrectly.
I'll have a poke around and produce a revised patch.
Cheers,
-
Chris Robinson -
Owen Rudge