Am 08.03.2006 um 02:34 schrieb William Stewart:
Abstract: The suggested workaround causes the same problem
- if you are opening an MP3 file, then you should first ask it for the number of packets in the file. This will cause the parser to parse the contents of the file (so it can take some time), but it also does workaround the problem of this code hanging when doing some operations with MP3 files. I don't know if your hang is caused by this bug, but it is certainly worth investigating.
Unfortunately, here are the results of my trials:
err = AudioFileGetProperty(inAudioFile, kAudioFilePropertyAudioDataByteCount, &propertySize, &fileLength);
return noErr, and an apparently correct size. But worse yet, asking for the number of packets like it was suggested using:
err = AudioFileGetProperty(inAudioFile, kAudioFilePropertyAudioDataPacketCount, &propertySize, &fileLength);
again causes the call to hang.
This is very bad news for us, and I would appreciate if someone could suggest another workaround. And just to clarify: If CoreAudio can not read this file, that's fair enough. I have no idea where it came from, how it was encoded etc. But I need to know when it can not be read.
The file is included in the rdar report, but I have also uploaded it to http://vonbelow.com/media/corruptedSample.mp3
Alex