Re: Open audio file from a buffer - not from file
Re: Open audio file from a buffer - not from file
- Subject: Re: Open audio file from a buffer - not from file
- From: Stephen Davis <email@hidden>
- Date: Thu, 8 Feb 2007 11:23:37 -0800
On Feb 8, 2007, at 12:12 AM, email@hidden wrote:
Hello,
sorry for bothering again, but I am totally stucked with
AudioFileOpenWithCallbacks.
I searched the web for any hints on this and all I've found is an old
unanswered question in this mailing list - no example, nothing...
Are there any differences in the parsing of the audio data between
AudioFileOpen and AudioFileOpenWithCallbacks ? How does it come
that some
audio files (seems to apply to mp3 files only) can be read by
AudioFileOpen correctly, but fail to be read with
AudioFileOpenWithCallbacks?
Is there any other way to open an audiofile from a buffer and not
from a
file?
Example:
A)
FSPathMakeRef ((const UInt8 *)inputFile, &theRef, NULL);
AudioFileOpen (&theRef, fsRdPerm, 0, &audioFile1);
err=AudioFileGetProperty(audioFile1, kAudioFilePropertyDataFormat,
&propsize, &fileFormat);
-> works like a charm
B)
NSData *data = [[NSData alloc] initWithContentsOfFile:[[NSString
alloc]
initWithCString:inputFile]];
AudioFileOpenWithCallbacks(data, ReadAudioFromBuffer,
WriteAudioToBuffer,
GetSizeFromBuffer, SetSizeToBuffer, 0, &audioFile2);
err=AudioFileGetProperty(audioFile2, kAudioFilePropertyDataFormat,
&propsize, &fileFormat);
-> fails on some mp3 files, even if they can be opnened via
AudioFileOpen.
err returns -50
I added some debug output to see what data in the buffer is
accessed by
the callback. As you can see, the routine first reads some byte at the
beginning of the buffer an then skips to the last 128 bytes to read
more
information.
Opening audiofile via AudioFileOpenWithCallbacks...length 3473
inPosition 0 requestCount 12
inPosition 0 requestCount 12
inPosition 0 requestCount 10
inPosition 0 requestCount 10
inPosition 3345 requestCount 4
inPosition 2115 requestCount 1027
AudioUnitGetProperty (file format) failed with error -50
I guess this is done to detect the right file format and choose the
corresponding parser. Everything seems right to me, but why does it
fail ?
This is my callback:
xtern OSStatus ReadAudioFromBuffer(void *inRefCon,
SInt64
inPosition,
ByteCount
requestCount,
void
*buffer,
ByteCount
*actualCount)
{
ByteCount requestOffset = inPosition + requestCount;
ByteCount availableBytes = [inRefCon length] - inPosition;
if (requestOffset > [inRefCon length]) {
*actualCount = availableBytes;
} else {
*actualCount = requestCount;
}
[inRefCon getBytes:buffer
range:NSMakeRange(inPosition,*actualCount)];
return noErr;
}
All the examples I have found are opening audio data via files, I hope
someone on this list can give a hint on this.
Thanks for any help,
Michael
Off the top of my head (with no verification whatsoever nor do I work
on the CoreAudio team), I'd imagine the read proc wants you to return
eofErr when you hit the end of the buffer. I have successfully used
the AudioFile callback procs in this manner but not for MP3 files.
To answer the question of why it reads 128 bytes at the end of the
file, it is most likely looking for an ID3v1 tag.
hth,
stephen
_______________________________________________
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