Re: Native Device Formats
Re: Native Device Formats
- Subject: Re: Native Device Formats
- From: Brian Willoughby <email@hidden>
- Date: Tue, 23 Jun 2009 01:47:52 -0700
The following is a one-year-old reply to a dead thread. However,
since the question of converting to float samples and back often
recurs on this mailing list, I thought it would be helpful. Perhaps
someone should start a FAQ...
The reason why CoreAudio uses (and many prior systems use) the range
[-1.0, +1.0) is simply that the conversion is precise, and thus avoids
quantization error. Since integer and float representations are both
binary, the only precise conversion between them must be a whole
number power of 2. The conversion factor that is used allows all 16
million possible 24-bit sample values to be expressed as a 32-bit
float without any loss of precision. 64-bit is not needed for
conversion purposes.
Admittedly, other ranges such as [-2.0, +2.0) or [-0.5, +0.5) could
have been selected instead, and they would have offered the same
precision. So, in one minor respect, the choice we use is ever so
slightly an arbitrary one. I think it is evident why [-1.0, +1.0) was
chosen above the other precise conversion options available.
Dividing a 24-bit sample by 0x7FFFFF in order to achive [-1.0, +1.0]
is not a precise conversion. The fact that the quantization error can
be reversed under very controlled circumstances is irrelevant. The
conversion factor creates results which do not fit in 32-bit float or
64-bit float.
The thing to keep in mind is that the 24-bit fixed representation is
2's-complement, and thus the "+1.0" sample value is already missing.
Conversions to float which miss the +1.0 code are precise, other
conversions factors which achieve +1.0 are erroneous.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden