Jump to content
Sign in to follow this  
Gringo

Speeding up Verify

Recommended Posts

I have an idea about speeding up the verify after burn:

 

on Verify you currently read from the disk building an MD5 and read the image building an MD5.

 

Why not build the MD5 on the image while burning it (while it's read anyway), so the verify has only to check the disk and is not delayed by I/O to the disk (or even worse: the network) reading the image again?

 

Gregor

Edited by Gringo

Share this post


Link to post
Share on other sites

Hi there LUK!

 

I also thought about this one.

 

When you burns an image, without verifying, at the end of process you got an MD5:

I 21:08:34 Closing Track...
I 21:08:36 Finalising Disc...
I 21:09:16 Image MD5: 23f3792ea3f8dcf87e7e918d12b2a45f
I 21:09:16 Operation Successfully Completed! - Duration: 00:15:04

 

Is this MD5 the checksum of the image on the disk, or the MD5 of the burned disc?

(I'm almost sure that is the MD5 of the image, because when you verify also, there's a "Device MD5", but this would be nice to be sure.)

 

If that MD5 in the above log would be the MD5 of the burned disc, and if you would know the image MD5 before, then indeed the verification process could be shorter, just compare the two MD5. I guess this is not possible, so probably we need to re-read the whole disc anyway if we want to verify? Am I right?

Edited by batagy

Share this post


Link to post
Share on other sites
Yes, Image MD5 is of the image file. Device MD5 is of the disc.

Yeah thanks for the verification!

So then we can't left out the verification process (reading back the disc) if we want to verify the burn.

 

 

Another question:

While I messing around with MD5 sums, I've noticed that in Build Mode, ImgBurn produces different MD5 when the output is the Device, compared when the output is an Image file. So everything is the same, content, settings etc, only difference is the output (Device or the Image file).

 

I got this when I burned to disc in Build mode:

I 20:28:30 Synchronising Cache...
I 20:28:31 Closing Track...
I 20:28:33 Finalising Disc...
I 20:29:13 Image MD5: ec3c212c87ca6fec345fdccaf5a68970
I 20:29:13 Operation Successfully Completed! - Duration: 00:15:04
I 20:29:13 Average Write Rate: 5 339 KB/s (3.9x) - Maximum Write Rate: 5 592 KB/s (4.0x)

 

I got this when I made an image file as output:

I 20:39:21 Destination File System: NTFS
I 20:39:21 File Splitting: Auto
I 20:39:21 Writing Image...
I 20:43:45 Image MD5: 23f3792ea3f8dcf87e7e918d12b2a45f
I 20:43:45 Operation Successfully Completed! - Duration: 00:04:23
I 20:43:45 Average Write Rate: 17 073 KB/s (12.3x) - Maximum Write Rate: 44 035 KB/s (31.8x)

 

Why is that different?

Share this post


Link to post
Share on other sites

Correct, you can't leave out the verification process. (Why would I have implemented it if you could?!)

 

Dates and times change within the file system structures, that's why the MD5's don't match.

Share this post


Link to post
Share on other sites

Thank you much LUK, now everything is clear! :w00t:

This is one of the best program ever made!

Share this post


Link to post
Share on other sites

To add to what LUK! has said.

 

If you burn a disk, then make an ISO and verify against the ISO, you'll find verify errors in the first few sectors. These are all time and date related (typically sectors 16, 32, 261 and 269). However, the sectors after the filesystem will (or at least should) show a good burn.

 

Regards

Share this post


Link to post
Share on other sites
To add to what LUK! has said.

 

If you burn a disk, then make an ISO and verify against the ISO, you'll find verify errors in the first few sectors. These are all time and date related (typically sectors 16, 32, 261 and 269). However, the sectors after the filesystem will (or at least should) show a good burn.

 

Regards

Exactly!

Thanks indeed for your verification!

 

I just tried it for myself, that I verified a builded burned disc against an ImgBurn generated ISO image, and indeed there were mismatch in the first area sectors, but the main was the same.

Great!

From now on, I will using a method, that I generate an ISO image with ImgBurn, then I put it twice to the queue, and burn it with two different drive. So I get two exactly same disc written on 2 media (for archiving purposes). Then I generate Par2 recovery checksum files for the image on the hard disk.

Why I say this? Because if I generate the ISO once, and burn it twice, the MD5 will be the same for both disc plus the ISO, because date and time won't change. (If I would burn both disc in build mode with device output, then date/time would be different). And the Par2 set later can be used the recover either of the two discs, since they are exactly the same.

 

Sorry for the lengthy off-topic.

BTW I just donated LUK, because I like ImgBurn much. :thumbup:

Share this post


Link to post
Share on other sites

Reason why i asked is that i use this very nice program to burn ISO images created from a backup cron job. The windows client has to fetch the images (a handfull a day) over the LAN (sadly not enough local disk space to cache them there) and while getting them the load on the network goes up (and the rest running there gets slow). So i hoped that i missed a switch somewhere because for all verify operations i have seen the ISO and disk MD5 were consistent. So should you get bored someday, looking for some feature to code then maybe remember this one ;)

 

Until then i guess i'll have to upgrade the LAN to GBit to stop the customer from complaining :(

 

Nevertheless, thanks for this nice free piece of software!

 

Gregor

Share this post


Link to post
Share on other sites
Sign in to follow this  

×

Important Information

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