[Scummvm-devel] Idea: IndexedMp3AudioStream

[Johannes Schickel]

On Thu, Oct 7, 2010 at 3:27 PM, yotam barnoy <yotambarnoy at gmail.com> wrote:
>> Well I mean we could say that for improved performance people should
>> use CBR files on devices with slow I/O. And if that helps seeking /
>> length calculation it might be the easiest way out.
>>
>
> That's true. The easiest solution would be to have CD audio games use
> only CBR for performance, and then to modify the code to take
> advantage of that (which is trivial). Can anyone comment on the
> realistic impact this might have audio-wise? Also is it possible to
> convert a VBR file into a CBR file so people don't have to rip again?
>

I don't know whether it's really worse, but after all we are talking
about portable devices here, I doubt someone has real HiFi equip
connected to them for sound ;-).

I guess a VBR -> CBR conversion might be possible, but quality wise it
should be worse than reripping.

>>
>> I am actually not sure at all why we need to horrify our code when you
>> say you never had any problems except with CD audio tracks. I mean
>> when you have indexed the MP3 files for the audio cd emulation that
>> should take care of all the looping code too, since the looping code
>> just uses the SeekableAudioStream API. But maybe you have a good
>> reason why you want to change the looping code too?
>>
>
> Wow. Horrify is such a strong word :) I'm just thinking of
> performance. While there isn't a big delay, knowing the PSP has to
> read every small sound file beginning to end before playing it makes
> my neurotic optimization-sense tingle. Also, a game might have a
> looping sound that's really big and actually have a sizable delay.
> Though I haven't encountered said game yet.
>

Well for simple looping (i.e. looping the whole file) the stream
length is never retrieved. Just check the LoopingAudioStream
implementation and "AudioStream
*makeLoopingAudioStream(RewindableAudioStream *stream, uint loops)".
So if you would decide on only calculating the length the first time
getLenght is called (which might be a bit of a hackery since that
method should be const...) that should help for simple looped audio
streams, since the initialization delay would be shorter then. But of
course when we have an index file or that ID3 tag that should be no
problem anymore.

On the other hand sophisticated looping like in SubLoopingAudioStream
will need the end time (if it's 0 it currently retrieves the real
length via getLength, instead of having special code inside the
SubLoopingAudioStream::readBuffer implementation, might be possible to
have special ifs in readBuffer to handle that though).

Anyway for SubSeekableAudioStream one definitly needs the end time,
since of course otherwise it couldn't properly implement getLength
itself. And that is actually what the audio cd emulation is using.

Actually I definitly think that "hacking" our audio stuff just because
we do not have a solid MP3 stream implementation currently is the
wrong way. So if we have the mp3 implementation taking advantage of
ID3 or an index file and then there's still big delays caused by the
audio stream code and not a poor mp3 implementation I will make sense
to look at the more general code.

// Johannes