Re: ExtAudioFile API crash when reading compressed file with different sample rate
Re: ExtAudioFile API crash when reading compressed file with different sample rate
- Subject: Re: ExtAudioFile API crash when reading compressed file with different sample rate
- From: Stephen Blinkhorn <email@hidden>
- Date: Mon, 29 Aug 2011 13:16:29 -0600
On 29 Aug 2011, at 11:30, Michael Tyson wrote:
To answer myself:
It turns out that ExtAudioFile appears to have a - well, I'll just
call it a bug for now - that results in a crash when reading the
whole file in one ExtAudioFileRead call, when resampling at the same
time.
If you break up the read into smaller chunks (I'm using 16k blocks),
within a loop, it seems to work perfectly.
Interesting. I also use ExtAudioFile to read entire files in one call
whilst simultaneously upsampling and haven't come up against this
although I work mostly with small files. I'll keep an eye out for it.
I fully intend to split up the read calls though.
Thanks,
Stephen
See my revised code:
http://pastebin.com/raw.php?i=5xHdFgvy
And the same revised code within my test project:
http://resources.atastypixel.com/AudioFileLoadTest2.zip
On Sunday, 28 August 2011 at 18:59, Michael Tyson wrote:
Hi!
Guys, my brain hurts. I'm having a some real trouble loading
compressed audio files using the ExtAudioFile API, when the files
in question have a sample rate different to the target rate.
I'm trying to load the files into memory as 16-bit LPCM at 44.1k.
The code works like a charm with all files also at 44.1k, but at
other rates, I'm seeing a crash in ExtAudioFileRead (specifically,
in SRC_convert_table_i16_scalar_stereo, within
AudioConverterFillComplexBuffer).
Here's the relevant code I'm using: http://pastebin.com/raw.php?i=E7YHRiXt
(commented, also contains a backtrace of the crash)
And here's a tiny sample project that demonstrates the problem,
with 44.1k and 48k sample MP3 files: http://resources.atastypixel.com/AudioFileLoadTest.zip
In summary, I'm:
1. Opening the source file,
2. Obtaining kExtAudioFileProperty_FileDataFormat,
3. Setting the target audio description to match the number of
channels (otherwise it's 16 bit LCPM at 44.1k),
4. Applying kExtAudioFileProperty_ClientDataFormat,
5. Grabbing kExtAudioFileProperty_FileLengthFrames,
6. Allocating a buffer to hold the loaded audio (fileLengthInFrames
* targetAudioDescription.mBytesPerFrame)
7. Performing one ExtAudioFileRead (cue crash, burn and hair loss
here)
At present I'm assuming that the
kExtAudioFileProperty_FileLengthFrames gives the length in the
client data format (the docs seem pretty vague), but even assuming
that it's giving it at the original sample rate, the crash still
occurs.
So - does anyone have any ideas where I'm going wrong? Am I just
doing something stupid?
Many thanks in advance!
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden (mailto:email@hidden)
)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden (mailto:email@hidden
)
_______________________________________________
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
_______________________________________________
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