I meant non-Audio... sorry. Anyway... it's interesting to see that dd will back up my VMS CD's. Meanwhile anyone here want to see some restrictions on MS software on critical government or "secure" systems. Geez... this "Love Bug" virus has hit AT&T and Lucent and a bunch of US government sites. Luckily, my wife was using Elm on Unix dialed in from home instead of Outlook or Exchange at work so she deleted the 150 messages at noon and another 150 last night. Exchange and Outlook (and the MS Exchange server and Visual Basic) have really revolutionized mail handling into a major virus breeding ground. All because it's too hard to use FTP or the web to push Powerpoint presentations around -- they mail 44mb files as attachments. UGH. Bill (an old dinosaur who misses the net like it was in '85-6) -- bpechter(a)monmouth.com | Microsoft: Where do you want to go today? | Linux: Where do you want to go tomorrow? | BSD: Are you guys coming, or what?

John Wilson wrote: The problem with direct CD to CD-R copy is that the OS, device driver, and even the CD-ROM drive do not have any reliable way to know how many sectors there are on the source disc, unless they can rely on file system data, i.e., the ISO 9660 header. If the disc isn't 9660, you'd need some other way to tell. On my system, I use a script I call cd2cdr to make copies of ISO 9660 discs: #!/bin/sh # direct disc-to-disc ISO-9660 CD copy source=/dev/hdc dest="0,6,0" speed=8 cdrecord -v dev=$dest speed=$speed -pad -isosize $source Obviously you'd need to modify the source, dest, and speed variables to suit your system. The -pad option tells cdrecord to write some extra empty sectors at the end, because some systems have trouble reading the last few sectors of a track. The -isosize option tells cdrecord to determine the size of the image from the ISO 9660 header. When writing from an image file (of any sort, not just ISO 9660), you do not need the -isosize header; cdrecord will use the file length.

John Wilson wrote: No (although perhaps some might not). I'm disputing that the drive will always (or even frequently) give the correct response to the READ CAPACITY command. That command uses the TOC of the disc to make up a number that is at best only vaguely related to the actual number of blocks in the image. If you're lucky, the number will be greater than the actual number of blocks, so that if you use it to do an image copy, you'll get *at least* all of the blocks that you should. But I've seen occasional cases where the reported number was less than the actual number of blocks.