[Scummvm-devel] Idea: IndexedMp3AudioStream

[Max Horn]

Hi folks,

some remarks on this subject (and I am sorry for repeating some things that may have been said already, but I only had time to glance over the conversation, sorry).

MP3 seeking performance (at least in VBR encoded files) is an annoying issue (MP3 was designed for streaming, and that shows in many ways), but also an old one; many people had had to cope with it over the last decade. Hence, it might pay off to search around a bit for existing solutions.

A standard strategy to cope with it (as you already discovered) is to use a table of suitable size which records the total length, and the file offsets for certain frames. For example, a table with 10 entries, spaced evenly along the time axis, reduced the amount of the file that has to be scanned for a seek by a factor of 10. Obviously, the size of the table is a trade-off between seeking time and memory consumption...

This seek table can easily be created while computing the length of the MP3, but of course this is slow for big files (which is why this thread was started, after all ;). Still, the point I want to make is this: We could easily modify our MP3 stream class to support using a seek table. The code would be the same whether the seek table is created on the fly, or laoded from a precomputed cache file, or from an ID3 tag. Hence, I think it should be possible to add support for this in a relatively clean way.


Now, as to how and where to store a seek table for an MP3 file.. 

It is true that ID3 v2.4.0 has a frame for a seek table, the ASPI "Audio seek point index" frame (see section 4.30 in <http://www.id3.org/id3v2.4.0-frames>). Unfortunately, according to <http://www.id3.org/Home> it is not really that wide spread, and clients may not support it properly (see <http://www.id3.org/Compliance_Issues>). Rather, it seems 2.3.0 is the most wide spread (and it does not cover the seek table data). 
In v2.3.0, there is the MLLT "MPEG location lookup table" frame (see <http://www.id3.org/id3v2.3.0#head-febc618121880ee751b0c2a87327b0e698213dc4>), which also provides a seek table, but the format is mostly suitable for CBR files.

ID3 in either revision still has the advantage that it is at least a well-known unofficial "standard", and we would not have to create tools from scratch... But we would have to create the code for parsing this thing. Note that there is a sister library to libmad, called libid3tag; see also <http://www.id3.org/Implementations> for more implementations.


Another method to record such a table inside an MP3 file is the XING MP3 header. I am not sure how much that is still used these days... But it is relatively simple to add this to an MP3 file, and used to be quite popular. See e.g. here for a description and sample code: <http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx>.


Or we could record the data in a separate file. What is nice about this is that the MP3 file does not have to be modified to add this cache data. It would also require hand-rolling our own tools.


Bye,
Max