Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Alright, I am probably being an idiot here, but I am writing an ISO-ripping util that is really just GUI slapped on top of dd, and I can't coax the thing to produce non-corrupt ISOs on Snow Leopard. I have tried the following variations (all with /dev/disk1 unmounted as it should be):

dd if=/dev/disk1 of=/Users/[me]/Desktop/anIso.iso bs=2048 conv=sync,notrunc
dd if=/dev/disk1 of=/Users/[me]/Desktop/anIso.iso bs=2048 conv=notruc 
dd if=/dev/disk1 of=/Users/[me]/Desktop/anIso.iso bs=2048
dd if=/dev/disk1 of=/Users/[me]/Desktop/anIso.iso

in all four cases, clicking the iso that is produced gives me a popup that says "the following disk images could not be read" and lists the file. If it's any use, output (at least for the first variation of the command) is:

408258+1 records in
408259+0 records out
836114432 bytes transferred in 513.382815 secs (1628637 bytes/sec)

Any ideas? I read the man pages, variation 1 definitely seems like it should produce an iso from the specified cd

share|improve this question
    
This wants to go to superuser, I think. –  T.J. Crowder Feb 7 '10 at 17:10
    
wait, are you trying to make ISOs of data discs or audio discs?? your process should work for data discs. audio is a different beast, however. –  quack quixote Feb 9 '10 at 0:48
    
In this case, trying to make an ISO of an audio disk. What's the difference. Guess I've been really naive about this. Thought an image was an image. Probably would have served me to check the wikipedia before I jumped in... –  znice Feb 9 '10 at 1:17
add comment

migrated from stackoverflow.com Feb 7 '10 at 20:49

This question came from our site for professional and enthusiast programmers.

5 Answers

For a CD-ROM, use /dev/disk1s0 and not /dev/disk1.

/dev/disk1 will access the raw 2352-byte blocks, which is useful if you are reading an audio CD. On a CD-ROM, 2048 of the 2352 bytes are used for data and most of the rest are for error correction. When you read /dev/disk1s0, it will use the error correction codes to correct any errors if possible and return the (possibly corrected) 2048 data bytes of each block, which is what you want for an ISO image.

Note that this is different for DVD-ROM, where you would use /dev/disk1. DVD-ROM uses a different error correction scheme which spreads the data across the disk more in order to provide better error resilience. There is not a separate device name that can be used to read the DVD data with the error correction codes included.

share|improve this answer
    
+1 interesting! –  quack quixote Feb 9 '10 at 0:45
    
There doesn't seem to be a /dev/disk1s0, only /dev/disk1s[1-last track], and /dev/disk1s1 definitely seems to be the first track on the record. Tried passing /dev/disk1s0 as infile into dd anyway (in spite of it not being listed among disk partitions) and dd complained that there was "No such file or directory". Thanks all the same, though. Very odd business (or not?) –  znice Feb 9 '10 at 0:47
    
/dev/disk1s0 is used to read the CD-ROM data. If the CD is audio only, then there will be no /dev/disk1s0, only disk1s1, s2, etc. for each audio track. –  mark4o Feb 9 '10 at 1:01
    
An audio CD does not contain a filesystem, so you cannot create a mountable ISO image of an audio CD using dd. –  mark4o Feb 9 '10 at 1:13
    
So how do you rip an image of an audio CD?...Or can you not (can you only copy the data that constitutes each track) –  znice Feb 9 '10 at 1:18
show 1 more comment

Audio CDs are generally not ripped with dd and stored as ISOs. Audio CD data (CDDA) is closer to tracks on a phonograph record, spiraling inward with gaps marking the boundaries. They do not contain a filesystem.

Instead, audio CD data is usually ripped with programs like cdrdao or cdparanoia. Instead of an ISO file, audio CDs are generally stored as BIN/CUE pairs, WAV/CUE pairs, or individual WAV files for each track. The CUE file is an ASCII text file containing the layout of the tracks, and the BIN or WAV files contain the actual audio data.

With cdparanoia:

# read cd's table of contents
cdparanoia -Q

# rip several (1 thru N, inclusive) tracks to one big file
cdparanoia --batch 1-N bigfile.wav

With cdrdao:

cdrdao read-cd --read-raw --datafile foo.bin --device ATAPI:0,0,0 --driver generic-mmc-raw foo.toc

See the Ripping and Burning from the Command Prompt How-To for lots more gory details.

share|improve this answer
add comment

Not sure what is going on, but have you tried comparing the source and target afterwards?

Maybe:

od -c source > source.txt
od -c target > target.txt
diff source target

I guess this will generate some pretty big files and I'm not sure how useful the diff output will be - but at least it should provide an answer as to whether the files are the same or not.

You running 'FileVault' or anything on your machine ? Not sure if that could affect this type of thing ?

Does the dd work with other types of binary files? (try copying '/bin/ls' to another file and see if it still works?)

share|improve this answer
    
running diff right now, may not have the patience to let it finish (the octal dumps are really, really huge). For whatever it's worth, the dumps are the EXACT same size. –  Anonymous Feb 7 '10 at 19:07
    
Wait, spoke too soon, diff just finished. Output: 51727460c51727460[line break] < 6165410140[line break] --- [line break] > 6165414000 –  Anonymous Feb 7 '10 at 19:09
add comment

for comparing binary files use cmp, not diff...

if you still wanted to compare them in hex run

diff <(od -c source) <(od -c target)

I would test this with a cd you have already burned and verified from an iso, then compare the original iso with your iso.

it would have been useful to know if all of the images you extracted were the same or not.

also /dev/disk1 doesn't look right, are you sure that is a cd drive?

836114432 is also 797MB, does that even make sense for the disk you are using?

share|improve this answer
    
running cmp right now, may take a while. diskutil reports disk is 836.1mb, but I guess its measure of an mb is 1mil bytes even. –  znice Feb 9 '10 at 0:53
    
cmp output: "cmp: EOF on /dev/disk1". Is that meaningful/helpful? Again, apologies for my ignorance on this subject –  znice Feb 9 '10 at 1:02
add comment

For whatever it's worth, this is what diskutil tells me about the disk that's currently in the drive:

      Device Identifier:        disk1
   Device Node:              /dev/disk1
   Part Of Whole:            disk1
   Device / Media Name:      MATSHITA DVD-R UJ-868

   Volume Name:              West Side Story
   Escaped with Unicode:     West%FF%FE%20%00Side%FF%FE%20%00Story

   Mounted:                  No

   File System:              CD-DA
   Type:                     cddafs
   Name:                     CD Audio

   Partition Type:           CD_partition_scheme
   Bootable:                 Not bootable
   Media Type:               
   Protocol:                 SATA
   SMART Status:             Not Supported

   Total Size:               836.1 MB (836112480 Bytes) (1633032 512-Byte-Blocks + 96 Byte(s))
   Volume Free Space:        0 B (0 Bytes) (exactly 0 512-Byte-Blocks)

   Read-Only Media:          Yes
   Read-Only Volume:         Not applicable (not mounted)
   Ejectable:                Yes

   Whole:                    Yes
   Internal:                 Yes
   OS 9 Drivers:             No
   Low Level Format:         Not Supported

   Optical Drive Type:       CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-R DL, DVD-RW, DVD+R, DVD+R DL, DVD+RW
   Optical Media Type:       CD-ROM
   Optical Media Erasable:   No
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.