DVDs & CDs

CDs

CDs are hand-sized disks storing digital audio in their physical microscopic structure (caveats later), aiming to be resilient to scratches and other ways routine handling can damage their data. Here I’ll explore my understanding of how the circuitry in a CD player converted the laserlight reflected by the disk or not as it spun past into soundwaves for you to enjoy.

But first: CDs need to keep their laser focused on the correct track!


The main photosensor’s split into 4 segments for anologue math to compare intensities to see if the beam’s been shaped into a vertical or horizontal ellipse. If so it adjusts the voltage to an electromagnet moving the laser lens closer or further from the disk to keep proper focus.

There’s two techniques to ensure it remains focused on the correct track. Early machines used those sensors to determine if the track has shifted left or right, so it can make adjustments to a swing arm.

Technology Connections had an early Magnabox which used that approach (above in thread), and split this task amongst multiple chips. Though today basically everything discussed today is in 1 chip with the photosensors.

The other approach to “tracking” a CD is to add 2 more photosensors which when triggered indicates it moved to close to the neighbouring trackers & the laserlens should be shifted away.

Combine & amplify photosensors to get a NRZI 8-to-14 CIRC 16bit 44.1khz stereo digital audio.


Once a clock’s lined up to the edges read off the CD (by comparing to variations upon a second clock) we use a JK-flipflop toggled upon said edges to generate a digital signal that can be written into a shiftregister. Thus decoding the NRZI component of the data.

To ensure there’s enough edges (seperated by 2-10 bittimes) every 14bits are looked up (ignoring additional 3bits) in ROM to produce a byte. “8-to-14 modulation”.

Now to protect the digital data from scratches!


Every 33rd “control” byte (ignoring 2 preceding “sync” pseudo-bytes) is removed from the stream & sent elsewhere (with a clock) interpreted as 8 98bit numbers. The first two bits of which are a special sync word. The 1st determines whether audio should be muted, and the disc should stop spinning, as does invalid prefixes on the 2nd. The 2nd can readily be rendered to an 8-Segment Display to show time & track numbers if CRC16 passes.

The other 32bits are CIRC decoded!


I’m finding it difficult to find anything that documents Reed-Solomon Coding legibly to me. But judging by imagesearch diagrams, I think its as to CRCs as Hamming Codes are to Parity Bits. I’ll explain what I mean by that…

CRC is a variant of a shiftregister which inverts certainbits upon shifting out a 1. Mathematicians view this as “finite-field polynomial division” to reason about its error-detection capabilities. Upon decode expect the computed to CRC to be 0.

If I understand those diagrams correctly Reed-Solomon Coding involves XORing the delayed data with specially chosen CRCs. With (if its akin to Extended Hamming Codes) another CRC to help detect errors that process couldn’t detect, in which case I’d use a subtract-shift-add to interpolate missing data.

Once consulted drop the CRC bytes from the stream.

To turn this into Cross-Interleaved Reed-Solomon Coding (CIRC) rearrange output bytes to spread out impact of scratches.

CDs use 2 overlapping Reed-Solomon Codes so they can recover from longer scratches. Also there’s RAM involved in that process.


Now we’ve got raw 16bit 44.1khz stereo raw digital audio! (CDs don’t have compression)

Send that through a Digital-Analog Converter (resisters connected to common output wire), a low-pass filter (output between a resister & capacitor), & amplifier (transistor).

Incorrectly assuming perfect low-pass filters on recording & output Claud Shannon, amongst others, proved this can perfectly recreate any sound with frequencies less than 22.05khz. We can’t hear frequences >20khz at best.

Bibliography

Closest public doc to a primary source: ECMA-130: https://www.ecma-international.org/publications-and-standards/standards/ecma-130/

Technology Connections: https://invidious.snopyta.org/watch?v=3yJqlD9RxD4

Ben Eater: https://invidious.snopyta.org/playlist?list=PLowKtXNTBypFWff2QjXCWuSfJDWcvE0Vm & https://invidious.snopyta.org/watch?v=h0jloehRKas

3Blue1Brown: https://invidious.snopyta.org/watch?v=X8jsijhllIA

Xiph.Org: https://invidious.snopyta.org/watch?v=cIQ9IXSUzuM

Wikipedia: https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio

Seriously everyone other than Ben Eater & 3Blue1Brown seem to either be explaining error detection/correction to mathematicians as opposed to software devs, or providing mystifying non-explainations!

CD Variants

Yesterday I described how (my best understanding) the laserlight reflected or not by a CD is converted into sounds you can hear. Today I wish to run over some of the ways CDs got extended.

Which boils down to 3 different tactics:

  1. Connect it to a computer/software to do something with.
  2. Control other aspects of the CD reader.
  3. Store data in the “subcodes” alongside the audio.

Also there were attempts at adding compressed audio (superaudio CD, CD-MIDI) but that didn’t take off.


In place of audio CD-ROMs stored a “HFS” filesystem standardized through ECMA & the ISO, and other digital intended to be read by software on your computer. These were split accross 98 CIRC-frames with a prefix encoding a synchronization pattern, a bit of structoral metadata & optional error detection. These bytes are further rearranged to further spread out the impact of scratches.

Upon CD-ROMs were built videogame consoles like CD-i (& in turn VCD akin to DVD, Photo CD), Playstation, etc.

These videogame consoles read software off the disc to be run directly on a known computer architecture. CD-i was essentially a console written up as a proprietary standard, at which point I’m not surprised Playstation succeeded over it.

CD software had to cope with how slow it was to read the CD’s immense data storage (similar challenge to what I’m toying with when designing hypothetical hardware) for the time. Usually this was solved by a progressbar, but Crash Bandicoot & Myst are more interesting.


As for controlling other aspects of the CD reader…

Controlling the sled, or (adjustments must be incorperated) swing arm hold the laserreader, can seek between tracks, in reference to data read from the initial muted segment. Binary searched timestamps with a hueristic, usually via a CPU.

Controlling laser intensity can burn away reflectivity of a die in the disc, or melt away existing data. Requires special tracking.

Playstation tapped the adjustments for purposes I don’t approve of. It compared against an expected a value as a form of DRM.


And finally those 6 remaining “subcodes” left 16 floppy diskettes worth of data just sitting there, so how to use those?

CD-Text allows storing textual provenance metadata alongside the audio, I’m surprising it took the so long to add this. Or that my copy of ★ doesn’t have it.

And CD+G (& CD+EG) allows storing highly-compressed graphics for karaoke machines to be sent to sent to a 4bit-colour tiled graphics cards.

Bibliography

Wikipedia: https://en.wikipedia.org/wiki/Rainbow_Books

Technology Connections: https://invidious.namazso.eu/watch?v=TCTWyNstpD0

And I once again referred to ECMA-130. Couldn’t be bothered reading their HFS spec, which led them to rewrite The Yellow Book as ECMA-130 so they weren’t building on a closed standard.

DVDs

Once we managed to fit an hour+ of music onto a CD, we wanted to do similar for feature films. But even once we stuffed an order of magnitude more bytes than CD’s already impressive capacity, and doubled it again by layering 2 discs in the space of one we still didn’t have enough space to store a raw 1.5hr+ digital video. So we turned to compression!

All of this would theoretically have reduced DVD’s damage-resistance…

So how do compress movies & make them interactive?


I’m working from the best public info available on this proprietary DRM’d standard.

DVDs stored MPEG-2 videos with CD, DTS, MPEG-2 Layer II, or (which they liked to brag about) Dolby audio in a custom container format within a UDF (or HFS) filesystem. The process for reading & error-correcting the data off the disc is essentially as for CDs, just with a finer-focused laser! Presumably UDF & DVD-Rs aided authoring DVD menus…

VIDEO_TS/VIDEO_TS.IFO stores data on how to start playing the DVD, .BUP holds a backup, & .VOB if present initial video (usually a copyright notice).

The IFO files contains the interactive features, VOB contains video/audio.


An MPEG file (as stored on DVDs, its a highly flexible standard) essentially uses JPEG to store its individual (“I”) frames. Which would’ve made it convenient for DVD players to render a slideshow of JPEG DVD-ROMs! Incidentally digital TV uses MPEG too, so it’d make sense to combine digital TV decoders/DVD players.

JPEG Huffman-decodes blocks of 8x8px & applies a “quantization matrix” (multiply-sums?) which MPEG’s P- & B-frames will shift around onscreen with Huffman-encoded adjustments.


Hardware-wise this isn’t too demanding though it does require RAM to store the Huffman-tables, current frame, & previous frame. Could reasonably hardwire the logic, especially the quantization matrix!

JPEGs & MPEGs are in YCbCr colourspace. Which incidentally broadcast colour TV always was, in part to maintain compatibility with grayscale TV. So colourspace conversion can be handed off to analogue arithmatic in the TV…

Subtitle & menuoption sprites need to be composited above the video.


Also between anologue frames DVD players could on-request generate broken signals (analogue DRM, could buy defeat devices as long as they didn’t admit to why broken signals were a problem) & digital closed captions for your TV to optionally composite onscreen.

Once a video finished playing a “programme chain” would be consulted as to which video or menu to display next with which tweaks. Including multiple “angles” + audio tracks, & registermachine bytecode (no RAM).


Having decent RAM seems like enough to accelerate most of this decoding, hardware-wise I guess most DVD players were little more than CPU, RAM, & a DVD-reader with appropriate output sockets. Which matches the circuit boards I’ve seen.

Bibliography

My main source (might overwhelm you with detail, all reverse-engineered): http://dvd.sourceforge.net/dvdinfo/index.html

Also, Wikipedia: https://en.wikipedia.org/wiki/DVD-Video

And there’s lots of docs about MPEG, I don’t know which to cite! Also Technology Connections had a couple asides relating to DVDs in some of his videos, which made their way into this thread.

Worth noting: Basically all the intelligence in DVDs where in the DVD authoring software, not the DVD player.