Jump to content

Verify against file?


Darkfalz

Recommended Posts

Verify against file verifies it against the file you burned

 

What does normal verify do? Just try to see if the disc is readable?

 

Wouldn't the best solution to be calculate an MD5 of the ISO as you read/burn it, and then calculate it again reading back burned disc and compare?

 

Tell me I'm stupid if this is what it already does - but if it's the case, why would you bother verifying it against the file? To see if perhaps some reading of the source file could have been corrupted?

Link to comment
Share on other sites

What does normal verify do? Just try to see if the disc is readable?

Depends. By default it compares against the file.

 

Wouldn't the best solution to be calculate an MD5 of the ISO as you read/burn it, and then calculate it again reading back burned disc and compare?

 

Isn't that the same as reading the file?

Edited by dirio49
Link to comment
Share on other sites

Isn't that the same as reading the file?

 

No, because it doesn't require a second pass through the image file on verify. It already read it once while burning, it shouldn't have to read it again while verifying. Once you've burned it, it's nice if you can free up all hard disk activity while verifying (like you can begin creating the next ISO you want to burn).

Edited by Darkfalz
Link to comment
Share on other sites

  • 2 weeks later...

It ALMOST sounds like a good idea (see below), it's just not the 'norm' so far as burning apps go.

 

I personally never do anything with MD5 so it's not something that I'd have ever thought about.

 

Just one issue with it... isn't it very limiting in that you need to read the entire file to find a problem? And then once you know the MD5 doesn't match, you need to read the disc/file again to actually find out where the problem lies.

Forgive me if I've missed something, like I said, I don't do MD5!

Link to comment
Share on other sites

You need to read the file anyway as you burn it. To calculate a CRC32 or MD5 at the same time is trivial and will barely consume any CPU.

 

Of course, a bad burn will result in a wrong CRC32/MD5 on verify, which will tell you there was an error somewhere but not where it is.

 

That being said, I've never had a bad burn where I could actually read the disc but the data was bad. So it would be the same as comparing to file, just without needing to read the file again on verify.

 

True, you wouldn't know which sectors are mismatched, but the point of verify isn't really to catch errors (a rare occurance) but to give the warm and fuzzy feeling that your burn was successful. What advantage is knowing where the burn went wrong, really? Unless it's a persistant problem. I don't know who would keep a only slighty corrupt burn.

Link to comment
Share on other sites

I don't suggest it as an alternative to "Verify against file", I suggest it as an alternative to the cheap "just see if it can be read" verify. It would take the same amount of time and reading, but it would also verify the data was all correct.

 

Where's the downside? :|

Link to comment
Share on other sites

  • 6 months later...
isn't it very limiting in that you need to read the entire file to find a problem?

 

I think the idea is that when you burn the ISO, you create a list of MD5 values for each file (not just the ISO file itself). Then during verify, you compute the MD5 for each file and compare. Unless there is one big file on the CD/DVD, that gives the user a pretty good idea of where the error is.

 

But as Darkfalz says, the idea of MD5 verification isn't meant to replace the "verify against file" verification method, but it is a great alternative to the normal method.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.