Clarification of 1.2.0.0 verify behavior

[fordman]

I saw this in the release notes:

 

Added: Ability to tell Write mode to tell Verify mode to not compare against the file - so it behaves more like 1.0.0.0 where it just checked the sectors could be read.

How was 1.1.0.0 handling verification? I think I started using ImgBurn at 1.1.0.0, so I didn't experience the 1.0.0.0 behavior. I had assumed that ImgBurn was verifying each byte of the written disc to the source image in a sector-by-sector methodology, which would therefore also ensure that each file matched the source exactly.

 

Did DVDD only verify that sectors could be read? When pressed for time, I was in the habit of sometimes skipping the follow-up file mode verification that I normally do by creating a .SFV file (using QuickSFV) of the written disc and comparing it to a .SFV file made from the mounted image file. I do this because I have encountered instances where the written data CRC did not match the source, despite the fact that the sectors could be read fine.

 

Also, when you state

not compare against the file

are you referring to the image file, or the individual files withing the image?

 

Thanks - just curious about what I need to set to ensure I get full byte-for-byte error checking.

 

fordman

Edited February 23, 2006 by fordman

[Shamus_McFartfinger]

ImgBurn (and DVDD) originally checked read quality from the freshly burned media itself. If the media was crap (like CMC Mags or whatever), the verification process would usually fail. Neither checked (or compared) files or ISOs against the source. Newer versions of ImgBurn compared the source file (the ISO) to the destination when verifying, not the files within the ISO. Sleep deprivation may be playing havoc with my answer so don?t quote me on it.

[LIGHTNING UK!]

You're spot on shamus

 

ImgBurn 1.0.0.0 and all version of DVD Decrypter ONLY checked the physical disc for read error (by reading every sector).

 

ImgBurn 1.1.0.0+ compares what's read from the media against the image file itself.

 

So in order to get a proper byte by byte verify, you just need to leave the settings on their default values. i.e. 'Verify against image file' should be ticked.

 

are you referring to the image file, or the individual files withing the image?

 

You're burning an ISO file, so that's what it's compared against. I do not deal with things on an 'individual file within image' level.

[Shamus_McFartfinger]

You're spot on shamus

 

<phew> Thank fook for that.

[fordman]

You're spot on shamus

 

ImgBurn 1.0.0.0 and all version of DVD Decrypter ONLY checked the physical disc for read error (by reading every sector).

 

ImgBurn 1.1.0.0+ compares what's read from the media against the image file itself.

 

So in order to get a proper byte by byte verify, you just need to leave the settings on their default values. i.e. 'Verify against image file' should be ticked.

 

Thanks to both you and Shamus! I'm a bit of neurotic when it comes to data verification before I erase my source, so it's good to know that ImgBurn is doing a byte for byte verification as default. When my old Plextor PX-716A drive started to fail, I sometimes found that DVD Decrypter would verify the disc (dual layer Verbatim MKM001) and said it was fine, but when I read it back with QuickSFV (or by copying by Windows Explorer), it would freeze on a particular file, complaining that the file could not be read, and I had to let Windows XP close quicksfv or windows explorer down. I took the resulting disc to other computers, other drives and standalone DVD players and verified that there was indeed a problem (usually in the middle of a VOB file located on the second layer) that would prevent it from being read or played correctly. Since DVDD verified the disc and had no read errors, I began to suspect that validity of that information, and that's why I really started to do my manual file verifications. Eventually it was happening on every Verbatim DL disc I burned, and I replaced the drive under warranty. When it got to this point, even DVDD would error out with a read error.

 

In general, I think a byte for byte verification (whether in sector for file mode) is the only sure method. I've had burned discs (even single layer) that read back fine with Quick SFV or by copying back to my hard drive, but the CRCs didn't match the original files. When looking at the surface of the disc, I could observe that there might be a large "unburned" area where a large speck of dust or a defect in the polycarbonate protective layer might have been. Apparently the spot was too large for the error correction to correctly rebuild the data on reading, but it read just fine. For this reason, I also inspect blank discs and set aside ones with obvious physical defects and also use an air duster to blow dust from the surface and also from the drive tray before every burn...

 

You're burning an ISO file, so that's what it's compared against. I do not deal with things on an 'individual file within image' level.

 

Unless, of course, you're parsing the file system looking for a good layer break point and subsequently modifying the IFO and BUP accordingly. Since you do have file system parsing built in, I thought it possible that file by file verification was being done, though I expected it was sector by sector so that the non-user data areas could be checked also.

 

Thanks again,

fordman

Edited February 23, 2006 by fordman

[LIGHTNING UK!]

Indeed, I do have FS/IFO parsing I guess... but it's much easier to treat the image as a whole rather than something made up of lots of little files!

 

And as you said, doing it sector by sector, I can check non file/user data too.

[fordman]

Indeed, I do have FS/IFO parsing I guess... but it's much easier to treat the image as a whole rather than something made up of lots of little files!

 

And as you said, doing it sector by sector, I can check non file/user data too.

 

Your programming is quite brilliant! I must admit I was amazed that you were able to build the modification of files within the ISO image into your program, and so seamlessly and mostly automatically at that.

 

Thanks again for sharing your great utility....