• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Slow seeking in MP3 files using ExtAudioFile
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slow seeking in MP3 files using ExtAudioFile


  • Subject: Re: Slow seeking in MP3 files using ExtAudioFile
  • From: Jeff Moore <email@hidden>
  • Date: Tue, 20 Jan 2009 14:11:38 -0800

MPEG-1/2 files do not have anything like a packet table or table of contents in them. So, to seek to a position in the middle of the file requires parsing the file from the beginning. Note that this is the case regardless of whether you are talking a VBR or CBR MP3 encoding. The reason why is that there are no rules about what you can stick between packets and there are apps that will put stuff there.

BTW, the parsing of the file should only happen the first time you seek to a position. The AudioFile implementation is supposed to be building a packet table in memory as it parses the file. So the second time you seek, it shouldn't require parsing from the beginning again provided the file hasn't been closed in the meantime.

Note that you can avoid all this kind of by using a file format that has a packet table in it, like CAF or MPEG-4.

On Jan 20, 2009, at 1:46 PM, Jens Alfke wrote:

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.)



--

Jeff Moore
Core Audio
Apple


_______________________________________________ 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
  • Follow-Ups:
    • Re: Slow seeking in MP3 files using ExtAudioFile
      • From: Hamish Allan <email@hidden>
    • Re: Slow seeking in MP3 files using ExtAudioFile
      • From: Jens Alfke <email@hidden>
References: 
 >Slow seeking in MP3 files using ExtAudioFile (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: Slow seeking in MP3 files using ExtAudioFile
  • Next by Date: Re: Slow seeking in MP3 files using ExtAudioFile
  • Previous by thread: Re: Slow seeking in MP3 files using ExtAudioFile
  • Next by thread: Re: Slow seeking in MP3 files using ExtAudioFile
  • Index(es):
    • Date
    • Thread