Re: Reading MtRainier CD in plain CD unit?

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> xorriso : UPDATE : 359848 of 359848 sectors examined in 5404 seconds

You really did let it gnaw to the end.
(I hope the drive noise was not too frightening.)


> Media checks :        lba ,       size , quality
> Media region :          0 ,       1632 , + good
> Media region :       1632 ,         32 , - unreadable
> Media region :       1664 ,         16 , + slow
> Media region :       1680 ,         15 , + partial
> Media region :       1695 ,          1 , - unreadable
> ...
> Media region :     295264 ,      64584 , - unreadable

The bad spots look not overly encouraging.
The ones at block address 1632 and 1695 might well have hit
the UDF directory tree.
The big one at the end predicts that about 128 MB of file data
will be unreadable. Also hit would be the hinder "anchors" of
UDF. There should be a copy at address (1024 + 256), though.

So it is not totally hopeless (but nevertheless a different
drive with MRW capability promises more success).

------------------------------------------------------------------

You could copy the readable blocks to a file on hard disk.

  xorriso -outdev /dev/sr0 \
          -check_media use=outdev what=disc time_limit=3600 \
                       data_to=$HOME/copy_of_mrw \
   2>&1 | tee -i $HOME/log_of_copy_of_mrw

This will copy the readable blocks to their proper addresses
in file  $HOME/copy_of_mrw . The inner bad blocks will not be
copied and will contain 0-bytes in the copy. The bad blocks
at the end will not be part of the copied file.

This run will log all message output in file
  $HOME/log_of_copy_of_mrw

I assume that your read attempt reached the final area of bad
blocks already after less than an hour. So you could reduce the
time_limit to 3600 and spare your drive the useless effort.
If this does not reach block 295264, then you may re-run with
additional options of -check_media:

          -check_media use=outdev what=disc time_limit=3600 \
                       data_to=$HOME/copy_of_mrw \
                       min_lba=... \
                       max_lba=295264 \
  
The value of min_lba= would be the first number in the last
visible message of the form
   xorriso : UPDATE : 123456 of 359848 sectors examined in 3600 seconds 
I.e. here: 123456.
It is harmless to retrieve blocks twice.

After the file is copied to disk as good as possible, you would have
to cut off its first 2 MB and try to mount the rest.
This is a bold try and might stress you operating system.
So better do not attempt this while important jobs are running.

Cut off (needs another 600 MB of disk space, i fear):

  dd if=$HOME/copy_of_mrw \
     of=$HOME/daa_copy_of_mrw \
     bs=2048 skip=1024

The resulting file $HOME/daa_copy_of_mrw would be the payload
area of the MRW. (If i understand the specs correctly.)

A first try to find the UDF Primary Volume Descriptor would be
  dd if=$HOME/daa_copy_of_mrw \
     bs=2048 count=1 skip=257 \
  | strings | fgrep OSTA
If this says
  OSTA Compressed Unicode
then you probably have an UDF there.
(Regrettably the anchor at block 256 seems to have few redundancy
 by which it could be recognized. The Volume descriptor address 257
 is quite a guess.)


For mount-safety add the missing blocks as 0s:

  dd if=/dev/zero bs=2048 count=64584 >>$HOME/daa_copy_of_mrw

The eventual mount test would be done as superuser:

  mount -o loop .../daa_copy_of_mrw /mnt

(Instead of "..." you insert the $HOME directory of the user who
 created the file daa_copy_of_mrw. Directory /mnt has already to
 exist and should be empty.)

Then do

  ls -l /mnt

and hope for files being visible.

------------------------------------------------------------------------


Have a nice day :)

Thomas