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: "Michael Markowski" <email@hidden>
- Date: Fri, 9 Feb 2007 21:36:23 +0100 (CET)
- Importance: Normal
Stephen,
you got me back on track with your hint about the ID3v1 tag: The
AudioFileOpenWithCallbacks routine seems to fail when opening an mp3 file
that contains no id tag at all.
I opened the mp3 file that caused AudioFileOpenWithCallbacks to fail with
a hex editor and added a 128 byte long ID3V1 tag at the end of the file.
I then could read the file with AudioFileOpenWithCallbacks. Maybe I should
file a bug ?
Cheers, Michael
> 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