CPU IO access speed and memory transfer delay, in a world before the advent of DMA. There’s a reason that game consoles of the era had dedicated “Audio Process

CPU IO access speed and memory transfer delay, in a world before the advent of DMA. There’s a reason that game consoles of the era had dedicated “Audio Processing Units” that rendered sound directly from sequencer instructions + a small set of loaded samples: trying to feed “one large continuous sample” (i.e. a raw PCM stream) through the CPU to a DAC, wouldn’t have left any time for doing actual logic. If you compressed the audio, decompressing it would take the whole CPU too. Sure, CD-ROMs weren’t usually continuous streams of data in the way that audio CDs were; but the kinds of stuff that couldn’t just be usefully fit into a floppy — or a set of floppies installed onto a hard drive! — was usually asset files that were individually large in the same way that PCM audio was individually large, in a way that would still choke either CPUs or RAM. No point in large image files you can’t even display. There were a few consumer use-cases for random access to individually large files — mostly public databases, of the kind we’d expect to find online today. But people who really needed these, either did use them “online” even back then (by dialing in directly to mainframe database services); or, if they were a more industrial consumer, they got these distributions on tape! These were the first things to be ported over to CD-ROM when CD-ROM drives did start becoming available. The whole “multimedia” hype took a bit longer, only really taking off once high-quality images and low-quality video were able to actually be displayed on PC (requiring PCs to first achieve display resolutions higher than 640x480; color depths higher than 256-color; at least 2MB of VRAM; and CPUs fast enough for MPEG1 decoding of at least small 100x100 video clips.)