[ILUG] Copying CDs with dd

[Brian Foster]

  | From: "Josh Glover" <jmglov at wmalumni.com>
  | Date: Fri, 6 Jul 2007 22:12:21 +0900
  | 
  | On 06/07/07, Michael Watterson <watty at eircom.net> wrote:
  | > dd is not going to help except on the less smart anti-copy protection.
  | 
  | Not sure I agree with this; dd makes a bitwise copy.  [ ... ]
  | the CD produced should be an exact replica of the orginal;
  | copy protection intact.

 the CD must be a data CD.  since it is a bit-wise copy,
 the format of the data (i.e., ISO-9660, tar(1) archive,
 proprietary, whatever) is not relevant (provided, of
 course, you copy the entire CD).

 however, dd(1) cannot copy audio CDs:  data CDs have
 an I-forget-how-many number of ECC bytes per sector,
 but audio CDs do not.  what are ECC bytes on a data
 CD are use as additional payload bytes on an audio CD.
 the occasional bit-error is considered Ok for audio,
 but would be a disaster for data.

  | Some CDs employ bad sectors and shite, but dd should not care about those.

 eh?!  if the bad sector or whatever causes a read(2)
 error, `dd' will most certainly care (in its default
 mode of operation).

 the ILUG archives contain several previous threads
 on both the differences between data and audio CDs;
 and on `dd'(-like) programs and I/O error handling.
 but, _guessing_, the contents of both the ECC bytes
 (and payload) for the "bad" sectors matters to such
 copy-protection schemes, naïve `dd' is probably not
 the tool to use.  what the "correct" tool is, and
 it's legality, I do not know.

cheers!
	-blf-
-- 
▶ ▶  I AM CURRENTLY LOOKING FOR A JOB!  ◀ ◀ | Brian Foster
Experienced (>25 yrs) software engineer:    |        Montpellier, FRANCE
 • Unix, Linux, embedded, design-for-test;  | Stop E$$o (ExxonMobile)!
 • Software/hardware co-design, debugging;  |     http:/www.stopesso.com
 • Kernels, drivers, filesystems, &tc;    Résumé (CV) & contact details:
 • IDL, automated testing, process, &tc.   http://www.blf.utvinternet.ie