Verify against file?

[Darkfalz]

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?

[dirio49]

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 March 18, 2006 by dirio49

[Darkfalz]

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 March 18, 2006 by Darkfalz

[Darkfalz]

Care to comment Lightning UK?

[LIGHTNING UK!]

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!

[Darkfalz]

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.

[dirio49]

you can always disable compare to file. and It will just read the disk and make sure it is readable.

Edited March 28, 2006 by dirio49

[dirio49]

Double post.

sorry.

Edited March 28, 2006 by dirio49

[LIGHTNING UK!]

Sorry but not knowing where an errors occurs is a big 'no no' for me I'm afraid. This will not be implemented.

[Darkfalz]

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?

[Relentence]

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.

[LIGHTNING UK!]

You can do this yourself now anyway. The md5 of the data read from the disc is displayed in the log.

 

Your eyes can compare the two