Re: AudioFileOpenWithCallbacks fails on certain files / file types, while AudioFileOpen succeeds
Re: AudioFileOpenWithCallbacks fails on certain files / file types, while AudioFileOpen succeeds
- Subject: Re: AudioFileOpenWithCallbacks fails on certain files / file types, while AudioFileOpen succeeds
- From: james mccartney <email@hidden>
- Date: Thu, 6 Nov 2008 10:39:13 -0800
Please file a bug report and attach the files which exhibit problems.
On Nov 6, 2008, at 1:01 AM, Svilen Stoilov wrote:
Hello,
I'm using AudioFileOpenWithCallbacks in a library that decodes audio
files (or audio input in general) to a specified PCM format.
I've noticed that for some file types or for certain files
AudioFileOpenWithCallbacks fails to recognize the data format or/and
the file type.
However AudioFileOpen has no problem and actually works in all cases.
My latest tests are held on OS X 10.5.5
The official documentation is not specific about the actual difference
between AudioFileOpen (AFO) and AudioFileOpenWithCallbacks (AFOWC)
which
initially made me think that the difference is only in the audio
source (respectively a file or a stream accessible through callbacks).
In reality I see a different behavior.
I'm aware that the stream must be seekable and it is. I have verified
that the callbacks never fail, the data requested by CoreAudio is
always provided.
I've tried with a specific file type hint and with no hint (0) as well
- both cases work for AFO and both cases fail when AFOWC is used.
Here are 2 specific problems:
1. a certain wave file which is properly recognized by AFO, but AFOWC
thinks it's MPG1 file with .mp1 data. This wave file have lot's of FF
bytes at the beginning of the data chunk. When I trim half a second
from the beginning of the file, AFOWC correctly detects it as a WAVE
file with lpcm data format. It seems that regardless of the file type
hint, the file extension, the file header (which is OK) AFOWC tries to
detect the file type only by inspecting the audio data.
2. AIFF 16-bit little endian. Such a file is created when a CD track
is copied (ripped). In reality it is AIFC (compressed AIFF with a
pseudo compression because only the bytes are swapped).
AFOWC opens the file, but the data format cannot be obtained: there's
a "fmt?" error. Again AFO succeeds with such files.
Here is in general the code that I have:
/* This works reliably - the input format and fileType are correct
UInt8* pfile = (UInt8*)"/some_audio_file";
FSRef fsref;
err = FSPathMakeRef(pfile, &fsref, NULL);
err = AudioFileOpen (&fsref,fsRdPerm,0, &m_infile);
*/
// This works in most of the cases, but sometimes inputFormat
and fileType are NOT correct afterwards
err = AudioFileOpenWithCallbacks( pStream, // for files this is a
wrapper around the actual file
readProc, writeProc, getSizeProc, setSizeProc,
0 // no hint here, but specific hints are also tested
,&m_infile);
// get the data format
AudioStreamBasicDescription inputFormat;
UInt32 size = sizeof(AudioStreamBasicDescription);
err = AudioFileGetProperty(m_infile, kAudioFilePropertyDataFormat,
&size, &inputFormat);
// get the file type
AudioFileTypeID fileType;
size = sizeof(AudioFileTypeID);
err = AudioFileGetProperty(m_infile, kAudioFilePropertyFileFormat,
&size, &fileType);
So, does anybody know for sure that AFOWC is not the same as AFO in
terms of the logic that parses that audio data?
Is there some non-obvious prerequisite, constraint or trick for
using AFOWC?
Thank you in advance. I'll appreciate any clues and suggestions.
--Svilen
_______________________________________________
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