Gringo Posted October 18, 2007 Share Posted October 18, 2007 (edited) 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 October 18, 2007 by Gringo Link to comment Share on other sites More sharing options...
LIGHTNING UK! Posted October 18, 2007 Share Posted October 18, 2007 Because it does a byte for byte compare. The MD5 is just cosmetic. Link to comment Share on other sites More sharing options...
batagy Posted October 22, 2007 Share Posted October 22, 2007 (edited) 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 October 22, 2007 by batagy Link to comment Share on other sites More sharing options...
LIGHTNING UK! Posted October 22, 2007 Share Posted October 22, 2007 Yes, Image MD5 is of the image file. Device MD5 is of the disc. Link to comment Share on other sites More sharing options...
batagy Posted October 22, 2007 Share Posted October 22, 2007 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? Link to comment Share on other sites More sharing options...
LIGHTNING UK! Posted October 22, 2007 Share Posted October 22, 2007 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. Link to comment Share on other sites More sharing options...
batagy Posted October 22, 2007 Share Posted October 22, 2007 Thank you much LUK, now everything is clear! This is one of the best program ever made! Link to comment Share on other sites More sharing options...
blutach Posted October 22, 2007 Share Posted October 22, 2007 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 Link to comment Share on other sites More sharing options...
batagy Posted October 22, 2007 Share Posted October 22, 2007 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. Link to comment Share on other sites More sharing options...
Gringo Posted October 23, 2007 Author Share Posted October 23, 2007 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 Link to comment Share on other sites More sharing options...
Recommended Posts