Like nero on windows growisofs and others produce a disk with additions from the original iso.

cdrecord appears to be different you can do a dd if=/dev/hdc | md5sum and it will be the same as the iso you burn't from.

For growisofs and the likes this is a good way to verify when the cd is different to the iso:
http://www.g-loaded.eu/2006/10/07/ve...mage-on-linux/


I am glad I can just do dd if=/dev/hdc | md5sum with cdrecord (easyer than following that link) but I would like confirmation that what I am experiencing is true not just a glitch on my machine or something.

Also to discus is this a good thing? apparently other programs (like growisofs) change the md5sum because they finish the disk by additional writing, does cdrecord become an issue if its just leaving it as is?


Thanks, WOTHed

That method you describe can give errors at times. Here's an article that goes into a more accurate way of verifying whether your burn is good:

http://troubleshooters.a3b3.com/linux/coasterless.htm

Note the use of the author's "rawread" script which incorporates the information from "isoinfo" into the dd command for greater accuracy.

Read your link (it looks good) So... md5sum myiso.iso rawread /dev/cdrom | md5sum is basicly md5sum myiso.iso dd if=/dev/cdrom bs=<determinednum> count=<determinednum> /dev/cdrom | md5sum but this only works on cdrecord, growisofs and nero (and mabye allothers) change the md5sum with this aproch because of stuff that gets added when they close the disc. Can you confirm I am right?

For cdrecord I will use rawread but with growisofs you have to use: http://www.g-loaded.eu/2006/10/07/ve...mage-on-linux/ The verification discribe there will work for growisofs. I don't belive your way will work for growisofs.

My question is which way (to burn) do you think is better cdrecords or growisofs. Like I would like to know if cdrecord doesn't add any more informaton to seal etc, does the disc seal properly? Cheers, WOTHed

I'll have to read your article in more detail but at first glance they seem to both require the block count when doing an md5sum of a cd or dvd:
The main difference is that your article is using output from growisofs or a complicated procedure using ls and awk on information outputted from mkisofs to calculate the block count on the generated iso whereas my article uses the isoinfo command to get the block count on the burned cd-r/dvd-r and uses this info when checking the md5sum of the cd-r/dvd-r against a presumably downloaded iso with a known good md5sum. I haven't confirmed it, but I think the block counts should be identical with all three methods. Once the block count is obtained, both articles require it's use when doing the md5sum on a burned cd/dvd. My article does this implicitly in the rawread script and yours explicitly sets out the procedure.

If I have time I will try and check this out by generating my own iso on some data files with mkisofs and and comparing the block counts obtained using all three methods.

I can tell you that I have successfully used rawread to to make backup isos of commercial software on cd/dvd and have reburned the iso when I've lost the original cd/dvd. Generally, I use k3b to do the burning but the md5sums on the original cd, the backup iso and the cd-r/dvd-r burned from the backup iso have always matched when using rawread. The only problem is when the original cd/dvd employs certain copy protection systems. There, the md5sums still match but the if you try to install from the copied cd/dvd the fact that it is a copy is detected and the install will abort with a message to use the original cd/dvd.

Ok tried your article and it is more to the point than mine (mine was about making iso not dding them) I didn't realize they were saying the same thing about block size and volume size I will use isoinfo -d -i /dev/cdrom from now on or the script.

Never the less I will show you what happened that makes cdrecord different:

First the correct way:


$isoinfo -d -i /dev/cdrom1

this tells me bs=2048 count=2246210 so:

$dd if=/dev/cdrom1 bs=2048 count=2246210 of=bla.iso

$md5sum bla.iso

result is 9c5bcb0d4a46f9c44a6bda9b3a0dd317

$dd if=/dev/cdrom1 bs=2048 count=2246210 | md5sum

result is 9c5bcb0d4a46f9c44a6bda9b3a0dd317

doning the wrong way produces good results anyway(this time):

$dd if=/dev/cdrom1 | md5sum

result is 9c5bcb0d4a46f9c44a6bda9b3a0dd317


Take out origanal put in blank:

$growisofs -Z /dev/hdc=bla.iso


$isoinfo -d -i /dev/cdrom1

gives same peramerters as before so:

$dd if=/dev/cdrom1 bs=2048 count=2246210 | md5sum

yes your right result is 9c5bcb0d4a46f9c44a6bda9b3a0dd317 !

Now for the wrong way:

$dd if=/dev/cdrom1 | md5sum

result is 70fb90655e610aedc31f961790240877 failed to match so you can see growisofs has added some more stuff at the end mabey in sealing the disk, funly enough a copy i made in windows on nero put back in my linux box produce the same results [the goodsum then the bad])


now put in another blank and:

$cdrecord -dao -dev=ATA:1001,0,0 bla.iso


$isoinfo -d -i /dev/cdrom1

gives same peramerters as before so:

$dd if=/dev/cdrom1 bs=2048 count=2246210 | md5sum

result is 9c5bcb0d4a46f9c44a6bda9b3a0dd317 !

Now for the wrong way:

$dd if=/dev/cdrom1 | md5sum

result is 9c5bcb0d4a46f9c44a6bda9b3a0dd317 ! So cdrecord does not affect the new disk with additional end stuff!




Your link is very useful and I understand a lot more now but I don't seem to need it for cdrecord, I think I'll do that last step the wrong way just to see if it ever fails.




So in concluding: cdrecord is different in that it doesn't add "finishing data" (if thats what it is).


Why and is this good or bad? the original I believe was home made so maybe cdrecord grabbed the "finishing data" and used it in a finishing manner again without adding more again, or maybe it just slapped it on.


I'm just wondering why growisofs and nero work so differently than cdrecord.




PS: Thanks for your help I understand dd more now.

I guess I just want to know how to reproduce this

$dd if=/dev/cdrom1 | md5sum
70fb90655e610aedc31f961790240877 -
8984896+0 records in
8984896+0 records out
4600266752 bytes (4.6 GB) copied, 411.94 s, 11.2 MB/s

with cdrecord instead of growisofs.

If theres a flag or something to make the total output burned by cdrecord to disc look like / match growisofs please post.

Ok to answer my own question:

Adding the option padsize=14s will give the same md5sum to the disc.

I'm surprised it's not padsize=15s because thats the default if you have just plain -pad, so it seems growisofs and nero default to 14.

So if you have no padding (which is the default for cdrecord) you don't need bs=<size> or count=<times> for getting an accurate md5sum but if you pad (which is a good idea) you need to have the right count and bs so you don't md5sum the pading!

I recommend everyone use http://troubleshooters.a3b3.com/linux/coasterless.htm
for instructions!

Thanks again kilgoretrout

Q:cdrecord writes iso's without adding data, unlike any other burning program confirm?

A:No there is no differents except it doesn't pad by default.
Add padsize=14s to you line of options and it will pad the same as growisofs and nero.

This thread is solved I have know idea how to add solved to the title but it is

Thanks for this information. I don't understand why cdrecord and growisofs do not come with a built in verify option.

I am having difficulties using dd to verify a dual layer DVD+R disc: It consistently bombs out after 4.0Gb. I'm using your command

Any ideas why this might not work?

I am having a nightmare getting these dual layer discs to work reliably.