4 ms·
Well, Philips did actually define these capabilities in a standard known as "Extended Architecture" (XA). CD-XA introduced Mode 2 sectors, which could hold 2048
by spicyjpeg 4y ago
Well, Philips did actually define these capabilities in a standard known as "Extended Architecture" (XA). CD-XA introduced Mode 2 sectors, which could hold 2048 bytes of data with ECC, 2324 bytes of custom data without ECC or even a chunk of ADPCM compressed audio to be played directly by the drive without intervention of the host CPU. ADPCM sectors could be "spread out" throughout custom data, so the drive would play them while the host would only receive the non-audio data (such as video frames). Multiple ADPCM tracks could also be interleaved, allowing playback of compressed audio at the same drive speed as regular CD audio with no need for buffering.
Now, CD-XA unfortunately didn't take off... or did it? It was initially only supported by the failed Philips CD-i, but it turns out that a few years later Sony would reuse most of the technology for their upcoming game console. That's right, the PlayStation 1 made heavy use of XA and of its audio capabilities; the system's native video format was in fact a custom container format interleaved with XA ADPCM audio, and many games took advantage of the ability to interleave multiple audio tracks as well.
Video CDs also used 2324-byte Mode 2 sectors without ECC by the way, but I'd say their popularity was far below that of the PlayStation 1.
- bsenftner 4y agoFWIW, CD-XA's presence in the first PlayStation might be due to my influence. I was the "Philips streaming guy" hired by Sony who worked with the streaming libraries and the OS subsystem devs in Tokyo, during the development of the initial PlayStation OS. In a series of architectural design meetings I helped their developers understand the whys and hows of real time files and the architecture necessary within the OS to support them.