[Scummvm-devel] Idea: IndexedMp3AudioStream

[Johannes Schickel]

On Thu, Oct 7, 2010 at 2:38 PM, Michael Madsen <michael at birdiesoft.dk> wrote:
> I'm not really familiar with the sound system, so perhaps more than this is needed - but one option could be to take advantage of ID3 tags.
>

Well in this case it's pretty simple:

We have two functions which cause problems for Yotam:

"getLength" which returns the length of an stream. To be precise how
the length is calculated for an MP3Stream object. Currently we seek
through the whole file when we open an mp3 file (and only when we open
it, a call to getLength after that will always result only in the
length being returned and no processing whatsever!) and calculate the
length based on that.

"seek" which is able to seek at an abitrary point in the stream. For
MP3Stream we currently have the problem, that it always first rewinds
the mp3 stream to the start and then seeks till the requested time is
passed/reached. For big MP3 streams and seek positions a bit into the
stream this might take a long time on devices with slow I/O or the
like.

> ID3v2 defines a TLEN field which is intended for the length of an MP3 file in milliseconds (as a string). It should be possible to make a tool which creates and fills in this field, and then MP3Stream can simply check if this field is present and only need to seek through the entire file if it's not.
>
> We can also use the TXXX field for our own data, so if, for example, we need a frame count, we could place that there - or we could use ID3v2.4, which allows multiple values in the TLEN field, separated with a NULL character.
>

That would be perfect. This would at least reduce the opening time for
mp3 streams by a lot, since currently we seek through the whole file
to determine the length. Do a lot of the audio cd rippers out there
already add that? Actually if the information could not be found we
could still fall back to the seek approach.

So TXXX can be used for user defined data? We might embed seek
positioning data there then too.

> This *does* rely on the MP3 file not being edited after we tag it, but it might be an acceptable way of dealing with the getLength call.
>

Yeah actually I prefer that over the index file, since it would not
rely on an external file, so we might take advantage of this in all
our mp3 files outputted by the various compress_foo tools.

//  Johannes