Agree. This also prevents problems in the first instance in the case that the CD has any read-errors, otherwise you will run intor problems if during playback sometime the CD stops playing. But this means that you possibly needs lots of ram, you know how much uncompressed audio takes up, at 44kHz stereo 16bit, thats 172kB/s, means 6seconds auf audio will eat 1MB RAM. And thats only for one song mapped at one turntable/cd ;-)

To expand on nik's point, I should first point out that our buffers are 32-bit, which is twice the normal CD resolution. This means that a 5-minute CD track would fill 4x2x44100x60x5 bytes of memory, which is 101Mb. Two of these tracks would obviously fill 200Mb, not to mention 10 minute trance tracks. We would massively increase the required memory if we buffered entire tracks.

Also, I don't get the point... nobody expects their CD player to keep playing a track when you eject the disc, so why not just leave it in there until you're done with it? If you want to play a CD track without the CD present, you should really rip the tracks.

But what about the point that the CD might have a read error? About the massive amount of RAM which is needed, well IF anyone needs this pre-loading THEN he has to make sure he has enough RAM, thats up to him.

Scratch LIVE already buffers decoded / ripped-on-the-fly audio. Perhaps the best solution is a preference for how much RAM to dedicate to buffering.

yes a preference to set how much ram to dedicate to buffer is a really great idea