On Mon, Dec 10, 2001 at 05:54:07PM -0600, Munir Nassar wrote: > On Mon, 10 Dec 2001, Bill Layer wrote: > > > So is any binary image of a cdrom considered an ISO image? That doesn't > > really make sense if you think about it. For instance, wouldn't a binary > > image of a Mac HFS disk be an HFS image? (Mac cdroms need to be mounted -t > > HFS and not iso9660) What about a binary image of a game disk that has > > some readable files, but 75% of the game data in some (invisible) raw > > format; would that be some sort of hybrid image? > > Actually it makes perfect sense if you think about it, consider this: A > Compact Disc consists of the Plastic Plater with pits in it and a > reflective metal (simply put that is) > > now consider each pit a 0 and each non-pit a 1, dd should be able to read > the pits and non-pits as a binary stream and save it to disk as an image > (call it .img or .iso it makes no difference) > > now concerning HFS, Juliet, or RockRidge or what it is, it just like the > difference between a elf and MS-DOS executable, both are binary files made > up of zeros and ones but it is how the zeros and ones are arranged that > make them different. This reply is not a flame at all, but the first part of your answer is not at all accurate. I'll talk about the first part second. To talk about the second part first, ;) only those files conforming to the ISO-9660 spec set by the International Standards Organization are considered an ISO. Whether someone bastardizes the term to mean a "CD image" is entirely different. That's why HFS or ISO are different to mount. There are other ones out there, too. As to physical storage: (First part) CD-ROM is not stored in anything even remotely resembling raw data. It is encoded with Eight to Fourteen modulation, then Cross-Interleaved Reed-Solomon Code. The net result is that in terms of pits (1's and 0's) a CD-ROM has about 2 and a half Gigabytes worth of pits, but by design only 650MB of data. The simplest way of thinking of it is that if the data are recorded 7 times, one of them is likely to read back. The more complicated way of explaining it is that there's a pattern to how they are duplicated, so that you can get what you were after by seeing how close what you actually get is to something that would be expected. The upshot is that the data isn't even recorded in 8 bit bytes, nor in order. I don't know about dd, but there do exist tools that copy one SCSI device to another in just plain raw data -- copy protection code and all. I used to have one -- but it wasn't a PC (any OS) toy. I see no reason why Linux couldn't support such a thing, but you wouldn't even bother mounting the device. Just use SCSI commands and keep it pure I/O. Sorry -- optical storage is one of my big areas of geekdom. :) I don't assume anyone cares. -- "Trying to do something with your life is like sitting down to eat a moose." --Douglas Wood