CloneCD Guide - Page 12

FAQ

What is exactly MMC DAO RAW?
RAW-MMC-DAO is the technology CloneCD uses to make perfect copies. It doesn't use any CUE sheets or similar. The data is streamed to the writer from the begin of the lead-in up to the end of the lead-out in one go. The SubChannel data is transmitted too, so the blocksize is 2448 bytes instead of 2352.

As I heard there are 2 RAW DAO modes. What are their main differences?
There are 2 RAW DAO modes. DAO RAW 96 and DAO RAW 16. DAO RAW 96 is only necessary for LibCrypt and DAO RAW 16 handles everything else. Few drives support only DAO RAW 16 (like HP 8250 and newer Philips drives). Plextor/Sony CRX support only DAO RAW 96. Mitsumi and Ricoh have both. You can tell if a drive has DAO RAW 16 if the "raw" checkbox in CDRWin works. DAO RAW 96 is the "supports CD-G and CD-TEXT" in CloneCD compatibility list.

LibCrypt doesn't REALLY need the R-W SubChannels. Like SecuROM, the protection is stored in sub-Q. You can read as RAW 16. So CDRWin can read SecuROM and LibCrypt just not in the normal "BIN/CUE" way. You have to do "read sectors".

When *writing* in 16 byte mode, the drive corrects the CRC of sub-Q. When writing in 96-byte mode, the drive doesn't correct anything. The extra 80 bytes (Sub R-W) don't do anything helpful for LibCrypt/SecuROM. 96-byte mode just disables CRC correction, and that's all that LibCrypt needs more than SecuROM!

What is exactly MMC SAO RAW?
RAW-MMC-SAO is the technology, which CloneCD uses in order to be compatible with recorders, which not support MMC DAO RAW writing. It does not use any CUE sheets or similar. The data are transmitted to the writer by sessions. The MMC SAO RAW writing has the following restrictions (which do not apply to DAO-RAW mode):

- Multisession is not allowed yet; therefore CD-Extra and Photo CDs can't be copied with this mode.
- "Crazy Disc Layouts" can't be written. This is a restriction of SAO writing, not of CloneCD!
- Any copy protection relying on SubChannel Data will probably not be copied. This is a restriction of SAO writing, not of CloneCD!
- Media Catalog Numbers (MCN) and International Standard Recording Code Numbers (ISRC) will not be recorded yet.
- Indices and Pauses on Audio CDs will not be recorded yet.
- Depending on the recorder model, Tracks smaller than 4 seconds and Enhanced CDs can't be recorded.

Will TAO be supported ever?
As CloneCD author said: "…I already have written a TAO write engine, but I've discarded it. Reason: RAW-TAO worked, but only with those writers which already supported SAO or DAO. There wasn't much sense to confuse people with another option…"

How I can enable DAO-RAW for my Yamaha CRW2100E?
You must upgrade the firmware update with 1.0h version!

What is this SubChannel data? What is MainChannel data?
The SubChannel data is used to store various information's. It can be data used for CD-Text or Karaoke CD (CD+G) for example, but also for data that is used for copy protection: SecuROM & LibCrypt used Digital IDs which are stored in this SubChannel. MainChannel is the actual "information" stored on the CD: the user data + check sums, 2352 bytes "raw" data. Both the SafeDisc & LaserLock protections use this channel to store their protection.

Why can't I select the "Don't repair SubChannel Data" option? In this case, can I make backup of SecuROM protected CD?
This option is only available if your writer supports writing of 96 Bytes SubChannel Data (CD-Text, CD+G). This is a hardware restriction, not software restriction. Your writer still writes MMC-DAO-RAW and will work with CloneCD with the following restrictions:

- No CD-Text writing
- No writing of copy protected PSX CDs (LibCrypt protected)
- No writing of Karaoke (CD+G) CDs

Yet, you can still make safety backup of SecuROM protected CD since uses only 16 Bytes Q-SubChannel Data whereas LibCrypt protection (PSX) needs the full 96 bytes.

Why the backups of new SecuROM protection work only with CD/DVD-ROMs?
As you know, by now, SecuROM protection is a piece of cake for CloneCD. However Sony improved the SecuROM protection and it's newest build which found on games (such as VRally 2 Expert Edition) added a special trick in order to prevent the backups.. Sort off we must say.

The reason why your backups will work only with CD-Rom drives and not with CDR-W drives is that the new SecuROM protection checks to see if the media has ATIP information.. CDR-W drives can read them with a ReadTOC command (with format code ATIP) so when that happens the backup refuses to run! CDR/CDRW media have ATIP information stored but a "silver" (aka pressed) CD doesn't. Nice move from Sony however as we said you could still play your backups from normal CD/DVD ROM. Why? Simple. They don't support reading of ATIP! We imagine that this trick probably will be used from other protection authors quite soon…

Why most other current CD Copy software will not make working backups of my CDs?
Most other CD Copy software (CDRWin, Fireburner, BlindWrite) will not work since they don't allow writing of SubChannel data.

CDRWin and Fireburner: CDRWin only knows DAO RAW 16, but it does not write custom data (it's determined by the CUE sheet). RAW 96 don't let you do anything special besides Karaoke and LibCrypt. If you use BlindWrite and PadusDJ, SafeDisc/LaserLock work. Summarize: RAW16 can copy SafeDisc, SecuROM and LaserLock not LibCrypt and Karaoke. RAW 96 can copy all if the software can do the appropriate tricks…

Since CDRWin/FireBurner supports RAW16 how come backups will not work?
1. SafeDisc/LaserLock: You can't copy these. You can only fake these protections. Basically, Clone CD, when reading, replaces bad sectors with data that, when burned, makes a "fake" bad sector. By burning data with intentionally corrupt EDC/ECC data, the drive will think it found a bad sector when it really didn't.

CDRWIN does not do this when reading. Reading is the problem here, not writing. CDRWIN can write such bad data through its DAO RAW 16 mode, but not do the necessary tricks when reading. However, sometimes, when you use CDRWin's "Replace" option to read, it will act like Clone CD. You have to choose Replace when reading, and Raw when writing.

2. SecuROM: (LibCrypt not covered since CDRWIN doesn't do DAO RAW 96)
Although DAO RAW 16 is a sufficient mode to write SecuROM, CDRWIN doesn't make full use of it. To copy SecuROM, you need to write custom sub-Q data to the disk. DAO RAW 16 lets you do this, but CDRWIN doesn't have a way to store sub-Q in a BIN file and have it written to disk. CDRWIN generates the sub-Q based on the CUE sheet. CDRWin's DAO RAW 16 mode is identical in capability to SAO RAW for this reason.

Another note about #1: SAO RAW works identically to DAO RAW 16 with respect to SafeDisc and LaserLock. Same story must go for Fireburner.. If Fireburner adds CCD/IMG/SUB file support, SecuROM will work immediately (provided that you read with clone CD). BlindRead/BlindWrite. As far we know they don't do SecuROM so they act like CDRWIN.

Why my drive reads backups faster than the original CD?
The reason that copies can be read faster than originals is because copies do not actually have physical errors! The physical errors are represented by bad sectors, which CloneCD produces. They sectors aren't truly unreadable, on a copy, they're valid audio, but not valid data.

Data sectors have EDC/ECC for detecting and helping fix (minor) errors. If you burn bad EDC/ECC, the reader will try to correct with invalid correction data and you will get a read error, even though it can physically read the sector just fine. However there are some drives that some drives can actually differentiate CloneCD bad sectors and actual bad sectors (such as HP 8100/8200/9100/9200/9300/9400). But the CloneCD smart engine can handle them quite good.

Why I cannot read 96bytes SubChannel data with Plextor UltraPlex40x?
As CloneCD author said: "…The UltraPlex is known to have problems with certain SubChannel data on data tracks (namely SecuROM protection). Audio+SUB (Karaoke) shouldn't cause any problems, but I haven't looked at the quality of the R-W channels (where the CD+G information is stored)…"

Why my HP8100 cannot work with CloneCD?
Cause it doesn't support neither SAO nor DAO RAW! If do you want to make safe backups of your protected CDs get a better drive.

Can I write 99min CDs with CloneCD?
Not yet! CloneCD stops writing when it reaches 90min.

Can I make my own compilations with CloneCD?
No. CloneCD main use is for dupes only.

How I can backup GD CDs with CloneCD?
You cannot. GD CDs are not readable with normal drives. Read more about Dreamcast protection and the possible ways to backup them.

Which are the best settings for x game?
You need to recognize the protection of the CD or use an add-on called "Perfect Copy", which has a database with various games and the proper CloneCD settings.

Does CloneCD defeat the boot protection scheme found on Playstation CDs?
No, you still need a modchip in order to run your safety backup.

I saw that my burner can do DAO RAW Writing, but I failed copying a SecuROM CD, how come?
Two cases must be distinguished: protection that are stored in the SubChannel Data and ones that are stored in the MainChannel Data of the CD. In 1st case, you need to check (from the "hardware required" section) if your CD-Reader/CD-Writer can read/write "SubChannel from data track" since SecuROM protection store its Digital ID into the SubChannel of the CD. In second case, SafeDisc protection is stored in the MainChannel so most CD-ROMs can read this area.

I've just made a backup of a protected game; will I be able to copy it with another CD-R software?
You will need software that is able to perform RAW writing. As far we know, only CloneCD can do fully (MainChannel & SubChannel) write in this mode. CDRWin & Fireburner can write in RAW MODE but only for protection that are stored in the MainChannel (SafeDisc, LaserLock), so they can't handle protections that are stored in the SubChannel area (e.g SecuROM & LibCrypt protections).

How come games can be protected by using SubChannel data? As far i know not all CD-Rom drives can read the SubChannel data but can play the original CDs!
This is indeed a very intelligent question. It is indeed possible for an application to check, if a based-based protection is present, even if the reading device can't read SubChannel data with CloneCD. That actually makes SubChannel based copy protections so effective.

If a CD-ROM can play audio disks, then can read subcodes (at least minimally). When you play an audio disk with cdplayer.exe, you'll see the current time on the disk. That time comes from the Subcodes! What you can do is turn the volume off for the CD-ROM then ask it to play track 1 as audio (most drives will blank the audio if you try to play a data track, but turn the volume off as a precaution) then, as it's reading, retrieve the SubChannel data. Actually all CD-ROMs can read SubChannel data, not in the way you would like them to, but yes. It isn't exactly precise when you do that trick there is one completely unused and one almost unused field in the subcode data more than enough storage for copy protection decrypt codes.

How is this possible?
To check for a protection, you don't need to read the SubChannel data exactly. It is sufficient to do normal SEEKs and READ and ask the drive about the SubChannel data with a Read SubChannel Data from current position, as the protected application "knows" where to look. Almost any drive supports this. If you want to duplicate the protection, this method will not work. (Well, it would take weeks to find the position of the protection on the CD).

To duplicate the protection reliably (and in an acceptable time) the device used for reading the original must transmit the main- and SubChannel data in one stream (somehow synchronized), so this data can be written precisely. Note, that most drives have a fixed "Main- to SubChannel data" offset error, as the MainChannel data is fed through the ECC electronic and the SubChannel data is passed on unmodified. For example, reading sector x will give you MainChannel data of sector x, but SubChannel data of sector x+y. CloneCD will compensate this offset with a very cute method (patent pending).