Jump to content

Verification in Build Mode


fordman

Recommended Posts

I built my first disc directly to the DVD writer and was expecting that it would do a file by file comparision during the verification phase. I was very surprised in the log ot see that it was instead doing a sector by sector comparison.

 

Is ImgBurn actually creating a "virtual drive" in memory without actually copying the files into such a drive to accomplish this?

 

Would a physical image built with the same settings (i.e. including a forced date for files and image creation) have the same MD5 value as that in the virtual drive?

Link to comment
Share on other sites

Build mode always works by creating a virtual image, be it during the build/write phase or the verify one.

 

Verify is re-reading the files and recreating the filesystem when it does its thing - incase that's what you were worried about? It's not simply checking the disc is readable (like how DVD Dec used to work).

 

In theory yes, if the files hadn't changed and you set all the dates etc the MD5 should be the same.

Link to comment
Share on other sites

Verify is re-reading the files and recreating the filesystem when it does its thing - incase that's what you were worried about? It's not simply checking the disc is readable (like how DVD Dec used to work).

 

I suppose I'm really not worried about anything. It was more a curiosity and admiration that you are able to map files to a virtual image on the fly without actually writing an image first to the hard drive, while simultaneously comparing it to the written disc!

 

In theory yes, if the files hadn't changed and you set all the dates etc the MD5 should be the same.

 

Then with this information, and the answer above, I now know that there is no reason to make an actual ISO image beforehand! The only exception might be where I would want to troubleshoot or otherwise verify the operation.

Edited by fordman
Link to comment
Share on other sites

Then with this information, and the answer above, I now know that there is no reason to make an actual ISO image beforehand! The only exception might be where I would want to troubleshoot or otherwise verify the operation.
You might also want to make an ISO when you are backing up many files over a fragmented drive. I have had occasions in write to device mode where the buffer empties and the burn waits for them to re-fill. This would, of course be avoided if you wrote via an ISO.

 

Regards

Link to comment
Share on other sites

:worthy: Lightning_UK! :worthy:

 

Agreed! All Hail Lightning_UK!

 

I've done 3 this way now and all looks great!

 

I had one with a JACKET_P directory and am wondering is it best to put that at the end of the structure, or keep it mixed, which is the default? What do other mastering programs do? It seems that RecordNow Deluxe puts the VIDEO_TS folder at the beginning, because even if I've dragged the AUDIO_TS and JACKET_P into the burn windows first, when I drag VIDEO_TS there afterward, it gets put at the top of the window...

Link to comment
Share on other sites

  • 4 weeks later...
In theory yes, if the files hadn't changed and you set all the dates etc the MD5 should be the same.

 

Ok, I've verified that an .ISO image ripped from a disc made directly from build mode does not match an ISO made from build mode.

 

You made an adjustment to the UDF recording time as referenced in the following thread:

 

http://forum.imgburn.com/index.php?showtopic=2037

 

and in this thread we discussed that as long as the files stayed the same and the date settings were the same the disc made directly in build mode should compare exactly to one made from an ISO file first made in build mode and then burned.

 

I set the "Volume Dates/Creation" and "Folder/File Dates - Use Custom Date & Time" options to the same date and time for the direct to disc build and the build to ISO.

 

I can verify that the DVDInfoPro UDF recording time is now shown the same for both, however there is a difference in sector 16 of the ISO file system (as viewed with the sector view in ISOBuster). At offset 032D of sector 16, the date string I used for volume creation is shown, but immediately following that the actual date I recorded to disc (or to ISO image) is shown. Therefore the two will never match.

 

I had assumed that this would be where you modified the UDF recording time, and only ever verified your adjustment in DVDInfoPro. I've been since building direct to disc, bypassing the ISO file altogether (a big time saver!) and just happened to be looking at sectors in ISOBuster when I noticed this. Now I'm realizing that the UDF recording time likely isn't stored in the ISO file system structure, but I cannot find a similar string in the UDF file system sectors. So, where is the UDF recording time stored, i.e. where did you make that adjustment?

 

Is it possible to also change the second date in the ISO file system? I've noticed that in pressed DVDs these either seem to match, or the second date is not there at all (all zeros).

 

Thanks,

fordman

Link to comment
Share on other sites

It's probably the creation (first date) and then modified (second date) that you're seeing in the ISO9660 filesystem. Both of which are configurable on that same 'Dates' tab.

 

Aaah, OK. So, I'll set 3 date fields and then the images should match. I was hesitant to change other fields since I wasn unsure of the implications behind the effective and expiration dates.

 

No fix needed then, I just wasn't using the options you already have built in.

 

Thanks for the pointer.

Link to comment
Share on other sites

Just to be clear...

 

The created and modified date fields use the current time/date if not specified.

 

The effective and expiration date fields are zeroed out if not specified.

 

You anticipated my next curiosity, but I wasn't going to bother to ask! I saw all the zeros in sector 16 after the created and modified dates, and wondered why the modified date wasn't also defaulted to zeros.

 

Thanks.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

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