CloneCD hiding bytes?

vbimport

#1

Following this thread
http://borg.cdfreaks.com/forum/showthread.php?&threadid=44829
I had a closer look at how CloneCD behaves on safedisc2
bad sectors, and the result is pretty surprising. For
this test I used a plexwriter 24/10/40A on MOHAA with
CloneCD 3.3.4.1 and 4.0.1.3 (FES enabled, retries=5,
correction=none).

With both versions I see this : when CCD reaches a
bad sector, it tries to read it 6 times, as expected
from my retries setting. So 6 times CCD issues a
READ_CD command (CDB=BE00xxxxxxxx000001F80000),
and each time it gets the same sector of datas,
with SRB Status and Target Status both ok. The
datas CCD receives look like this :

00 FF FF FF FF FF FF FF FF FF FF 00 00 49 74 01 .............It.
38 8F 1F DF 41 73 E7 D1 DB 48 68 0F 9D 0A 13 E7 8...As...Hh.....
C9 92 2B A8 5F CE 6A 55 2D 98 C1 3F EC 94 3F 5E ..+._.jU-..?..?^
4B 68 CE 04 09 1B E8 4C D1 5B 8F C6 0F 21 BB B8 Kh.....L.[...!..
07 F8 7E 85 C7 0F 55 B9 B9 A7 9F 74 84 5A 3B 57 ..~...U....t.Z;W
50 80 82 D5 52 94 2E 43 F0 E0 37 C1 F7 5F 3E 7F P...R..C..7.._>.
08 AD C7 3C 60 90 21 3D E3 9C C8 24 04 D8 EE 05 ...<`.!=...$....
C4 AE C1 25 B2 A3 EF B4 AF DE 48 C9 5A 98 02 1F ...%......H.Z...

but the datas CCD writes into the .img file are :

00 FF FF FF FF FF FF FF FF FF FF 00 00 49 74 01 .............It.
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

So it seems that although I specified not to check
the EDC by activating FES, CloneCD still decides
to discard the bytes it gets, and I see no good
reason for a true 1:1 copier to do so. Any idea ?


#2

do different drives read the same data on these sectors?
i guess not, thus it’s no advantage to use the actual bytes.

and if different drives would read the same data, you still could’nt
check it in the protection because of scratches etc.


#3

what error recovery parameter byte does ccd use with your settings? you pointed out that sd’s bad sectors are damaged
at c2 level. why does readcd return good status when a circ unrecovered error occures ? might this be the effect of the rc bit ?


#4

I think in CloneCD, on a Plextor drive with the FES set to error correction:none - the hardware will ignore and not report errors due to unrecovered circ or EDC/ECC errors - hence why it returns good status. The drive just returns the sector uncorrected (couldn’t be corrected anyway).

I agree with blackcheck, scratches, etc would cause problems reading those sectors. But would you think Macrovision care about this, their future versions might check a few of those sectors or even backlist and if you have scratches then they’ll think tough luck.

Only one problem not many drives support this feature of returning the uncorrected sector - probably only Plextor drives so far.


#5

> do different drives read the same data on these sectors?

Dunno, only my plextor returns datas.

> i guess not, thus it’s no advantage to use the actual bytes.
> and if different drives would read the same data, you still
> could’nt check it in the protection because of scratches etc.

From a copy protection point of view, I agree that current
safedisc checks are so basic that they will not see the difference.
But my point is more general and not limited to safedisc : I
don’t want a cd reading program to decide for me which bytes
are important and which ones are not. And when I specifically
ask for no error checking, I expect it to give me the bytes my
drive can read, even when EDC is wrong.

> what error recovery parameter byte does ccd use with your
> settings?

For all configurations CloneCD uses TB = RC = PER = DTE = 0
(pretty disappointing, no ? :))
with FES/None or FES/software -> DCR = 1
with No FES or FES/hardware -> DCR = 0

When DCR=1 my drive send back bytes, when DCR=0 the
READ_CD fails. But in all 4 cases the .img contains all ‘U’.

> you pointed out that sd’s bad sectors are damaged at c2 level.
> why does readcd return good status when a circ unrecovered
> error occures ? might this be the effect of the rc bit ?

I only measured the C2 errors, not how many of them are
uncorrectable, and I don’t know for sure what my drive really
does when DCR=1.


#6

Only one problem not many drives support this feature of returning the uncorrected sector - probably only Plextor drives so far.

The Toshiba 1502 (and probably 1612, too) also support FES set no none (at least CloneCD doesn’t report a warning as it does e.g. with liteons).


#7

alexnoe, you’re right, my Toshiba SD-1502 does support the feature. But CloneCD always refuses to write the bad sectors to the image. Anyway, that makes 2 brand drives to support the feature. :slight_smile:

I did the same tests of my own with Plex 8432 (IDE).

With CloneCD v3.3.4.1 it will only write those sectors when read retry count is set to 0 and error correction:none.

With CloneCD v4.0.1.3 it’s the same.


#8

> Anyway, that makes 2 brand drives to support the feature.

Now we just need CloneCD to support the feature too
(they already have the GUI, that’s a good start).


#9

List of devices that can return C2 Errors


#10

Originally posted by spath
[B]Following this thread
http://borg.cdfreaks.com/forum/showthread.php?&threadid=44829
I had a closer look at how CloneCD behaves on safedisc2
bad sectors, and the result is pretty surprising. For
this test I used a plexwriter 24/10/40A on MOHAA with
CloneCD 3.3.4.1 and 4.0.1.3 (FES enabled, retries=5,
correction=none).

With both versions I see this : when CCD reaches a
bad sector, it tries to read it 6 times, as expected
from my retries setting. So 6 times CCD issues a
READ_CD command (CDB=BE00xxxxxxxx000001F80000),
and each time it gets the same sector of datas,
with SRB Status and Target Status both ok. The
datas CCD receives look like this :

00 FF FF FF FF FF FF FF FF FF FF 00 00 49 74 01 …It.
38 8F 1F DF 41 73 E7 D1 DB 48 68 0F 9D 0A 13 E7 8…As…Hh…
C9 92 2B A8 5F CE 6A 55 2D 98 C1 3F EC 94 3F 5E …+..jU-…?..?^
4B 68 CE 04 09 1B E8 4C D1 5B 8F C6 0F 21 BB B8 Kh…L.[…!..
07 F8 7E 85 C7 0F 55 B9 B9 A7 9F 74 84 5A 3B 57 …~…U…t.Z;W
50 80 82 D5 52 94 2E 43 F0 E0 37 C1 F7 5F 3E 7F P…R…C…7…
>.
08 AD C7 3C 60 90 21 3D E3 9C C8 24 04 D8 EE 05 …<`.!=…$…
C4 AE C1 25 B2 A3 EF B4 AF DE 48 C9 5A 98 02 1F …%…H.Z…

but the datas CCD writes into the .img file are :

00 FF FF FF FF FF FF FF FF FF FF 00 00 49 74 01 …It.
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

So it seems that although I specified not to check
the EDC by activating FES, CloneCD still decides
to discard the bytes it gets, and I see no good
reason for a true 1:1 copier to do so. Any idea ? [/B]

This is indeed weird. CloneCD should only write the 0x55 stuff if it was unable to recover the data.
I’ll check.


#11

Originally posted by Olli

CloneCD should only write the 0x55 stuff

Why did you choose 0x55? It seems a very unnatural number.


#12

Originally posted by SirDavidGuy
[B]

Why did you choose 0x55? It seems a very unnatural number. [/B]

It is a alternating 1 and 0 bit pattern and looks indeed beautiful, doesn’t it? :slight_smile:


#13

Originally posted by Olli
[B]

This is indeed weird. CloneCD should only write the 0x55 stuff if it was unable to recover the data.
I’ll check. [/B]

Olli, have you checked?

May be important for a protection (Sd2)?

Can you say anything about this?


#14

Anything new ?


#15

Originally posted by PeterS
[B]

Olli, have you checked?

May be important for a protection (Sd2)?

Can you say anything about this? [/B]

Okay, I checked and all seems to be well. You may see a couple of these sectors, when Automatic FES is enabled for the first four or so bad sectors. This is intentional.


#16

Why is this intentional? If it was doing a true 1:1 copy there would be no need for rewriting the bad sectors. The bad sectors would simply be copied.

So are you saying that it cannot read and write these sectors initially but can later? Please clarify.


#17

Originally posted by runner1000000
[B]Why is this intentional? If it was doing a true 1:1 copy there would be no need for rewriting the bad sectors. The bad sectors would simply be copied.

So are you saying that it cannot read and write these sectors initially but can later? Please clarify. [/B]

What happens is, that FES is disabled by default. CD drive reports read errors, CloneCD inserts read errors.

Later, FES kicks in. CD-Drive no longer reports read errors, CloneCD writes whar CD-Drive has read.

In the end, there is no difference. You could switch on FES per default, but why? A read error is a read error is a read error.


#18

Thanks for the explanation.

In other words, in programming vernacular:

garbage in --> garbage out


#19

> Later, FES kicks in. CD-Drive no longer reports
> read errors, CloneCD writes whar CD-Drive has
> read.

Sorry, but that is still not clear to me. My test
showed a case where the drive does not report an
error and sends back datas but CCD still writes all
U to the image. Is that intentional ?


#20

Obviously, CloneCD is not a true 1:1 copier. It is unable to accurately copy the bad sectors so it creates its own bad sectors and sends them to the writer. It doesn’t matter what it sends to the writer as long as it is the same length and unreadable, also.

I don’t think that any program can accurately copy these sectors, so they are all doing pretty much the same thing.

I think that it is certainly pretty close to genius to have come up with the idea for AWS. However, the idea that is often stated on this board and others that CLoneCD is a true 1:1 copying program is just not entirely accurate. (No offense, Olli).

It is still a great program!