3 ms·

I was at Philips during an R&D period experimenting with alternative data formats for CD ROMs. A capability I liked that never went public was removing the err

I was at Philips during an R&D period experimenting with alternative data formats for CD ROMs. A capability I liked that never went public was removing the error correction portion of sectors of data, transforming the 2K per sector into something slighter bigger 2356 bytes. Anything to get more bits off the disk back when it was limited to 128K per second. This was interesting because it allowed the developer to selectively say "this data can survive some data loss, and it's fine". Another feature that never went public was "real time files" - multiple files interleaved sector by sector on the disc such that at a given time after a "real time file play" has begun you're guaranteed the data from the interleaved files are in memory, with per-file-sector callbacks if requested. (And if you wanted, the different files could have full error correction or not, 2K or bigger sectors selectively.) Never used for, but would have been great for loading game levels where multiple files land all over memory, but streamed all at once.

interroboink 4y ago
Games definitely had custom "put this data on this sector" software, for authoring their gold masters. Generally, data that was needed fast was on the outer tracks, since they spin faster and can have lower seek times. Something less time-critical like background music would be on a slower part of the disk, streamed incrementally. If I'm remembering right — has been some years.
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 ago
  FWIW, 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.

interroboink 4y ago

Games definitely had custom "put this data on this sector" software, for authoring their gold masters. Generally, data that was needed fast was on the outer tracks, since they spin faster and can have lower seek times. Something less time-critical like background music would be on a slower part of the disk, streamed incrementally. If I'm remembering right — has been some years.

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 ago
FWIW, 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.