We all know the bad sectors which appear on every SafeDisc(2) CD. If a drive reaches such a sector, it reports "unable to read sector" to the application and the sector is filled up with zeroes, or whatever. CloneCD uses the HEX-value 55, I think (image scanned with CDmage). A long time ago, BlindRead introduced a great method to avoid the slow-down of CD-ROM drives, while encountering bad sectors. The data is read as audio, which has the same sector-size as a raw Data-Track (2352 bytes/sector).
If have read Rayman 2 (SDv1) for testing:
First with the UltraPlex 40max, alternative read method, enabled.
Second with CloneCD, fast error skip, enabled (disabling shouldn't give any differences).

The resulting images are different. All bad sectors of the CloneCD image are filled with "55", while the BlindRead image seems to have always different values in every bad sector.

OK, next I created a very strange disc!
I used a regular wave music file, cutted it to be a multiply of 2352 bytes and removed the wave header to get a RAW-PCM file.
I burned this file with CDRWIN as a Mode1 disc.

file test.raw binary
track 01 mode1/2352
index 01 00:00:00

The final CD is pretty "cool".
It runs in a regular cd-player as an audio-CD, but at the end a VERY SHORT click noise will appear. I have no idea why this occurs. Almost none CD-ROM will be able to read such a CD again. Nice copy protection, BTW ;-).
But the disadvantage is that "new" cd-players won't recognize the CD as audio because of the DATA flag in the subchannels.

The UltraPlex is one of the rare drives which can read such a CD again (Toshiba SD-M1401 and PlexWriter failed both) because the Mode1 Track gives no sense as audio.

If you read the DATA Mode1 Track containing audio with CDRWIN (only read sectors works) as Mode1/2352 you'll get garbage, but if you read it as audio, you'll get the whole file (with that annoying click at the and :-[).

It would be interesting to know: When is a sector unreadable? Because if you read the CD as audio, ALL sectors are readable, no matter if the CRC is OK, or not. So the sectors stay unchanged.
Maybe BlindRead reads the CD without correcting the bad sector in opposite to CloneCD.

It would be nice, if anyone could give me additional infos about the topic "unreadable secotrs, CRC, etc".

Datas you call 'unreadable' are either sectors you cannot locate
or sectors you cannot correct. In both cases, reading these sectors
as datas will not give you anything, while reading them as audio
will indeed give you some bytes. But these bytes are generated by
the error concealment mechanism of the drive (interpolation,
muting, fading...) to minimize the audible impact of these errors :
they have nothing to do with actual datas on the disc.

In short, by reading a cdrom as audio you will neither extract
more datas nor extract datas more accurately. The only advantage
you could get is an improved extraction speed, but with CloneCD's
fast error skip, I consider this trick is now obsolete.

I have read this article and Olli's reply, and both make
sense. Certainly I can understand the irritation of
Fireburner's author about what you can read everywhere
about CloneCD, I myself was pretty upset when someone
here has claimed that CCD could bypass the EFM tables
But AFAIK these claims always came from CCD users, not
from Olli himself. And as much as I would like him
to refute all these absurdities, I can understand that
he has no time (or even commercial interest) to explain
in details how CCD works and its limitations.

About the 'U' trick, I think Olli could answer this better
since he invented it. My guess is that safedisc is not
smart enough to distinguish between a read error caused
by uncorrectable datas at C1/C2 level and a read error
caused by a trashed sector. Want me to ask macrovision
if they can fix it ?

I think so too. But you know what? I think macrovision did it on purpose, so that they can put this in later and make a new updated version in order to make more money and confusion. Anyway, it doesn't make too much of difference because most or all CDROM drives cannot read C1/C2 sector errors.

@FutureProof
The text file, you mentioned, is great. Very useful info. Thank you for this!
Maybe you have to do "better things" than testing track modes.
Girl-friends can be a very time-intensive "hobby" ;-).

@spath
You wrote, that reading the data disc as audio won't give better results or even exacter results.
But as I wrote before, I created a data-disc, which contained actually audio-data. Because the audio sector uses the full size of a raw main-channel (2352 bytes/sector), my created DATA MODE1/2352 Track containes *ALL* the audio data.
An if I read the CD as audio again (CDRWIN / sector reading), I get the *TRUE* audio data. NO interpolation errors occur, the resulting wave file is the SAME (except the introduced offset, of course)!!!
I tried reading the CD sectors as Mode1/2352 (as reported from the CD-TOC) with CDRWIN / sector reading. Then the whole CD is interpreted as Data, and of course, the audio doesn't give ANY sense as MODE1, because the EDC/ECC infos are completely wrong. So I end up with garbage data. Proof enough, that only AUDIO reading will give you the true bytes !?

I wanted to try out the alternate read method of BlindRead.
The problem is, that BlindRead doesn't have the option to read single sectors, only. It wants to read the TOC of the disc first, which is complete junk, of course. So you can't read the disc with BR, even if you own a UltraPlex :-[.

I had the idea to write a new CD, on which the first track is normal (any files on your hdd, etc.), and only the second track would be the strange audio/data track, so BlindRead could recognize the CD properly. Nice try ;-)!
The first track is read properly, of course, but as soon as BlindRead reaches the 2nd Track, it stops reading from the CD and filles up the whole track with garbage, even in the "nibble" reading mode :-[.

Again, I had no chance to test this reading method.

But one thing is certain:

If you read a SafeDisc protected CD with BlindRead / audio mode, you won't get the sectors filled up with 55 as explained in the text file. Instead maybe you will get the true bytes. I can't test this because the sectors are still "bad", otherwise the copy wouldn't run as the original game CD, obviously.

This brings us to the final topic:

I don't think, that Macrovision can "enhance" their SafeDisc sheme, to check if the "bad" sector is bad because only the checksum is wrong or if the sector is bad because Olli filled it up with 55 bytes.

The general problem is:
The original game should run in MOST drives, not only on high-end drives, like Plextor (just kidding!).
You can't expect from a CD-ROM drive that is discerns if a sector is generated or originally pressed.

I think you are mixing the results of two completely unrelated
tests to draw wrong conclusions : your special disc and safedisc2
sectors are two very different things. If it was not clear, my
first reply was about safedisc, not your special disc. Now in
details :

YOUR DISC:
> Then the whole CD is interpreted as Data, and of course, the
> audio doesn't give ANY sense as MODE1, because the
> EDC/ECC infos are completely wrong. So I end up with garbage
> data. Proof enough, that only AUDIO reading will give you the
> true bytes !?

Not really. The MMC-1 READ_CD command clearly states that you
can disable the EDC/ECC check and get the datas even if the
correction is impossible (see details in SBC-2). As a quick
counter-example, I have replaced all the EDC/ECC bytes of a
sector with 'U' and burned that raw with CloneCD. Although
some programs cannot read this sector back, CloneCD itself
(with FES enabled) can recover all the datas of the sector. In
that case you can recover the 'true bytes' in audio mode as well,
because I have trashed the datas at sector level.

SAFEDISC2:
> But one thing is certain:
>
> If you read a SafeDisc protected CD with BlindRead / audio
> mode, you won't get the sectors filled up with 55 as explained
> in the text file. Instead maybe you will get the true bytes. I
> can't test this because the sectors are still "bad", otherwise
> the copy wouldn't run as the original game CD, obviously.

No, in this case you don't get the 'true bytes' but interpolated
ones. Contrary to the previous sectors with bad EDC/ECC bytes,
CloneCD (with FES enabled) is not able to read the bad sectors
of a SD2 disc. I had a closer look at these bad sectors, and the
reason why drives cannot read them is that they contain a lot of
(fake) C2 errors. In that case sectors are trashed at EFM frames
level (one level below the previous one), so you will not get the
'true bytes' either in data or audio mode. And you will also not be
able to burn a disc with such C2 errors.

> I don't think, that Macrovision can "enhance" their SafeDisc
> sheme, to check if the "bad" sector is bad because only the
> checksum is wrong or if the sector is bad because Olli filled it
> up with 55 bytes.

Well, after a quick look through the specs, I think MMC compliant
drives should be able to see the difference. We'll see in next
version

I'm not sure where you guys are getting the mentioned 'audio' mode from, but this mode doesn't exist to give data though IDE cable!! I know that this doesn't exist because if you look at MMC specs there are none that will do this. All of the ones in there for audio (except READ_CD) are not for passing data through IDE cable but through the CDROM audio cable instead.

Let me get this straight, are you guys saying that the data is routed through sound card, then spath is right, the bad data will be interpolated.

OK, maybe I have mixed to different tests together. Sorry if I have understood you wrong.
I don't know very much about all these MMC specifications.
So I thought, unreadable sectors are unreadable sectors, no matter WHY they are unreadable (faked or not).
Maybe some of this MMC stuff is available in german. That would be much easier for me ;-).

Easy Audio Lock uses tricks which look like your trick. One of the EAL-protections marks audio-tracks as data-tracks. This is accomplished by modifying the control field in the .CCD file from 0x00 to 0x04. (If I am correct, Control=0x00 is audio, Control=0x04 is data. Are there other values possible?)

If you read the DATA Mode1 Track containing audio with CDRWIN (only read sectors works) as Mode1/2352 you'll get garbage, but if you read it as audio, you'll get the whole file (with that annoying click at the and

It would be interesting to know: When is a sector unreadable? Because if you read the CD as audio, ALL sectors are readable, no matter if the CRC is OK, or not. So the sectors stay unchanged.
Maybe BlindRead reads the CD without correcting the bad sector in opposite to CloneCD.

Correct me if I'm wrong, but the read command for reading audio digitally (dae) through SCSI/IDE cable is the same command for reading data CDs. There isn't a separate command for the 2, therefore you guys/girls shouldn't be using a separate naming for it.

The read command for reading audio digitally before and currently now is still the generic MMC READ_CD command.

When you guys/girls are talking about "audio" mode, you are referring to sector type filtering options for the read cd command - not different read commands.

The read command actually also accepts no filtering and this is what is used by most CD copying programs:
CloneCD and BlindWrite.

The reason why the Plextor can read such a disk is because it probably doesn't abide strictly by the mode that is written in the subchannel (doesn't care), therefore it can read the CD. This is to do with design issue in hardware, not commands issued by the software.

The data selection in CDRWIN is the filtering option that I described!!

The reason why selecting AUDIO works is because it tells the hardware to do AUDIO filtering - which doesn't filter anything - since AUDIO uses full 2352 bytes. Selecting MODE1 doesn't work because this tells the hardware to do filtering of SYNC, position info, strip out 2048 of data and EDC/ECC checking - which are not valid on the interesting CD you made.

You would realise this if CDRWIN had included one more selection it left out: ALL TYPES (NO FILTERING), as this option would also be able to read your CD. I am not sure why this option was left out. Strange?

I have written such a prototype CD reading program that includes this option - if you would like to try it out on your CD, then please PM me.

You wrote, that the copy protection "Sunncom Media Cloq" uses "my" audio method. Do you know, how they bypass this "click" @ the end of the wave when reading the data as audio?

@all of you

OK, I tried an image from Black&White, this time:

I read the disc with BlindRead/audio reading.
Then I read the disc with CloneCD (fss DISABLED).
I opened this CCD-Image with a Hex Editor to look, where the first bad sector is filled up with "55" hex bytes. I closed the file and opened the BlindRead-Image instead. I skipped to the same position and in the middle of this sector, I overwrote the bytes with some text, like "AUDIO READING TEST".
Then I burnt this image with CDRWIN/RAW MODE.

Then I created an image again from the copy with BlindRead and CloneCD. Guess what happened:

In the BlindRead/Audio Image, my inserted string is STILL THERE.
But in the CloneCD image the whole sector is filled up with 55 again.

I think this shows, that the BlindRead reading (at least the audio mode) is in some way "correcter" than the reading of CloneCD. But I think it is NOT CloneCDs fault, but the reading methods ...

It would be cool, if CloneCD would support the audio reading in the future, for drives that support this.

i always thought that clonecd didnt actually write the weak sector, but just put something in that wasnt the 'null' value that safedisc checks for. i guess that something is 55

thank god for the small break between spring semester and summer school, maybe i can actually understand this *prays*

__________________ www.livingwithoutmicrosoft.org

last 5 cd's
Avril Lavigne - Whatever the new one is called
Lucky Boys Confusion - Throwing the Game
lostprophets - Start Something
Story of the Year - Page Avenue
Flaming Lips - Yoshimi Battles the Pink Robots

> I think this shows, that the BlindRead reading (at least the
> audio mode) is in some way "correcter" than the reading of
> CloneCD. But I think it is NOT CloneCDs fault, but the reading
> methods ...

The only thing CloneCD misses to read back your string is the
intermediate field, restore it and everything works. I guess
it should be posible to remove that limitation by tweaking the
Data Selection and/or Expected Sector Type fields of READ_CD's
CDB, but I won't spend more time on this : it seems to me you
just love that audio reading method and nothing I could say
would convince you (and if you can get it added to CCD, it will
not hurt )

I think you are understanding me wrong,
I absolutely respect your knowledge and your opinion.
I cannot say, that I love the AUDIO method sooo much, but I just like to experiment. This audio method has a lot of disadvantages, by example it is VERY unsecure.
But isn't it strange, that the weak sectors of the copy are only available in the CCD-image ???
Unfortunately I cannot make this test with an correct EFM compatible burner, because the only one I own is a PlexWriter PX-W1210S. So I have to live with BetaBlocker or AWS.

> 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.