5 ms·

Which bytes? A raw 2352 byte copy that includes the P and Q channels (timing) can behave differently than a 2048 byte copy depending on the software.

by snarfy 6y ago

harry8 6y ago
Ok but why should we care about that in copying? This is my mental model for what's going on: There's a bunch of bytes stored on a CD-ROM in a defined order. Zeroes and ones. Copy them in order. You should now have a file on magnetic disk or flash that is precisely those byes in precisely that order. Anything that can make sense of one should be able to make sense of the other. What am I missing here?
- snarfy 6y ago
  There is more than one set of bytes. You may not care about copying the inode structure when you are copying your files from point a to point b, but you should when you are cloning the disk. Many times the software on the CD is looking at the physical layout of the disk, not just the logical data, to function correctly.
  - harry8 6y ago
    So filesystem meta data is being copied that references the physical cd but it's no longer associated with that cd once copied to magnetic storage? Is that what's going on here?
    - blincoln 6y ago
      No. Please see my other post in this thread. I'm struggling to think of a non-technical analogy, but basically what's going on here is that most data-copying tools, when used in the most common ways, are looking at CD-ROMs like they would look at the logical disk presented by a RAID5 array. That works fine most of the time. But imagine if the computing industry had come up with a "RAID5 Mode 2" that was actually RAID0, where the parity disk was just used to store more user data instead of parity data, but most of the copying tools didn't know the difference between "RAID5" and "RAID5 mode 2", and so they just copied 2/3 of the data, on the assumption that the parity data would be recreated on the receiving end. 1/3 of the user data just went down the drain. That's basically what's happening when you try to store anything other than a 100% vanilla data CD-ROM as an ISO file instead of bin/cue.

Which bytes? A raw 2352 byte copy that includes the P and Q channels (timing) can behave differently than a 2048 byte copy depending on the software.

by snarfy 6y ago

Which bytes? A raw 2352 byte copy that includes the P and Q channels (timing) can behave differently than a 2048 byte copy depending on the software.

harry8 6y ago

Ok but why should we care about that in copying? This is my mental model for what's going on: There's a bunch of bytes stored on a CD-ROM in a defined order. Zeroes and ones. Copy them in order. You should now have a file on magnetic disk or flash that is precisely those byes in precisely that order. Anything that can make sense of one should be able to make sense of the other. What am I missing here?

snarfy 6y ago
There is more than one set of bytes. You may not care about copying the inode structure when you are copying your files from point a to point b, but you should when you are cloning the disk. Many times the software on the CD is looking at the physical layout of the disk, not just the logical data, to function correctly.
- harry8 6y ago
  So filesystem meta data is being copied that references the physical cd but it's no longer associated with that cd once copied to magnetic storage? Is that what's going on here?
  - blincoln 6y ago
    No. Please see my other post in this thread. I'm struggling to think of a non-technical analogy, but basically what's going on here is that most data-copying tools, when used in the most common ways, are looking at CD-ROMs like they would look at the logical disk presented by a RAID5 array. That works fine most of the time. But imagine if the computing industry had come up with a "RAID5 Mode 2" that was actually RAID0, where the parity disk was just used to store more user data instead of parity data, but most of the copying tools didn't know the difference between "RAID5" and "RAID5 mode 2", and so they just copied 2/3 of the data, on the assumption that the parity data would be recreated on the receiving end. 1/3 of the user data just went down the drain. That's basically what's happening when you try to store anything other than a 100% vanilla data CD-ROM as an ISO file instead of bin/cue.