[ILUG] Backing up a CD

[Kenn Humborg]

> > Well, first of all nothing can just take the "raw binary data" off a CD.
[...snip...]
> It should be possible to read raw binary data. Red/Yellow book is what you
> called it, a format. It should be (and as far as I know is) possible to
> read the raw data from the disk to create a binary image of the disk, by
> circumventing the formats.

It's _possible_, but not as straightforward as you imagine.  You
mention that you want to do

dd if=/dev/cdrom of=imagefile

for any type of CD format and have it work.  What about multiple tracks?
It's a bit like reading from tapes.  You can copy two files onto a tape,
for example:

   mt rewind
   dd if=file1 of=/dev/nst0
   dd if=file2 of=/dev/nst0

But there is no way (short of special custom data recovery apps) to get
a single file that describes this tape.  In other words:

   mt rewind
   dd if=/dev/nst0 of=some-file

will give you an exact copy of file1, not file1+file2.  There is additional
'metadata' on the tape that's not accessible outside the tape drive itself.

> > If NTI CD Maker Pro writes the entire CD to one binary file
> it's actually
> > doing the job of reading all the data sectors, grabbing the audio and
> > putting it all into one large binary file.
>
> I don't know how CD Maker Pro does it's copying. All I know is that it
> works! For example,
> I copy an Audio CD with xcdroast. It reads each track in turn to the HD
> then writes this to the CD-R. Unfortunately I lose the CD-Text and some of
> the track information is slightly out (i.e. track ends too quickly or in
> wrong place).
> I do an image copy of the CD with CD Maker Pro and then write it to the
> CD-R and I get a perfect copy of the original with the correct
> CD-Text, and
> any data tracks if present.

The file that CD Maker Pro is probably a proprietary format.  I don't know
of any standard format for storing anything fancier than a filesystem
image (eg .iso).

For example, Adaptec CD Creator (which I've used - I haven't used CD Maker
Pro) creates 'image' files in a format they call .CIF.  It's proprietary.

The problem is not "NT can do this, Linux can't", it's "nobody's written
the software and designed an open file format" for doing this.

> > > dd, will check the file format on the CD, and then make a
> binary file of
> > > this file format. For a CD this is an iso file, for ext2 it
> would create a
> > > binary ext2 file. For some reason it needs to understand the
> format which
> > > it is copying...
> >
> > dd copies the binary image of the data session to a file.  If
> the data on
> > the disc is in ISO format (CD filesystem) then the binary file
> will be in
> > iso format.  If you're reading a cd with an ext2 filesystem on it it'll
> > write an ext2 file.  It doesn't need to understand the format
> at all.  In
> > fact it could read an NTFS or FAT32 or even an Amiga filesystem (damn I
> > forget what they were called - Kate?).
>
> What I meant was that dd will only copy data from the drive in what ever
> format it's in (iso9660, FAT, NTFS, ADFS etc.). In Solaris there are two
> types of disk device, one for normal disk operation /dev/sdX and one for
> raw operations /dev/rsdX.
>
> If there is a raw disk driver for Linux then dd should be able to
> do what I
> want, but I don't know if one exists.

 From what I've seen, raw disk I/O in Linux means something else.
It's something like bypassing the kernel's buffer cache and
taking a more direct route to the disk.

And the actual on-disk format of the audio data on CDs doesn't lend
itself to being read by a kernel driver.  This has been discussed
on linux-kernel many times.  See

   http://kt.linuxcare.com/kernel-traffic/kt20000417_63.epl#5

for some discussion.  Basically, pulling _all_ the special info
from a CD is a user-land problem.  Defining a file format for the
reading/burning apps to use is a user-land problem.

And if the currently-available tools don't suit, then either

   1. Improve the tools
   2. Write new tools
   3. Pay someone to do 1 or 2
   4. Make a case to the maintainers of the tools
      to add these features.

Sorry!

Later,
Kenn