Amplify Weak Sectors

vbimport

#1

I've move this thread from CloneCD to CloneCD Experienced User in order to learn more about AWS(Amplify Weak Sectors)

This is what was posted in CloneCD:

Originally posted by Upp3rd0G
Your writer is fully EFM compatible, so don't use AWS! (In fact, you could get a coaster if you do use AWS with your writer... I think I read this somewhere here on this forum, not completely sure.)

Originally posted by PaRaNoiD
[B]

Just wondering if this is true. [/B]

Originally posted by FutureProof
Yes

Originally posted by PaRaNoiD
[B]Why's that?

If the burner is fully EFM compatible,wouldn't having AWS on not matter. [/B]

Originally posted by FutureProof
[B]I don't know a lot about AWS. Maybe you'd like to post in the Experienced Forum. What I can tell you, from my testing, is this:

Failed Backups from these devices with AWS enabled in V3 & V4:

ASUS CRW 16X & ASUS 40x
LG GCE 16x
Liteon's 24102b, 32123s

otherwise they produce working MOHAA backups without AWS. [/B]

So like i've posted before,why would AWS affect a image if the drive is able to fully do EFM correctly?


#2
Edit:

The information in this post is incorrect, see my post below for the correction information…

Spath can give you an explanation for sure. I will give it a try…

Apparently AWS works by modifying sectors, that is by modifying the EDC and ECC fields. When you read an AWS sector, the EDC+ECC do a correction on the data-part of the sector so that it results in a weak sector. (Not really a weak sector, but weak enough to fool the SafeDisk weak sector check from Macrovision.) When you write with an fully EFM capable writer like most LiteOns, you don’t need and want the AWS trick. The LiteOn will write the data-part of the weak sector correct, than AWS modifies the EDC+ECC fields. So when you reread this sector, the data-part of the weak sector gets modified by the error correction code in such a way that it results in a sector which is not weak at all!!!

I think it works like this…

:slight_smile:


#3

I think it works in a different way. The data part of the sector gets modified in order to break the assymetry formed by the weak sector (that means the sector gets “deweaked”). The EDC/ECC is not touched at all. Because of this, such a sector gets automatically corrected by the drives hardware (on reading back). This is why it “fools” the SD2 check, it actually feels and smells exactly the same as the original weak sector.

Why doing such a thing on writers capable of writing (some) weak sectors breaks things, is over my head.
It should work, even on drives that are already capable of writing (some) weak sectors.


#4

I interpreted spath’s explanation as drezons way too.

Modifying the error correction could change the data interpretation, thus actually making it appear as a bad sector, and failing the check.

What we need is more info about the SD2 guard module.


#5

I interpreted spath’s explanation

Could you please post the link too this spath’s explanation.

Thanks.


#6

Originally posted by SirDavidGuy
I interpreted spath’s explanation as drezons way too.

Ok, I guess I am wrong then…

:o


#7

Originally posted by PaRaNoiD
[B]

Could you please post the link too this spath’s explanation.

Thanks. [/B]

In this link, spath said

> But isn’t it strange, that the weak sectors of the
> copy are only available in the CCD-image ???

Yes, it’s very strange. For instance Betablocker
replaces 86 bytes of each weak sector without
correcting EDC/ECC, so I would expect to get these
bytes back with CCD+FES. Seems to me CloneCD is
doing weird stuff here… when I get my toys back
I will tear CCD apart and find out what’s going on.


#8

drezon got it right.


#9

Originally posted by PaRaNoiD

So like i’ve posted before,why would AWS affect a image if the drive is able to fully do EFM correctly?

A suitable answer to this valid question, in the other CloneCD Forum, is “don’t do it” because I’ve seen too many Q’s about this where the only problem is that AWS was enabled and the backup didn’t work. This was certainly true for CCD v3. This is an appropriate forum to discover & report, particularly about ‘correct’ SD2 burners that are unaffected by AWS.

V4 is another kettle of fish. As you know, the “Allow AWS” checkbox is enabled for all burners in their properties, ‘out of the box’. The default Game CD profile has AWS checked. However, and I don’t know how this works, CCD claims to ‘know’ which burner doesn’t need it. In the few emails I’ve had from Sven and others between me & GF, I still don’t understand this; why? How does CCD know if it’s SD2.51.020 or SD2.51.021 ie “…is this a one dot burner burning .021 and ‘enable AWS’…” or “…is this a one dot burner writing 2.4.x…”, or “…is this a two dot burner and don’t ever enable AWS…?”. You see, the default Game CD Profile will give me a working backup of MOHAA from my 24102B 5s07.

I suspect that AWS is ‘always on’ and that it does not affect the write for a two dot burner; or, less likely, IMHumbleO, CCD somehow inspects the ‘data’ and accounts for “correct EFM encoding”. Dunno really - it just works. If someone can say that AWS in CCD v4.x does not affect writing, I’d be pleased to hear it and pass it on.


#10

Originally posted by FutureProof

I don’t know a lot about AWS. Maybe you’d like to post in the Experienced Forum. What I can tell you, from my testing, is this:

Failed Backups from these devices with AWS enabled in V3 & V4:

ASUS CRW 16X & ASUS 40x
LG GCE 16x
Liteon’s 24102b, 32123s

otherwise they produce working MOHAA backups without AWS.

How did these back up’s fail ie.didn’t install,wouldn’t run,or die half way though playing.

I’ve testing with AWS ON and OFF using a ASUS 4012A and have been getting working backs which leads me to believe that(though i could be wrong too)that if a burner is fully EFM compatible that running AWS shouldn’t affect the image.


#11

what clone version are you using? people who did this with version 3 couldnt use AWS on a perfect image…another interesting thought, what if you use AWS on a betablocker patched image on a 1 dot writer that clone ‘knows’ needs AWS ? just a little spicey thought i had.


#12

Originally posted by drezon
The data part of the sector gets modified in order to break the assymetry formed by the weak sector (that means the sector gets “deweaked”). The EDC/ECC is not touched at all. Because of this, such a sector gets automatically corrected by the drives hardware (on reading back).

Because I was wrong and this is an interesting subject and I want to have my facts straight I want to rephrase the above.

So the 2048 bytes of the data part gets modified ‘to break the assymetry’ of the weak sector (at least, this is how BetaBlocker works, is it already proven (?) that AWS works the same way?), but the EDC/ECC is not touched, so when reading this modified weak sector, EDC/ECC does it trick, correcting the data part of the sector back into a weak sector.

Is this correct? (@spath, sirdavidguy, drezon)


#13

If you are a “lucky owner” of a fully EFM-compatible drive and nevertheless you are using AWS or you patch the sectors with BetaBlocker and burn the image to CD - if you read back the CD to an image again, would you end up with an image, equal to the patched one (BetaBlocker)?
Unfortunately I can’t test this (owning PX-W1210S).


#14

Originally posted by little-endian
If you are a “lucky owner” of a fully EFM-compatible drive and nevertheless you are using AWS or you patch the sectors with BetaBlocker and burn the image to CD - if you read back the CD to an image again, would you end up with an image, equal to the patched one (BetaBlocker)?
Unfortunately I can’t test this (owning PX-W1210S).

It depends. If you use the audio read trick, you get the patched sectors. If read in CloneCD’s FES mode (due to a bug which Olli is looking in to), you get the original sectors.

So the 2048 bytes of the data part gets modified ‘to break the assymetry’ of the weak sector (at least, this is how BetaBlocker works, is it already proven (?) that AWS works the same way?), but the EDC/ECC is not touched, so when reading this modified weak sector, EDC/ECC does it trick, correcting the data part of the sector back into a weak sector.

If I’m understanding it right, yes.


#15

@SirDavidGuy

Besides that, it is very strange, that both, the UltraPlex and Toshiba SD-M1402, fail to read the “more or less weak” sectors on an amplified CD with Cdrwin.
But if I use BlindRead or CloneCd with the same disc, I get exactly the results, you’ve said.


#16

This thread lost me about half-way through…:confused: (I’m just clever enough to get myself in trouble - regularly). For what it’s worth, I can state that, burning SD2.5** with CCD4 (final Beta), Lite0n 32123s and AWS enabled is not a good thing!!! She no work too well! Disable AWS and all is fine.

Dik.

A little knowledge is dangerous - I have so little I’m a menace!


#17

Originally posted by Upp3rd0G
[B]
http://www.discusa.com/images/gif/mode1a.gif

So the 2048 bytes of the data part gets modified ‘to break the assymetry’ of the weak sector (at least, this is how BetaBlocker works, is it already proven (?) that AWS works the same way?), but the EDC/ECC is not touched, so when reading this modified weak sector, EDC/ECC does it trick, correcting the data part of the sector back into a weak sector.

Is this correct? (@spath, sirdavidguy, drezon) [/B]

Yes, I think this is correct. Btw, I didn’t know that spath already elaborated on this subject as quoted earlier in this thread. I came to this conclusion by myself; so it’s two people independently “discovering” the same thing - this should give you some confidence.


#18

I got a Lite-On 24x10x40 201020B…with CCD 4…using Beta Blocker works for me alot…but whenever I try to play the game with the burn’t play disc inside I still gotta put in the orginal CD…this makes me wonder…I did AWS still same thing…think is MacroVision? My thought is its physical bad sectors…if its physical then there is no hope…