I'm working on an app that does random-access playback of MP3 and AAC
files. It uses ExtAudioFile to read and decode the files. I'm finding
that changing the playback position in a file can be very expensive —
for example, I open a 20-minute MP3 file, seek to a point about 5
minutes in, and then the first call to ExtAudioFileRead takes over two
seconds. During this time, the MP3 decoder is issuing large numbers of
fstats 32k reads; it seems to be reading from the start of the file
all the way to the point its seeked to.
Is this to be expected? Granted, this is a VBR file so the mapping
from time to byte offset isn't linear, but I thought there was a table
in the file that served as a TOC. Or is there really no faster way for
the decoder to seek than to read MPEG frames until it finds the right
time?
(If the latter, is there a way I could produce an external TOC that I
could save persistently? I already save metadata about the files, such
as a scaled-down waveform preview, that's keyed to the file mod date,
so a TOC would be easy to add.)
Thanks,
—Jens
PS: This is in 10.5.6 on a 2.4GHz MacBook Pro, using the internal
160GB disk.
_______________________________________________
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
