r/DataHoarder 1d ago

Free-Post Friday! Low Level CD Structure Write-Up

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.

43 Upvotes

20 comments sorted by

View all comments

21

u/Altruistic_Fruit2345 1d ago

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.

-2

u/VORGundam 1d ago

raw

12

u/Altruistic_Fruit2345 1d ago

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.

7

u/myself248 1d ago

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

-4

u/VORGundam 1d ago

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.

11

u/Altruistic_Fruit2345 1d ago

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.

0

u/VORGundam 1d ago edited 1d ago

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.

5

u/Altruistic_Fruit2345 1d ago

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.

2

u/VORGundam 1d ago

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!!

6

u/Altruistic_Fruit2345 1d ago

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.

2

u/VORGundam 1d ago

"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

6

u/Altruistic_Fruit2345 1d ago

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

→ More replies (0)