[plug] cdr software

[Bernard Blackham]

On Wed, May 29, 2002 at 07:41:41PM +0800, Robert Davies wrote:
> I have a cd that is mission critical to a client, whom has purchased from
> manufacturer. The problem being program is irreplaceable, client needs a
> copy, but when trying to duplicate via xcdroast program refuses to read
> track. So cannot copy, anybody have solution seems to be same scenario as
> a game cd.

Robert,

If all else fails, I usually recover cd's the hard way using dd and
cat, to collect all the data on a disk that it can, and fill in the
rest with zero's. You probably only want to do this as a very last
resort! This isn't ideal but has saved me *many* times.  I've been
meaning to write a script to do this but the general procedure is as
follows (note it requires a bit of arithmetic):

       dd if=/dev/cdrom of=cdrom-img-0.img bs=2k
  
  *wait till it dies (horrible sounds from drive, ATAPI errors in
  /var/log/syslog), and hit eject and/or ctrl+c*

  dd will say something like
  8412+0 records in
  8412+0 records out

  keep track of this number, add maybe 200 or 300 to it, and use
  that as your next starting point. eg:

       dd if=/dev/cdrom of=cdrom-img-8600.img bs=2k skip=8600

  and if it doesn't finish due to another scratch, dd might say
  something like
  15313+0 records in
  15313+0 records out

  so repeat, using 8600+15313 and your new starting point, count
  forward a few hundred blocks (lets say to 24000), and repeat.
  (note you can usually see on the disc what scratches correspond to
  what sector numbers its bailing at - starts from the inside out,
  and there are roughly 300,000 2k sectors on a 650MB CD). so:

       dd if=/dev/cdrom of=cdrom-img-24000.img bs=2k skip=24000

and continue till it next dies or finishes. do you get the idea?
Depending how critical the information is, you can try getting
closer and closer to the scratch (tuning the numbers). Is fiddley
but if it's critical, it works.

*Then* to stitch them together, you need to `cat` all the files
together, and dd some /dev/zero in between to fill in the blanks.
eg, for above:

   cat cdrom-img-0.img > cdrom-recovered.img
   dd if=/dev/zero bs=2k count=$((8600-8412)) >> cdrom-recovered.img
      * note the use of >> instead of >, and also getting the shell
	    to do the arithmetic for you

   cat cdrom-img-8600.img >> cdrom-recovered.img
   dd if=/dev/zero bs=2k count=$((24000-(8600+15313))) >> cdrom-recovered.img
   cat cdrom-img-24000.img >> cdrom-recovered.img

   and so on until you get the entire image. Mount the image on a
   loop back ("mount -t iso9660 -o loop cdrom-recovered.img /mnt")
   and test there is a filesystem there, and if its good, burn it.

Is this making any sense? If it seems a little too hard, I plan to
write a script to do it automagically sometime soon because it's
something I've done all too often lately.

Note that this will also lose some data from the disc (but hey it
probably wasn't recoverable anyway), so some files may appear
corrupt but at least the rest is saved. Also if the scratch is near
the very beginning of the disc, you could possibly lose the CDs TOC
which bascially means the CD is unusable (unless you want to have
some real fun rebuilding it), but I've never had this happen to me.

Another method a friend told me is to wipe over the cd with a
solvent of some form, but I wasn't keen to do this at the time, nor
do I recall which solvent it was.

Hopefully, your cd has just a small scratch somewhere, so it
shouldn't be too strenuous.

Regards,

Bernard.

-- 
 Bernard Blackham
 bernard at blackham.com.au
 Australian Linux Technical Conference 2003: http://conf.linux.org.au/