Re: Issues in ExtAudioFileSeek and ExtAudioFileTell
Re: Issues in ExtAudioFileSeek and ExtAudioFileTell
- Subject: Re: Issues in ExtAudioFileSeek and ExtAudioFileTell
- From: William Stewart <email@hidden>
- Date: Wed, 11 Nov 2009 12:18:50 -0800
Abdul
You can use the ExtAudioFile API just fine if you make the slight
adjustment that Doug recommends below - also by doing this you will
know when you have to make the adjustment (with it not fixed) to
when you don't (when we do fix it)
Bill
On Nov 10, 2009, at 9:13 PM, Abdul.Majeed wrote:
Hi Doug & Bill,
Thanks for your response in time.
As I can not use the ExtAudioFile apis in my case any more until
you fix the issues in it, if you have any idea could you please let
me know will that fix may be given as update or will that take much
long time or so,
so that I can plan well?
Could you please also do not mind in helping me by giving an
alternative over here, that is decompress the audio file and read
chunk by chunk with freely moving the read header position, at
least some points, please?
On Nov 11, 2009, at 1:03 AM, Doug Wyatt wrote:
On Nov 10, 2009, at 6:16 , Abdul.Majeed wrote:
Hi Bill,
Kindly correct me If am not understanding you correctly. I am
still confused bit about your saying and the behavior about
ExtAudioFile calls especially like ExtAudioFileSeek and
ExtAudioFileTell apis.
My objective over here is read the data chunk by chunk and hold
it in buffers but the order of the reading data from the file can
be changed at any time and it is not sequential (I mean read
header position need to change
backward or forward using calls like ExtAudioFileSeek, depending
on the user interaction in UI).
As your words are considered (that is do not take care about
primeOffset, rather ExtAudioFile apis will do that for us)
For example, In case of particular file say .mp3 with primeOffset
576 following are the my observations (same kind of behavior for
other type of files with primeOffset greater than 0 ).
1. my first call to ExtAudioFileTell (this is the first call
immediately after setting the client format ) returns value of
-576;
2. read 262144 number of packets (read success) // assuming
that here number of sample in Client data format, if not also no
issues as both file sample rate and client sample rate are same
in this particular file
3. ExtAudioFileTell returns 261568 (I am assuming that return
value is in file data format not client data format)
4.Ask the read header position to move end of the file by giving
total sample count ie. 12784860 (in file data format) through API
ExtAudioFileSeek.
5. call to ExtAudioFileTell returns 12784284 //I dont understand
this when comparing the value that I got from step 3 above
6.And next if I want to move to a position = EndOfFile - 262144
== 12522716(ie using ExtAudioFileSeek, endOfFile is equal to
total number of frames in file data format, 12784860)
7. Immediate call to ExtAudioFileTell returns 12522140 (I am
assuming that return value is in file data format not client data
format)
//this also i do not understand
Could you please help me out giving more information on this?
Hi Abdul,
I've stared at the code a bit and I see the bug. ExtAudioFileTell
always return a value that's priming-frames too small. We may fix
in this in the future, so I'd suggest the following. After you've
opened the file and set the client format, call ExtAudioFileTell
(). If the position is negative, we haven't fixed the bug and
ExtAudioFileTell()'s results are off by the returned value. If the
position is zero, either the file doesn't have a priming offset,
or we've fixed the bug :-)
Thanks for bringing this to our attention.
Doug
Regards,
Abdul Majeed K
_______________________________________________
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