[Scummvm-devel] Idea: IndexedMp3AudioStream

[yotam barnoy]

> So I am not sure how this would help the "looping" subject you talk
> about, since I think many engines just use makeMP3Stream etc. directly
> (especially since the datafiles are usually embedded). Anyway as you
> later on say you never had any problems with looping except for audio
> cd emulation, so I wouldn't touch this.
>

Fair enough.

>
> Best example is of course the DC port or the PS2 port here, where game
> path is on CD usually, so no real possibility to write to it :-P.
>

So I was thinking for the DC/PS2 it would be disabled and those files
would be transferred from PC. But of course a tool is a better option.

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

I agree that ID3 looks like it could be an even better solution, Michael!

Yotam