[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dvd md5sum connundrum

Gene Heskett wrote:


Since I finally got subscribed for real, I've added the lists address
in the to: line.

Warning, newbie at dvd writing thinking out loud here.

I've been playing with cli stuff here, and failed in my quest to use
the data from the dvd+rwmediainfo utility.  It returns a value for used
blocks that is about 27k too long in round figures.

Using that, I read it with dd if=/dev/cdrom bds=2048 count=595536|md5sum
which gave the wrong answer, so I tried it with 595535 and also got the
wrong answer.

Then I fired up kcalc and calculated the number of 2048 byte blocks in
the iso image, and came up with 595523.  Substituting that count in the
above command line now gives the correct md5sum for the disk as written.

Now, since the iso image must be available for this idea to work, and as
the info utility doesn't appear to report an accurate location for the
leadout (which I would ASSUME starts immediately at the end of the

Media Book Type:       92h, DVD+RW book [revision 2]
Legacy lead-out at:    595536*2KB=1219657728

Which is longer than the iso:
-rw-r--r--  1 root root 1219631104 Nov 18 05:03 CAELinuxBeta1.iso

by 26624 bytes, or 13 2048 byte blocks, is there a std for this
'padding' that we could subtract, or are we doomed to use the iso's
actual size to determine the amount of data to feed to md5sum to make it
work in this scenario?  How about subtracting a (MOD(64k)/size)/2048 on
the mediainfo returned size?

Since it depends on your software, firmware, and in the reading process the kernel version, I would suggest that you just use the ISO image size. This can be gotten from the isoinfo program (came with cdrecord, I think) using the -d option.

I'm open for ideas and insights.  This is a problem that the broken
dvd filesystem gives us, and it needs to be fixed in a joe six-pack can
use it manner.

I think you just want to get the size and do the md5sum on that. The actual size on the media doesn't really matter, since all you have is the original md5sum, so you should only read back the data that originally covered.

For data where one added file per directory doesn't cause problems I embed the 'contents.md5' file created in the hierarcy with 'sumdir' and that allows both an overall check but also a "which file is bad" check. DVDs do age and develop problems, it's nice to be able to identify them and a finer level than "this DVD went bad."

bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

Reply to: