Re: kAudioFormatFlagIsFloat sample range
Re: kAudioFormatFlagIsFloat sample range
- Subject: Re: kAudioFormatFlagIsFloat sample range
- From: Brian Willoughby <email@hidden>
- Date: Sun, 12 Sep 2010 00:01:37 -0700
On Sep 11, 2010, at 20:49, Stephen F. Booth wrote:
If kAudioFormatFlagIsFloat is set as part of an ExtAudioFile's
client format, should the returned samples be in the range [-1, 1)?
I've always worked under this assumption but I can't find anything
explicit in the documentation. I've recently observed samples
being returned from AAC files with values >= 1 (and < -1), which is
causing clipping on one of my devices. It isn't difficult to
perform hard limiting, but this is something I hadn't noticed before.
A representative file looks like:
File data format:
AudioStreamBasicDescription: 2 ch, 44100 Hz, 'aac ' (0x00000000)
0 bits/channel, 0 bytes/packet, 1024 frames/packet, 0 bytes/frame
Client format:
AudioStreamBasicDescription: 2 ch, 44100 Hz, 'lpcm' (0x00000029)
32-bit little-endian float, deinterleaved
After each call to ExtAudioFileRead I scan for the min/max sample
values, and here is an example of what I'm seeing:
Max sample value: 1.011417
Min sample value: -1.063289
Min sample value: -1.003544
Min sample value: -1.058746
Min sample value: -1.077708
Max sample value: 1.046287
Is this to be expected?
Hmm, if you were dealing with a lossless file data format, then I
would say that this is entirely not expected. However, if there was
SRC happening between file and client, then it's possible that the
anti-alias filtering could have a gain of > 1.0 at certain frequencies.
As for AAC, it's a complex sum of multiple frequency bands, so it
seems easily possible that the reconstructed wave might exceed the
normal range. For sure, the waveform out of AAC is not going to
match the waveform that went in, so it could just as easily be higher
amplitude as lower amplitude. I would assume that the frequency
banks in the AAC reconstruction filters have weights that would never
sum to more than 1.0 in amplitude, but I must admit that I have not
studied lossy formats because I primarily use lossless.
Sorry, my response is far from definitive, but I'm just giving ideas
as to why it might not be guaranteed to fall within the usual range.
You may have found a bug, or not, it's up to someone else to say.
I'm sure that a reproducible test case sent to bugreport might be
helpful.
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