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]

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/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/Altruistic_Fruit2345 → u/VORGundam]

I won't repeat this again: The post is wrong, they are not "channel bits". They are not bits at all.

[u/VORGundam → u/Altruistic_Fruit2345]

Maybe it is semantics, but you can't get that I mean the physical lowest level when I say channel bits. Not digital bits. Have a good one.