copying damaged CDs, SCSI CD ROM

[rscottdrysdale]

i bought a bunch of CDs without cases - very cheep. several of them have scratches that prevent my crappy DVD player from playing them in my stereo, so i decided to copy the scratched disks with ImgBurn. had success with all but one.

 

that particular disc has a nasty, deep, 0.25 inch (6mm) long scratch tangent to the disc, which is a Bad Thing.

 

one of my CD/DVD burners is a TSSTcorp SH-S223F (SATA). this drive blissfully reads the damaged disc without reporting any errors or even pausing for retries, but produces an image file with skips. "disc->image" and "verify image<->disk" report no errors, so apparently it generates consistent garbage (or verify is broken). ImgBurn logged no errors or retries during the read or verify.

 

the other CD/DVD burner is a LiteOn DH-3H20A (IDE). it's much more honest. the image read slows down to 0kbps for a while as it's apparently doing retries. it still produces an image with skips, but not as bad as the other drive. ImgBurn logged no errors during the read or verify, but did log one retry during read. weird - there was no slowdown or pause during the verify operation anywhere in the damaged track, which makes me wonder if verify is really doing what it's supposed to do.

 

i also tried reading the disc with an NEC 466 CD ROM drive (SCSI via adaptec 2906), but...

 

I 18:19:02 ImgBurn Version 2.4.4.0 started!

I 18:19:02 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 3)

I 18:19:02 Total Physical Memory: 1,014,504 KB - Available: 231,012 KB

I 18:19:02 Initialising SPTI...

I 18:19:02 Searching for SCSI / ATAPI devices...

I 18:19:02 Found 1 CD-ROM and 1 DVD

[mmalves]

For Audio CDs the verify "asks" the drive to read all tracks/sectors of the disc, therefore, it fully relies on the drive's abilities to report errors/bad sectors.

 

As for your NEC drive, it may be too old to undestand the MMC standard commands that ImgBurn uses. If I recall correctly another user also had problems using ImgBurn to read CDs on an old Plextor SCSI CD-ROM drive.

[rscottdrysdale]

For Audio CDs the verify "asks" the drive to read all tracks/sectors of the disc, therefore, it fully relies on the drive's abilities to report errors/bad sectors.

i expected verify to compare every byte in the image file with every byte on the disc. if it doesn't do that, it shouldn't be called "verify!"

 

so to determine if i'm getting a good image during read i have to read to image file A, then read to image file B, and manually (FC, etc) compare the image files?

 

similarly, to determine if i got a good burn i have to burn from image A, then read newly-burned disc to image B, and compare the two image files?

 

As for your NEC drive, it may be too old to undestand the MMC standard commands that ImgBurn uses. If I recall correctly another user also had problems using ImgBurn to read CDs on an old Plextor SCSI CD-ROM drive.

that sounds likely.

Edited July 21, 2009 by rscottdrysdale

[mmalves]

The drive offsets the read audio samples, so having a real verify for Audio CD is almost impossible. Even if you apply correction it isn't a 100% verify.

[rscottdrysdale]

The drive offsets the read audio samples, so having a real verify for Audio CD is almost impossible. Even if you apply correction it isn't a 100% verify.

here's the scenario. no burning involved:

 

put an audio CD in the drive. tell ImgBurn to make an image of it.

 

at this point, i would expect doing a "verify disc<->image" would effectively read the audio CD all over again, comparing what it got to the image file it just created, but apparently that's not what ImgBurn does. FEATURE REQUEST!

 

to simulate it, i'll try making two image files from the same disc. on a clean, defect free disc, i see no reason to expect that i would not get exactly the same binary data in the two files. if the drive "offsets the samples" (whatever that means), it should do so consistently from one read to the next.

 

i cannot imagine a scenario where a drive would provide DIFFERENT data during a second read of the same disc unless there were uncorrectable errors.

[mmalves]

What you're asking is technically infeasible. Google around and you'll see.

 

If it was possible ImgBurn certainly would have it.

[LIGHTNING UK!]

Look in the settings on the Verify tab.

 

Audio tracks have no error correction on them, the audio samples take up the full 2352 bytes of data in the sector. The best you can do is read the sector 10 times and take an average or something. Use EAC for ripping problem Audio discs.

[rscottdrysdale]

What you're asking is technically infeasible. Google around and you'll see.

 

If it was possible ImgBurn certainly would have it.

 

"technically infeasible" he says. suck on this:

 

1) make an image of an audio cd into directory g:\a.

2) make an image of the same audio cd into directory g:\b.

 

3) bring up your friendly neighborhood command prompt:

 

G:\>dir a

Volume in drive G is RSD500G

Volume Serial Number is 10D8-093C

 

Directory of G:\a

 

07/21/2009 08:14 PM <DIR> .

07/21/2009 08:14 PM <DIR> ..

07/21/2009 08:13 PM 831,596,640 Tangerine Dream - The Anthology Decades.bin

07/21/2009 08:13 PM 684 Tangerine Dream - The Anthology Decades.cdt

07/21/2009 08:13 PM 1,402 Tangerine Dream - The Anthology Decades.cue

3 File(s) 831,598,726 bytes

2 Dir(s) 118,079,787,008 bytes free

 

G:\>dir b

Volume in drive G is RSD500G

Volume Serial Number is 10D8-093C

 

Directory of G:\b

 

07/21/2009 08:24 PM <DIR> .

07/21/2009 08:24 PM <DIR> ..

07/21/2009 08:24 PM 831,596,640 Tangerine Dream - The Anthology Decades.bin

07/21/2009 08:24 PM 684 Tangerine Dream - The Anthology Decades.cdt

07/21/2009 08:24 PM 1,402 Tangerine Dream - The Anthology Decades.cue

3 File(s) 831,598,726 bytes

2 Dir(s) 118,079,787,008 bytes free

 

G:\>fc /b "G:\a\Tangerine Dream - The Anthology Decades.bin" "G:\b\Tangerine Dream - The Anthology Decades.bin"

Comparing files G:\A\Tangerine Dream - The Anthology Decades.bin and G:\B\TANGERINE DREAM - THE ANTHOLOGY DECADES.BIN

FC: no differences encountered

 

 

G:\>fc /b "G:\a\Tangerine Dream - The Anthology Decades.cdt" "G:\b\Tangerine Dream - The Anthology Decades.cdt"

Comparing files G:\A\Tangerine Dream - The Anthology Decades.cdt and G:\B\TANGERINE DREAM - THE ANTHOLOGY DECADES.CDT

FC: no differences encountered

 

 

G:\>fc /b "G:\a\Tangerine Dream - The Anthology Decades.cue" "G:\b\Tangerine Dream - The Anthology Decades.cue"

Comparing files G:\A\Tangerine Dream - The Anthology Decades.cue and G:\B\TANGERINE DREAM - THE ANTHOLOGY DECADES.CUE

FC: no differences encountered

 

 

G:\>

 

what was so "technically infeasible" about that? this test was done with a new, clean CD. i'll try next with the defective one i used before.

Edited July 22, 2009 by rscottdrysdale

[LIGHTNING UK!]

That only works if you use the same drive twice for the reading - and of course I have no way of knowing if you've done that. For that reason, there is no actual byte for byte comparison done on Audio data (unless you enable it in the settings).

 

Read it (even a perfect disc) with one drive and then again with a different one and it won't work unless both drives happen to have the same read offset (same make/model/firmware normally).

[rscottdrysdale]

Look in the settings on the Verify tab.

i have looked there, but i see nothing that would indicate doing a "brute force" compare, which is what i want.

Audio tracks have no error correction on them, the audio samples take up the full 2352 bytes of data in the sector. The best you can do is read the sector 10 times and take an average or something.

yes, i realize that the drive's built-in red book correction is what handles errors, and thus ImgBurn only "sees" the output of that process (and is thus at the mercy of the drive's behavior when the drive can't correct errors or mistracks).

Use EAC for ripping problem Audio discs.

i used EAC to copy CDs years ago, but totally forgot about it. thanks for the reminder!

 

interestingly, EAC sees only the SCSI CD-ROM drive, not the TSST SH-S223F DVD/CD reader/writer in the machine, so i can only use it to rip individual tracks.

 

and when i use EAC to rip the damaged track, i get a perfect copy from the SCSI CD ROM!

[LIGHTNING UK!]

The option you want is 'Ignore CD-DA Data'.

[rscottdrysdale]

i'll try next with the defective one i used before.

using ImgBurn to make two image files of the defective disc (using the TSST drive as a source) does indeed produce two different binary images:

 

G:\>dir a

Volume in drive G is RSD500G

Volume Serial Number is 10D8-093C

 

Directory of G:\a

 

07/21/2009 09:03 PM <DIR> .

07/21/2009 09:03 PM <DIR> ..

07/21/2009 09:02 PM 394,418,640 Image.bin

07/21/2009 09:02 PM 752 Image.cue

2 File(s) 394,419,392 bytes

2 Dir(s) 118,866,173,952 bytes free

 

G:\>dir b

Volume in drive G is RSD500G

Volume Serial Number is 10D8-093C

 

Directory of G:\b

 

07/21/2009 09:14 PM <DIR> .

07/21/2009 09:14 PM <DIR> ..

07/21/2009 09:08 PM 394,418,640 Image.bin

07/21/2009 09:08 PM 752 Image.cue

2 File(s) 394,419,392 bytes

2 Dir(s) 118,866,173,952 bytes free

 

G:\>fc /b "G:\a\Image.bin" "G:\b\Image.bin"

Comparing files G:\A\Image.bin and G:\B\IMAGE.BIN

11CAE0EE: B9 58

11CAE0EF: 02 03

11CAE0F6: 32 52

11CAE0FE: 54 DC

11CAE0FF: 0A 09

11CAE14E: F7 71

...

<cut for brevity>

...

11D00E8A: 3E A4

11D00E8B: 13 11

11D00E92: 17 A5

11D00E93: 0E 10

^CTerminate batch job (Y/N)? n

 

G:\>fc /b "G:\a\Image.cue" "G:\b\Image.cue"

Comparing files G:\A\Image.cue and G:\B\IMAGE.CUE

FC: no differences encountered

 

 

G:\>

[rscottdrysdale]

The option you want is 'Ignore CD-DA Data'.

my tests so far have been with "Ignore CD-DA Data" checked (apparently the default, as i don't remember changing anything in there).

 

with it unchecked, i do indeed get miscompares (starting at LBA 126565 offset 2310). happy happy, joy joy!

[rscottdrysdale]

interestingly, EAC sees only the SCSI CD-ROM drive, not the TSST SH-S223F DVD/CD reader/writer in the machine, so i can only use it to rip individual tracks.

duh. i didn't notice the (new to me) "create image" button in EAC.

 

i used EAC to make an image of the defective disc from the NEC SCSI CD-ROM, and burned it with ImgBurn to the TSST DVD/CD burner. result: perfect CD!

 

EAC's "error correction" stuff didn't even light up. i guess the antique CD-ROM is really good at handling errors itself, which more than makes up for it's BLAZING 2.5X speed!

 

thanks for your attention and patience.

 

ps: it would be nice if the "Ignore CDDA data" button had a name that gave a better clue as to what it does

 

pps: automatically handling the "sample offset" problem wouldn't be hard - grab a big chunk of data once each from A and B, and slide one back and forth -512..512 bytes while comparing to automatically find the offset. use that offset until next operation (ie, until drive/disc/image file changes).

[rscottdrysdale]

just some observations from other tests i've done with the damaged cd. remember i have two drives attached to this machine - the internal TSST DVD/CD burner and external SCSI NEC CD-ROM. The Lite-On drive previously mentioned is in a different computer.

 

SUMMARY OF OLD OBSERVATIONS PREVIOUSLY POSTED:

 

1) making an image of the damaged disc with ImgBurn from the TSST drive creates images with skips (errors). ImgBurn reports no errors.

 

2) making an image of the damaged disc with EAC from the NEC drive creates perfect images. EAC was reading at 2.5X, and it's "error correction" lights never lit up.

 

NEW OBSERVATIONS:

 

1) the damaged CD plays fine in windows media player from the TSST drive, obviously at 1X speed. "enable digital CD audio for this CD-ROM device" is checked, so windows is reading the audio data over the SATA bus.

 

2) ripping the damaged track from the TSST drive with windows media player results in a file with skips. it ripped quickly, not sure what speed. no errors reported.

 

3) ripping the damaged track from the NEC drive with windows media player results in a perfect file. it ripped more slowly than the TSST, not sure what speed.

 

4) i figured out how to get EAC to see the TSST drive. when i create an image of the damaged CD with EAC from the TSST drive, it makes a perfect image. EAC was reading at 8x, and it's "error correction" lights never lit up.

 

CONCLUSIONS:

 

1) if ImgBurn could use my antique CD-ROM, i wouldn't need EAC.

 

2) it is possible to get good audio from the TSST drive, cuz EAC can do it and 1x playback can do it.

 

is there any development effort planned for ImgBurn to improve audio reads? perfectly understandable if not, as you appear to be concentrating on the bleeding edge of things, not the old rusty edge.

 

but fixing either of these would induce me to send another donation

[LIGHTNING UK!]

Do me a favour please, open up EAC again and go into the drive config (with the NEC selected and an audio cd in the drive) - you'll find that in the 'File' menu.

 

Select the 'Drive' tab and click the 'Autodetect read command now' button.

 

Then tell me what it says in the 'Drive read command' box.

 

I assume setting the audio read speed to 1x in ImgBurn doesn't work for the TSST drive?

[rscottdrysdale]

Do me a favour please, open up EAC again and go into the drive config (with the NEC selected and an audio cd in the drive) - you'll find that in the 'File' menu.

 

Select the 'Drive' tab and click the 'Autodetect read command now' button.

 

Then tell me what it says in the 'Drive read command' box.

NEC & TSST both say "Read command MMC1".

 

to get the TSST drive working with EAC, i installed the nero wnaspi32.dll alongside eac.exe, so EAC is using that. ImgBurn is using the microsoft interface.

I assume setting the audio read speed to 1x in ImgBurn doesn't work for the TSST drive?

i had not yet tried that. but when i try now, it doesn't seem to be paying attention...

 

1) select menu "Mode/Read"

2) in the "Settings" box at the bottom right, i see "Read Speed X / Y" and "Add to Write Queue When Done". if i change both X and Y to 1x and start the read, it'll quickly get to 8x anyway. is there some other knob i need to frob?

[rscottdrysdale]

4) i figured out how to get EAC to see the TSST drive. when i create an image of the damaged CD with EAC from the TSST drive, it makes a perfect image. EAC was reading at 8x, and it's "error correction" lights never lit up.

i must have had my head up my ass when i wrote that. EAC *cannot* get a clean image from the damaged CD using the TSST drive. i guess with the pile of various images from various drives and various programs using various settings, i looked at the wrong one.

 

both EAC and ImgBurn can get a clean read of the damaged disc (even at 24x speed) on the LiteOn DH20A3H in another machine.

 

so what have i learned?

 

1) the TSST SH-S223F CD/DVD burner is really awful at reading audio CDs.

 

2) the LiteOn DH20A3H / Ativa DH-3H20A CD/DVD burner is a good thing.

 

3) the NEC 466 CD-ROM is an oldie but goodie.

 

4) in my experience, ImgBurn works just was well as EAC when reading a damaged disc. there may be exceptions.

 

5) ImgBurn *still* can't use my NEC 466 CD-ROM

[LIGHTNING UK!]

8x appears to be the slowest read speed supported by the TSST drive - it is on 223F drive anyway.

 

I've ordered couple of old NEC SCSI CD-ROM drives from eBay so I'll look into why it fails when they arrive (I already have an idea but I'll need the drives for testing with anyway).

[rscottdrysdale]

8x appears to be the slowest read speed supported by the TSST drive - it is on 223F drive anyway.

another strike against it.

I've ordered couple of old NEC SCSI CD-ROM drives from eBay so I'll look into why it fails when they arrive (I already have an idea but I'll need the drives for testing with anyway).

i would've been happy to run any experimental code here. but i understand the value of having a "problem" drive available for debug and especially regression testing.

 

do you ever have marathon "try every drive we have" sessions?

[rscottdrysdale]

2) the LiteOn DH20A3H / Ativa DH-3H20A CD/DVD burner is a good thing.

just to clarify - it's a "good thing" after flashing the Ativa with LiteOn YP5W firmware (going backwards to make it appear to be a LiteOn drive instead of Ativa), then flashing with LiteOn YY11 firmware.

[spinningwheel]

[LIGHTNING UK!]

Typical, no problem here!

 

I 12:50:42 ImgBurn Version 2.5.0.1 Beta started!

I 12:50:42 Microsoft Windows Vista Ultimate Edition (6.0, Build 6002 : Service Pack 2)

I 12:50:42 Total Physical Memory: 3,405,392 KB - Available: 1,863,664 KB

I 12:50:42 Initialising SPTI...

I 12:50:42 Searching for SCSI / ATAPI devices...

I 12:50:43 Found 1 CD-ROM, 2 DVD

[rscottdrysdale]

Typical, no problem here!

whiskey tango foxtrot, over?

 

okay, i did some more tests. cast of characters:

 

ImgBurn: 2.5.0.0

 

CD1: original damaged CD (INXS - Listen Like Thieves)

CD2: another manufactured CD (Tangerine Dream - Stratosfear)

CD3: clone#1 of CD1. i forget if it was made with EAC or ImgBurn and from/to which drive, so...

CD4: clone#2 of CD1. read by ImgBurn with LiteOn drive, burned by ImgBurn with TSST drive.

 

NEC: external SCSI (via adaptec 2906) NEC 466 CD-ROM (FW 1.06)

TSST: SATA TSSTcorp CDDVDW SH-S223F (FW SB03)

LiteOn: IDE LiteOn DH20A3H (FW YY11). this drive was originally Ativa branded, but has been brainwashed.

 

computer1: Intel mobo, P4HT 3.2GHz, 1G RAM, WinXP, hosts NEC and TSST (and three DAT drives - two for audio, one for backup).

computer2: Dell 2350, P4 2.8GHz, 1G RAM, WinXP, hosts LiteOn.

 

reading with NEC:

 

CD1: FAIL

CD2: OK (!!!!)

CD3: FAIL

CD4: FAIL

 

reading CD1-4 with any other drive (TSST, LiteOn): all OK.

 

so it seems that the INXS CD and the NEC just don't get along at all. each time it fails, the problem is:

 

I 10:17:11 Operation Started!

I 10:17:11 Source Device: [4:4:0] NEC CD-ROM DRIVE:466 1.06 (E:) (SCSI)

I 10:17:11 Source Media Type: CD-ROM

I 10:17:11 Source Media Sectors: 167,695

I 10:17:11 Source Media Size: 394,418,640 bytes

I 10:17:11 Source Media File System(s): None

I 10:17:11 Read Speed (Data/Audio): MAX / MAX

I 10:17:11 Destination File: G:\llt liteon - nec.bin

I 10:17:11 Destination Free Space: 119,768,334,336 Bytes (116,961,264 KB) (114,219 MB) (111 GB)

I 10:17:11 Destination File System: NTFS

I 10:17:11 File Splitting: Auto

I 10:17:41 Reading Session 1 of 1... (11 Tracks, LBA: 0 - 249186, MCN: 0075678127724)

W 10:17:41 Failed to Read Sector 0 - Reason: Illegal Mode For This Track

I 10:17:41 Reading Track 1 of 11... (AUDIO/2352, LBA: 0 - 17584)

W 10:17:41 Retrying (1 of 20)...

W 10:17:41 Retry Failed - Reason: Illegal Mode For This Track

W 10:17:41 Retrying (2 of 20)...

...

W 10:17:41 Retry Failed - Reason: Illegal Mode For This Track

W 10:17:41 Retrying (20 of 20)...

W 10:17:41 Retry Failed - Reason: Illegal Mode For This Track

E 10:20:52 Failed to Read Sector 0 - Reason: Illegal Mode For This Track

E 10:20:52 Failed to Read Sectors!

I 10:20:52 Exporting Graph Data...

I 10:20:52 Graph Data File: C:\Documents and Settings\enduser\Application Data\ImgBurn\Graph Data Files\NEC_CD-ROM_DRIVE-466_1.06_TUESDAY-JULY-28-2009_10-17_AM_N-A.ibg

I 10:20:52 Export Successfully Completed!

E 10:20:52 Operation Failed! - Duration: 00:03:41

E 10:20:52 Average Read Rate: N/A - Maximum Read Rate: N/A

 

is it possible there's some kind of primitive copy protection (or just a mastering goof) on the INXS CD?

 

note that the damage to the disc (where my stereo-component DVD player skips and the TSST skips) is 75% into track 9 of 11, so i don't think any critical data is damaged on the disc.

 

would you like me to send you a copy of the image file, or does this go into the "too weird, enough time wasted" file?

 

EDIT: note that EAC can read CD1-4 just fine from the NEC drive...

Edited July 28, 2009 by rscottdrysdale

[AndrisL]

If computer methods don't help, i use last one, but usually effective method - polish. Nothing very special required. I have successfully used even car's color restorer liquid. For deep scratches manual polishing can take long time. In this case i used electric polish (orbital sander). But it requires to be careful.

Of course, it help only for scratches in plastic (bottom) side of CD. No way to restore CD with damaged data carrying (upper) layer.

Results may be not so god for CD-R, CD-RW or DVD. Possible because of polishing plastic layer transparency is going little reduced.

Note: before use this methode for valuable CD, try on something worthless!