MD5Sums don't match, yet verification was "Successful".

[Knightofoldcode]

I'm not certain this is a bug, but I would certainly consider it one.

 

 

I slip streamed my Windows XP Service pack 2, with Service pack 3, and burned the resulting ISO to a printable Memorex 52X CD-R.

 

I burned on internal SATA drive, it completed and said the verification was complete, but the md5sum's don't match. Are they supposed to? I would think so. If not, I need to learn why, since I'm storing the image MD5Sums, (and printing them on the CD itself), hoping to use it to verify data integrity. After the initial burn I didn't look at the MD5Sum and tried to verify on a second USB burner, it failed. Then I tried to verify on a third USB drive, it failed at a different area. Then I tried to verify on original Internal SATA Drive, it completed successfully, but MD5sums don't match.....

 

 

Am I going nuts here?

 

 

Thanks,

Knightofoldcode.

 

I 15:54:27 ImgBurn Version 2.4.2.0 started!

I 15:54:27 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 3)

I 15:54:27 Total Physical Memory: 3,407,084 KB - Available: 2,647,340 KB

I 15:54:27 Initialising SPTI...

I 15:54:27 Searching for SCSI / ATAPI devices...

I 15:54:27 Found 1 DVD

[LIGHTNING UK!]

Sorry, I don't have an explanation for this.

 

They should match up for the media you're using and that fact that byte level verification between the image/device has obviously passed makes it even stranger that they don't.

 

All I can say to do is read the disc back to a new image and use 'comp' or some GUI tool to compare them that way, or of could use another md5 tool. It might give us a clue.

[Knightofoldcode]

Okay, so I'm not going nuts.

 

So ImgBurn verifies the disc by byte by byte and not by the md5sums? Of course they *should* be the same, but obviously in some cases....

 

I'm still playing and trying to figure out the cause, whether the drive is at fault and causing bad burns or if it's the media at fault. I've only got a few discs left of this media (kinda scary, actually) so I don't know if I will be able to play much more. I'm going to read back this failed burn (in the drive that burned it, and that successfully verified it), into a ISO, and do a md5sum on it and report back.

 

One thing I failed to mention in the original post was that the original ISO's md5sum was verified with a 3rd party program, so ImgBurn is correctly identifying the image's md5sum.

 

Knight.

[Knightofoldcode]

Okay, using ImgBurn I read the bad burn into an ISO. Then I did a md5sum (using 3rd party md5sum program) on it. It returned the same MD5sum that ImgBurn did for the Device's MD5sum: 0cd4b8871b4006644a31e11bfd711c77

 

I am personally not as concerned that the burn failed, but more concerned that ImgBurn didn't catch that it failed. If I hadn't been looking at the two MD5sums, I would have thought the disc was correctly burned.

 

So, I guess ImgBurn needs to look at both MD5sums as well as the byte by byte analysis?

 

Let me know if there is anything else I can do to help you, Lightning.

 

Knight.

[mmalves]

If you do a binary compare of the image read from the drive against the source image, what do you get?

[Knightofoldcode]

If you do a binary compare of the image read from the drive against the source image, what do you get?

 

 

Any suggestions on what software to use? I did a search on these forums and didn't see any prefered software for comparing ISO's.

 

 

Knight.

[LIGHTNING UK!]

You could just use the 'comp' command line tool.

 

When you know the offset where things start to change, divide that number by 2048 to get the sector number, then -1 tp get the LBA.

 

Then open both ISO's in IsoBuster (2 instances) and jump to that LBA.

 

Can I just ask, when you load the ISO in ImgBurn does the 'Sectors' value match the one in the disc info panel on the right?

[Knightofoldcode]

Can I just ask, when you load the ISO in ImgBurn does the 'Sectors' value match the one in the disc info panel on the right?

 

 

No, it's off by two sectors:

 

 

Good ISO Sectors: 329,184

Good ISO Size: 674,168,832 Bytes

 

Bad ISO Sectors: 329,182

Bad ISO Size: 674,164,736 Bytes

 

I'll get back with you on the file comparison.

 

Knight.

[LIGHTNING UK!]

Ok so 2 sectors are being lost somewhere.

 

If that's the size your drive is reporting for the disc then I guess that's why the md5 doesn't match - the last 2 sectors aren't part of the calculation.

 

Copy + paste the disc info text from the panel on the right.

[Knightofoldcode]

Copy + paste the disc info text from the panel on the right.

 

 

Here is the bad burned disc that was successfully verified:

 

SONY DVD RW DW-D22A BYS2 (USB)
Current Profile: CD-R

Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 329,184
Size: 674,168,832 bytes
Time: 73:11:09 (MM:SS:FF)

TOC Information:
Session 1... (LBA: 0 - 329184)
-> Track 01  (Mode 1, LBA: 0 - 329183)
-> LeadOut  (LBA: 329184)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, TS: 329182, LRA: 329181)

ATIP Information:
Start Time of LeadIn (MID): 97m26s66f
Last Possible Start Time of LeadOut: 79m59s71f

 

 

And here it is from a successfully burned, and correctly burned copy of the same correct ISO:

 

SONY DVD RW DW-D22A BYS2 (USB)
Current Profile: CD-R

Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 329,184
Size: 674,168,832 bytes
Time: 73:11:09 (MM:SS:FF)

TOC Information:
Session 1... (LBA: 0 - 329184)
-> Track 01  (Mode 1, LBA: 0 - 329183)
-> LeadOut  (LBA: 329184)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, TS: 329182, LRA: 329181)

ATIP Information:
Start Time of LeadIn (MID): 97m26s66f
Last Possible Start Time of LeadOut: 79m59s71f

 

They are identical. I got the sectors that you requested above by copying it from the left side after loading the respective ISO's.

 

 

Here is the bad disc from another drive, Internal ATA.

 

Optiarc DVD RW AD-7170S 1.82 (ATA)
Current Profile: CD-R

Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 329,184
Size: 674,168,832 bytes
Time: 73:11:09 (MM:SS:FF)

TOC Information:
Session 1... (LBA: 0 - 329184)
-> Track 01  (Mode 1, LBA: 0 - 329183)
-> LeadOut  (LBA: 329184)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, TS: 329182, LRA: 0)

ATIP Information:
Start Time of LeadIn (MID): 97m26s66f
Last Possible Start Time of LeadOut: 79m59s71f

 

 

And the good disc from the Internal SATA drive:

 

 

Optiarc DVD RW AD-7170S 1.82 (ATA)
Current Profile: CD-R

Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 329,184
Size: 674,168,832 bytes
Time: 73:11:09 (MM:SS:FF)

TOC Information:
Session 1... (LBA: 0 - 329184)
-> Track 01  (Mode 1, LBA: 0 - 329183)
-> LeadOut  (LBA: 329184)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, TS: 329182, LRA: 0)

ATIP Information:
Start Time of LeadIn (MID): 97m26s66f
Last Possible Start Time of LeadOut: 79m59s71f

 

The two from the different drive are identical, but from the USB, and the SATA they are different.

 

Yes, I'm positive I'm putting the correct CD's in, the data is identical, I promise.

 

Knight.

[Knightofoldcode]

You could just use the 'comp' command line tool.

 

 

Comp won't work because the file sizes are different (I think), unless there's a command line parameter to tell it to ignore different file sizes.

 

 

Knight.

[LIGHTNING UK!]

Where did the image with 329,182 sectors come from, you just using 'Read' mode? If so, does Read mode produce the same size image from all of your drives?

 

Am I right in thinking that verifying as part of a burn returns correct md5 for both but verifying standalone returns a different one for the drive/device?

[Knightofoldcode]

Where did the image with 329,182 sectors come from, you just using 'Read' mode? If so, does Read mode produce the same size image from all of your drives?

 

Part A ) It came from a 'Read' mode from ImgBurn, using the 'SONY DVD RW DW-D22A BYS2 (USB)' Drive, this is also the drive that burned the bad disc.

Part B ) I haven't attempted to 'Read' this bad disc from a different drive because previously I attempted to 'Verify' this bad disc from a different drive, at that time ImgBurn told me it couldn't read certain sectors, I think, but whatever it did say, it failed to verify part way through the verification, and did not complete.

 

Am I right in thinking that verifying as part of a burn returns correct md5 for both but verifying standalone returns a different one for the drive/device?

 

No, this is the primary issue and reason for bringing this up. When I burn anything with ImgBurn I always tell it to 'Verify' by checking off the box while it's burning, of course it stays checked off. After the burn, (using: SONY DVD RW DW-D22A BYS2 (USB)) it cycled the drive tray, then verified the disc. It verified the disc without any problems reported, and said everything was fine. However, I just happened to notice that the MD5Sums were not consistent from Image to Device. So I then attempted to 'Verify' from the original ISO and the Disc, using a different drive. Both different drives failed verification, however when I then verified with the same drive that burned this bad disc, it said it verified successfully, but again, the MD5sums did not match.

 

 

I'm not concerned that it failed. I'm concerned that ImgBurn didn't notice that it failed, based on MD5sums.

 

Knight.

Edited January 24, 2009 by Knightofoldcode

[Knightofoldcode]

On my original post, I said I initially burned the disc with my Internal SATA drive, that was incorrect, it was burned with an external USB based drive (SONY DVD RW DW-D22A BYS2 (USB)), hopefully that hasn't confused anyone.

 

 

Knight.

[LIGHTNING UK!]

ImgBurn doesn't look at or use the MD5 calculations at all, they're purely cosmetic... hell I even turned off their calculation (by default) in newer versions.

 

I think the cause of the problem lies with this...

 

Optiarc DVD RW AD-7170S 1.82 (ATA)

Current Profile: CD-R

 

Disc Information:

Status: Complete

Erasable: No

Sessions: 1

Sectors: 329,184

Size: 674,168,832 bytes

Time: 73:11:09 (MM:SS:FF)

 

TOC Information:

Session 1... (LBA: 0 - 329184)

-> Track 01 (Mode 1, LBA: 0 - 329183)

-> LeadOut (LBA: 329184)

 

Track Information:

Session 1...

-> Track 01 (LTSA: 0, TS: 329182, LRA: 0)

 

ATIP Information:

Start Time of LeadIn (MID): 97m26s66f

Last Possible Start Time of LeadOut: 79m59s71f

 

That is to say, the track (according to the TOC) spans the LBA range 0... 329183 = 329184 sectors in total.

Yet upon asking the drive about the track (the 'Track Information' bit), it says the 'Track Size' is 329182 sectors.

 

So it's misreporting the size by 2 sectors.

 

I bet if you took 4096 bytes off the end of the proper ISO it would have the same MD5 as that reported by the 'Device'.

Likewise if you added 4096 bytes to the end of the broken ISO you'd then see (via 'Comp') that the differences were in those final 2 sectors.

 

I'm currently looking to why the difference in size wasn't flagged up somehow but it's hard when I can't find a disc / drive that will show the same issue! I'll keep you posted.

 

EDIT: Can you please take your problem CD and try to read/view the 2 sectors it's missing off the end using the builtin sector viewer.

 

i.e. try and read sector 329182 and 329183

 

Does it do that ok?

 

If you could then attempt to read (or verify... perhaps both!) the cd again, but this time press F8 before you click the 'go' button.

 

When that's done, save the contents of the log window to a file and upload it (rather than pasting it as plain text in your post).

[Knightofoldcode]

I'm currently looking to why the difference in size wasn't flagged up somehow but it's hard when I can't find a disc / drive that will show the same issue! I'll keep you posted.

I totally understand....anything I can do to help.... I can't even reproduce this error, actually. With a different CD, that is.

 

EDIT: Can you please take your problem CD and try to read/view the 2 sectors it's missing off the end using the builtin sector viewer.

 

i.e. try and read sector 329182 and 329183

 

Does it do that ok?

 

Yes, it does it without errors, however it appears to all be empty.

 

If you could then attempt to read (or verify... perhaps both!) the cd again, but this time press F8 before you click the 'go' button.

 

When that's done, save the contents of the log window to a file and upload it (rather than pasting it as plain text in your post).

 

 

Done, see attached.

 

 

Knight.

ImgBurn___Read.log

ImgBurn___Verify.log

[LIGHTNING UK!]

Ok, I see the problem now.

 

When ImgBurn scans the tracks it checks the end of them to see if they're readable.

 

Depending on how a disc is burnt (SAO or TAO), you can end up with unreadable sectors at the end that aren't really part of the track but are referenced in the TOC anyway.

 

This little check is being initiated due to your drive reporting that 'off by 2' value for the track size.

 

Here we see ImgBurn trying to read the sectors that aren't part of the track according to the track info but are according to the TOC... (i.e. 329182 and 329183 as mentioned before)

 

I 21:50:10 [0:0:0] SONY DVD RW DW-D22A BYS2 (E:) (USB)

I 21:50:10 CDB: BE 00 00 05 05 DE 00 00 01 F8 00 00

I 21:50:10 CDB Interpretation: Read CD - Sector: 329182

E 21:50:17 SENSE: 70 00 03 00 00 00 00 0A 00 00 00 00 11 05 00 00 00 00

E 21:50:17 SENSE Interpretation: L-EC Uncorrectable Error

 

As you can see, the drive is unable to read sector 329182.

 

ImgBurn then classes this sector (and any after this point but within the same track) as junk that it shouldn't read because they're probably not real ones.

 

Internally I just call them 'EndGap' sectors and once the real data sectors have been read, ImgBurn creates empty sectors for all the EndGap ones.

 

So it's reading up to sector 329181 from the disc and then dummy filling the remaining 2 with zeroes.

 

Currently, these EndGap sectors are NOT part of the MD5 calculation - that explains why the MD5 doesn't match I guess - assuming of course that the last 2 sectors in your image file really are just all Zeroes.

 

I'm going to assume that they are all zeroes (can't rely on what the drive reported when you said you could read the sector and yet the log shows the drive can't) and that's why the byte level verification passes.

 

So the moral of the story is... trust the byte level stuff more than the MD5 value

 

I'm going to add some more debug logging in now so it'll make these types of problems easier to justify.

[Knightofoldcode]

So are you saying that the CD is still good?

 

 

 

Because if I try to verify/read on any other drive, it fails.

 

 

EDIT: Also, when I try to reburn on same drive, same ISO, it creates a proper cd with matching MD5sums. So this was just a weird fluke.

 

Knight.

Edited January 26, 2009 by Knightofoldcode

[LIGHTNING UK!]

No, the read errors on the disc when reading with other drives proves it's not a decent burn. The verify only shows that the drive you verify in can read it at that moment in time.

 

See if you can get hold of some CD's using Taiyo Yuden dye. In my experience they're far better than anything else.

 

I stopped using Verbatim (unless they're TY ones!) a long time ago because of problems like this - i.e. them not reading back very well.

 

I've done a lot of tweaking since starting to deal with this thread so at least something good has come out of it even if at the end of the day you just end up binning that disc!

[Knightofoldcode]

No, the read errors on the disc when reading with other drives proves it's not a decent burn. The verify only shows that the drive you verify in can read it at that moment in time.

 

See if you can get hold of some CD's using Taiyo Yuden dye. In my experience they're far better than anything else.

 

I stopped using Verbatim (unless they're TY ones!) a long time ago because of problems like this - i.e. them not reading back very well.

 

I've done a lot of tweaking since starting to deal with this thread so at least something good has come out of it even if at the end of the day you just end up binning that disc!

 

Not at all, I'm not upset in anyway that the disc didn't read back properly, as you've said it's helped out with you, and that's well worth the bad disc, or even the entire spindle. I'm just trying to understand. As far as I see it, ImgBurn is still having an issue because it's not using MD5sum to verify the disc. Obviously in some cases a MD5Sum can be superior verification then a byte by byte, since in this particular case, the MD5sum is the only thing that caught the error, and of course that was by me noticing it, since ImgBurn isn't comparing them itself, it's just presenting them, and making the user check them.

 

Also when you state, "The verify only shows that the drive you verify in can read it at that moment in time.", this to me infers that you think this has occcured only once. I can make ImgBurn verify the CD many many times, with this drive, every time it will say that it was successful, yet the md5sums don't match. I didn't know if you understood that portion of my posts, if you did, that's fine, no harm.

 

Don't think I'm upset with the disc/drive, or even your responses and help. I'm glad I have been of help, and I'll look into the Taiyo Yuden cd's, I just love the ability to buy locally.

 

btw, this is a Memorex CD.

 

Knight.

Edited January 26, 2009 by Knightofoldcode

[LIGHTNING UK!]

What I meant is that a disc may verify one day and not the next (or a year down the line)... I wasn't specifically talking about your discs

 

Ah so it was a Memorex using the CMC dye! I just Googled the disc's MID (97m26s66f) and it mentioned Verbatim several times so I guessed it would be one of those.

 

There are so many variables when reading discs that it's really hard to get it right for every single one. To make it flag up an error on one sort of disc could mean it then errors out (without good reason) on another. Yours was an odd issue in that the drive didn't seem to be returning the correct info for track sizes and 'problem' discs are even harder to deal with!

 

I will do what I can to catch the problem but I don't want to break something else in the process.

[Knightofoldcode]

I will do what I can to catch the problem but I don't want to break something else in the process.

 

 

Sounds good, and I totally understand that flagging an error on a good disc would be bad.

 

Is there anyway you could add a feature for me (that is disabled by default), that would compare the md5sums and flag a error if they don't sync? Please?

 

 

Knight.

[LIGHTNING UK!]

Yup, I can do that

 

EDIT: Done.

[Knightofoldcode]

Yup, I can do that

 

EDIT: Done.

 

Sweet......

 

 

Thank you!

 

 

Knight.