• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Calculating peak level in db
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calculating peak level in db


  • Subject: Re: Calculating peak level in db
  • From: Richard Dobson <email@hidden>
  • Date: Sun, 13 Oct 2002 11:23:24 +0100

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). Only hardware DSP chips use 24bit fixed-point (e.g. Motorola 56K series; and the SHARC can also support 32bit ints and floats), where, as you rightly say, the maximum positive value is 2^^(N-1) -1 (where N=24).


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.

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 (I guess the driver writers will be able to desccribe precisely what they do here...). But the floats format itself, as used within CA, can certainly support a value of 1.0, and even of 32768.00001 if you really want to be perverse (and believe it or not, Syntrillium of Cool Edit fame actually use the floats range +- 32768.0 internally, and even try to pretend this is a legit file format!).


The basic point about floats is that you trade precision against dynamic range, and in one analysis I saw (from Sonic Foundry, discussing WAVE_FORMAT_IEEE_FLOAT), you can take a sample up to 2.0, after which point the precision in the mantissa falls below 24bit. Certainly, keeping within +-1.0 maximises precision and gives the best parity with 24bit ints.


Richard Dobson



Brian Willoughby wrote:

[ Does this mean my assuption is wrong, that the maximum sample
[ value I can get is 1.0?
[ And if it's wrong, which is the maximum sample valus I might get?

CoreAudio uses floating point, which is rather new in digital recording. Floating point has the advantage of hiding the detail of whether you have 8 bit, 16 bit, or 24 bit samples. The defined range is -1.0 to 1.0, but due to the way that binary fixed point numbers work, you'll never precisely reach 1.0 although you should still calculate as if you expect to get 1.0 (you *can* get -1.0, however). See the CoreAudio list archives for code examples.

e.g. 16 bit samples range from -32768 to 32767 in fixed point. The -32768 maps precisely to -1.0 in CoreAudio, but the 32767 doesn't quite reach 1.0 exactly, although it gets closer to 1.0 than an 8 bit sample would. I suppose 24 bit sampling would approach 1.0 even closer :-) NOTE: the 32 bit floats in CoreAudio probably cannot handle more than 24 bit samples, at least not while preserving full accuracy (not that I've seen any equipment that samples beyond 24 bit).

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.
_______________________________________________
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.

  • Follow-Ups:
    • Re: Calculating peak level in db
      • From: Brian Willoughby <email@hidden>
    • Re: Calculating peak level in db
      • From: Matthew Xavier Mora <email@hidden>
References: 
 >Re: Calculating peak level in db (From: Gerd Castan <email@hidden>)
 >Re: Calculating peak level in db (From: Brian Willoughby <email@hidden>)

  • Prev by Date: pixel-based metering [was: Calculating peak level in db]
  • Next by Date: Rumblence AudioUnit public beta released
  • Previous by thread: Re: Calculating peak level in db
  • Next by thread: Re: Calculating peak level in db
  • Index(es):
    • Date
    • Thread