-   Linux - Hardware (
-   -   BD md5sums differ (

linuxbird 12-05-2012 01:46 PM

BD md5sums differ
After adding a BD drive to one of my systems, I thought I would check it out before I entrust it to safeguard my backups.

So I built a 23 gb disk, using k3b, and wrote it and verified it. So far so good.

Then I used


dd if=/dev/dvd bs=5120 | md5sum
to obtain a md5 check sum of the disc.

Low and behold, I find that the values are different each time I read the disc, and compute a new md5sum.

From what is here, and what you might know, have I done something obvious which would cause there to be a different md5sum each time I read in the 23 gb disc?

linuxbird 12-06-2012 04:38 AM

I have had time to do a few more tests.

-reading DVD+RW discs results in consistent identical MD5SUMs.
-reading the subdirectories of the BD I test burned appears to yield consistent results (limited sample size thusfar). I did that with the following:

find subdir1 | cpio -oc | md5sum
A Nero utility is reported to provide the number of media errors that are encountered reading optical media. I am searching for a linux utility with equivalent capability.

Asus, the label for the drive I am using, responded to a tech support question, and told me that they only support their drives on Windows OS.

The primary reason I got this drive was for backup and archive, and I am just trying to prove that it is working well. If not, my strategy will be to use harddrives for backup.

H_TeXMeX_H 12-06-2012 08:03 AM

You can try:

I recommend not using md5sum. Use 'cmp' instead to compare burned images. Use md5sum for other files.

linuxbird 12-06-2012 05:31 PM


Originally Posted by H_TeXMeX_H (Post 4843738)

I recommend not using md5sum. Use 'cmp' instead to compare burned images. Use md5sum for other files.

What is your reasoning on this? Is I/O done differently in md5sum?


H_TeXMeX_H 12-07-2012 04:04 AM

It could be that, or maybe padding that occurs.

linuxbird 12-07-2012 03:01 PM

I took the original BD, read it in to three files:


In doing compares between each ISO file, I found that the differences were all in a very specific region, but not a specific location. I am now rewriting the media with zeros, and then with random bytes in an effort to see if the fault location or modality can be identified. It is clear that each time I read the BD, there is a different byte somewhere. Reading DVD+RWs yields no differences.

Since the error is near the outer edge of the BD, I am thinking a media issue, rather than a writer issue, but that is a weak conjecture.

H_TeXMeX_H 12-07-2012 03:14 PM

If the error is near the edge it may be a manufacturing fault or a scratch.

linuxbird 12-08-2012 10:24 PM


Originally Posted by H_TeXMeX_H (Post 4844780)
If the error is near the edge it may be a manufacturing fault or a scratch.

You are right. There was no visible defect, but the best the naked eye will do is about 11 microns, so there could be an affective scratch, and I would not see it.

I now have some BD-RE DL media, and am doing more testing. The drive is pretty much running 24 hours a day with tests.

Here is my working hypothesis: There was a burn artifact, which created a marginal section of the media.

The same, and other media has been written and read multiple times, and I have not been able to reproduce the errors.

I did look at code for md5sum, and cmp. While cmp does a literal comparison, a false positive or negative with md5sum might happen only once in our lifetimes. So for a quick comparison, it is absolutely valid. However, it does not tell you where in a file a difference occurred. For that cmp is definitely desired.

It will probably take me several days for the next round.

All times are GMT -5. The time now is 06:58 AM.