In the CD Recordable FAQ section [3-51] (http://www.cdrfaq.org/faq03.html#S3-51) the author warns about making copies using RAW reads and writes. This concept is touched on in other places in the document as well. Basically, he says that if you read in RAW mode your errors are not corrected and so they'll stick that way when you write RAW back out. If the program were correcting after reading RAW, that would defeat the point of reading RAW, which is to capture anything that's other than the normal values for the sectors. Is this an issue in practice? I suppose for making legitimate back ups you will only have one generation, not generational loss from copies of copies, and it will only kill the copy if the read error occured in the special copy-protection sector. And the disc copy will simply be more fragile having the read errors of the first built-in. --John
You're not completely correct. If you do not read RAW you only extract the data content of the sector (the famous 2048 bytes for MODE1 and MODE2 Form1), as you well know. If you read RAW you perfectly copy on your HD the ECC/EDC (Error Correction & Error Detection Codes). The problem of re-calculating the ECC/EDC lies in the WRITING phase! During WRITING your burner will re-calculate the ECC/EDC, thus spoiling part of the RAW extraction, except the fact that - the boot sectors are copied; - each file of the copy lies in the same LBA that the original file used in the original disc; Therefore a copy obtained from a RAW image is much more similar than a non-RAW one. Some old copy-procection schemes check the files LBA, so these schemes are defeated by a RAW extraction with subsequent non-RAW burning. If you DO NOT want ECC/EDC to be recalculated you need to *write* RAW DAO. Not all burners are capable of doing this. This burning option will bypass more sophisticated protection schemes (the ones hidden in the ECC/EDC). This copy is 'almost' a 1:1 copy of the original CD (except for the subchannel part, for this you need .SUB extraction and RAW DAO 96 burning option). Again, even RAW DAO 96 (2448 bytes/sector) will not create a *perfect* 1:1 copy. The data content is IDENTICAL, but physical info such as the media type (burned CD-R, as opposed to 'printed' discs) is different. Some protection schemes (CD Check, for instancd) are capable to detect - it seems - the physical angle between the CD-reader laser and the CD track! These info cannot be reproduced, so making a backup of this kind of protected CDs needs hacking (No-CD patches). PS Your interest to this topic is awesome, I think I'll candidate you to a promotion to 'member' status....
What's "LBA"? > Your interest to this topic is awesome, I think I'll candidate you to a promotion to 'member' status.... Thank you. What does that mean? --John
LBA means Logical Block Address. It represents the address of the CD sector in which the file begins. You know that a 74 min CD is made by 330,000 sectors (and 80 min = 360,000 sectors). You might compare the CD-ROM to a big box divided in little cells, 2352 bytes each. When you burn files on a CD you 'put' bytes into that cells. The CD usually needs the first 20-22 sectors to write the system files (Table Of Content, System boot identifier and so on). After LBA 22, (LBA 23 and greater ) all blocks are available for files. For instance, imagine to burn an audio file. A 16,475,463 bytes AUDIO file will occupy 16,475,463 / 2352 = 7005 sectors on the CD. So, the burner will write the file in blocks 23 to 7027 (0-22 are occupied). The audio file LBA will be 23 and the next file burned on the CD will occupy the LBA 7028. This will go on until the disc is closed. If you open a CD image (or even a CD-ROM) with, say, Isobuster, you'll notice that type of hyerarchy. Each file has an identifier, called LBA, and a size, often expressed in blocks or bytes. Please note that DATA files, that need error correction, occupy more blocks. A 16,475,463 bytes DATA file will occupy 16,475,463 / 2048 = 8045 sectors. So a data file written at LBA 23 will occupy the sectors 23-8067 and next file will have LBA 8068. The buener will put 2048 data bytes in each sector (that keeps on being 2352 bytes large), completing the remaining space with header, subheader (if MODE2), ECC, EDC.
