Re: Calculating peak level in db
Re: Calculating peak level in db
- Subject: Re: Calculating peak level in db
- From: Brian Willoughby <email@hidden>
- Date: Mon, 14 Oct 2002 11:44:06 -0700
[ This is a little misleading. In CoreAudio (as in other systems
[ such as DirectX, VST, etc), the floating-point samples are just
[ that - standard IEEE floats, ~not~ fixed-point integers. The 0dBFS
[ range is precisely +-1.0, and peak values of exactly 1.0 are
[ possible (as indeed are over-range samples).
You are correct. In an arbitrary CoreAudio stream, one should allow for
absolute values above 1.0 - I was referring to unprocessed data from an A/D
device, where you'll never see +1.0
[ The slightly uncertain area is in the final conversion to hardware
[ in, or for, the DAC, where typically the normalised (dithered and
[ possibly clipped ) floating-point value will be multiplied by
[ 32767, to fit the 16bit range - in this way no integer clipping
[ has to be used, but you would never gets a value of -32768.
This is incorrect. The multiplier is not 32767, but 32768. Further along in
your own message, you mention using 32768 to process incoming 16 bit samples.
You must realize that a simple 16 bit to float to 16 bit stream would not
preserve the original samples if you used 32768 on input and 32767 on output.
So, to return to your example above, you will see both -32768 and 32767, with
clipping applied if any processing on the stream has created values of 1.0 or
greater. I imagine that a simple sign invert of a full-range 16 bit stream
would result in minimal clipping as -32768 (-1.0) is changed to 32768 (1.0) and
clipped to 32767 on put to a physical 16 bit device.
[ Conversely, on converting 16bit ints to float, which is what I
[ think you are referring to, the usual trick is to convert the
[ sample directly to float and then divide by 32768, so that -32768
[ converts to -1.0, and 32767 converts to a value very very very
[ slightly less than 1.0
Right, this is the phenomenon that I was trying to illustrate. But you have
to realize that you want to apply the exact same process in reverse when
converting float to 16 bit. CoreAudio fortunately does a good job of
preserving bits, even though they're converted to float along the way.
P.S. If you check the mailing list archives, you'll see that the system uses
shifting or other fast operations rather than literally dividing by 32768.
Brian Willoughby
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.