• 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: Asymmetry in CoreAudio representation?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asymmetry in CoreAudio representation?


  • Subject: Re: Asymmetry in CoreAudio representation?
  • From: Chris Rogers <email@hidden>
  • Date: Thu, 4 Apr 2002 18:19:53 -0800

The code in Daisy in incorrect, and your symmetrical version:

*outDataPtr /= 32768.0;

is the correct interpretation.

Chris Rogers
CoreAudio


I understand the inherent asymmetry in binary twos-complement numbers (i.e. there is always one extra negative value that does not have a corresponding positive value with the same absolute value because 0 is positive). Therefore, 16-bit and 24-bit audio cannot represent the exact same excursion in the positive range as the negative. This is fine, because each sample value is the same voltage difference from the next, and audio mostly doesn't care about DC biasing.

But I noticed in the Daisy source code the following algorithm:

utility.c
/* Convert16BitIntegerTo32Float() */
if (*outDataPtr > 0)
*outDataPtr /= 32767.0;
else
*outDataPtr /= 32768.0;

This looks incorrect to me, because it would distort the waveform. While 16-bit values are stepped such that each increment represents a constant increase in voltage, the floating result of the above conversion would be expanded by 0.00305185% in the positive range only. Yes, that is a very small distortion, but any calculations which invert the waveform or add or subtract some DC bias would result in those distortions becoming irreversible.

I guess my real question is not whether Daisy should be changed, but whether the entire CoreAudio system is expecting this distorted float representation, or a more even translation from fixed-point as follows:

*outDataPtr /= 32768.0;

Obviously, the above algorithm would never result in an output of exactly +1.0, unless 0.999969482421 gets rounded up to 1.0 (I haven't checked). But this technique allows for further processing to be more accurate.

Any comments would be welcome.

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.

  • Follow-Ups:
    • Re: Asymmetry in CoreAudio representation?
      • From: Herbie Robinson <email@hidden>
  • Prev by Date: fixed point routines.
  • Next by Date: Re: Asymmetry in CoreAudio representation?
  • Previous by thread: fixed point routines.
  • Next by thread: Re: Asymmetry in CoreAudio representation?
  • Index(es):
    • Date
    • Thread