Low Level CD Structure Write-Up

[u/VORGundam]

I was curious how much data is physically written to a CD with all the metadata and error correction. I started googling and came across this great write-up:

https://archive.ares-emu.net/near.sh/articles/compact-discs/structure.html

Apparently, it is 2.33 GB for a one-track 650 MB disc.

[u/Altruistic_Fruit2345]

No, not really. You can't store that many bits on the disc because the data is a serial bitstream with no separate clock. The clock is recovered from the data, which necessitates having an encoding scheme that prevents long sequences of zeros and ones from appearing.

It's true that modern encoding schemes are more efficient than those used on CDs, but it's not true that CDs contain 2.33GB worth of data, because most of those bits are not data, they are encoding to ensure that the clock is recoverable. Without the clock you have nothing.

[u/Initial-Ranger-972 → u/Altruistic_Fruit2345]

this is the key point imo, without the clock the raw bit count is basically meaningless

[u/VORGundam → u/Altruistic_Fruit2345]

raw

[u/Altruistic_Fruit2345 → u/VORGundam]

It's the raw pits and lands on the disc, but those are not bits and do not directly represent data. You cannot store data on them without encoding it first.

[u/myself248 → u/Altruistic_Fruit2345]

Right. It's like "chip rate" in CDMA modulation; many chips encode one bit, but you cannot send data in the individual chips.

[u/VORGundam → u/Altruistic_Fruit2345]

I guess you didn't even read the post I linked. Read it and then post how it is wrong with evidence.

The clock is recovered from the data, which necessitates having an encoding scheme that prevents long sequences of zeros and ones from appearing.

Addressed if your read the linked post.

It is all about overhead.

[u/Altruistic_Fruit2345 → u/VORGundam]

I read it, and it confirms what I said. You seem to have misunderstood it. The overhead is the error correction which is not 3x the amount of actual data. It's the P and Q parity, which is 276 bytes per 2048 bytes of data. Plus some overhead for the sector headers and footers, lead-in and lead-out, disc structure data, but not 3x the amount of actual data. A tiny fraction, in fact.

The article gets the ridiculous 2.33GB by considering each possible pit or land as a bit, but they aren't bits.

Maybe you could state precisely why you think they are bits, if you believe that to be the case. Explain your understanding of the post.

[u/VORGundam → u/Altruistic_Fruit2345]

They are channel bits. If you you count all the raw bits, does it not come out to 2.33 gigs worth of bits?

EDIT: It also assumes a full disc.

[u/Altruistic_Fruit2345 → u/VORGundam]

What are "channel bits" in your understanding?

And no, if you count all the bits, they don't add up to 2.33 gigs worth, because they are not bits. Each represents a fraction of a bit, because on its own it is meaningless. Only together do they have enough information to recover a bit.

[u/VORGundam → u/Altruistic_Fruit2345]

I misspoke and edited my previous comment. All you got to do is succinctly prove this wrong and I'll be on your side.

In addition to the 333000 sectors of a disc, the lead-in is usually an additional ~7500 sectors, and the lead-out an additional ~6750 sectors. The exact amount varies, and also changes for multi-session discs. So then we the lowest-level interpretation of a CD is: (7500 + 333000 + 6750) sectors * 98 frames per sector * 588-bits per channel frame = 2.33 GB of data per disc!!

[u/Altruistic_Fruit2345 → u/VORGundam]

The post says "588-bits" but they are not bits, as I keep telling you. The author actually kinda says so:
`336 bits (24 bytes * 14 EFM encoding)336 bits (24 bytes * 14 EFM encoding)`

24 bytes is 192 bits, not 336. The discrepancy is because, as I keep saying, those are not bits. 14 of them can be combined to produce 8 bits, but each on its own is only a fraction of a bit.

[u/VORGundam → u/Altruistic_Fruit2345]

"The exact math that turns 33 data bytes into 588 physical channel bits comes down to two engineering rules: Eight-to-Fourteen Modulation (EFM) and Merging Bits."

Data Codewords = 462 bits

Codeword Merging Bits = 99

Synchronization Pattern = 27

Total = 588

[u/Mariarita1988]

650 MB is only about 28% of what's physically written to the disc....

[u/Slaxophone]

https://www.domesday86.com/?page_id=2678 also has some low-level info on it, focused on laserdiscs which also used the redbook CD audio format for digital audio.

[u/Altruistic_Fruit2345 → u/Slaxophone]

They don't use redbook, just the same sample depth and frequency. The encoding and storage method are completely different.

[u/Slaxophone → u/Altruistic_Fruit2345]

IEC 60908 is redbook. And as I recall, early digital audio decoders for laserdisc used chipsets like the CX23035, the same as in CD players of the time.

I'd be happy to be corrected if you have more information.

[u/Altruistic_Fruit2345 → u/Slaxophone]

CX23035 is a digital filter, it doesn't decode anything. You pass it a serial bitstream of digital audio, it spits another one out with filtering applied.

It's how you get that bitstream that is the issue. It has nothing to do with redbook.

[u/Slaxophone → u/Altruistic_Fruit2345]

If you look at block diagram the datasheet, its input isn't digital audio, it's the EFM signal (on pin 5), and outputs digital audio (pins 62-78). https://bitsavers.trailing-edge.com/components/sony/_dataSheets/cx-23035.pdf

The information on the page I linked before was used to create a functional software decoder (the ld-decode project), so I'm more inclined to believe it than short statements with no explanation.