Jump to content

Recommended Posts

Posted (edited)

Hi, I've seen a number of miscompares using Verify, and most of the time the burns are of video DVDs that are backups, so that on playback whatever errors might be on the disc don't show. But today again after burning one disc and getting one "miscompare", I checked all the files using the binary mode of WinMerge and it showed them all to be identical. Maybe no one else uses WinMerge in Binary mode as I do, or maybe there's an alternate/better file comparator someone might recommend, but I wonder why ImgBurn might throw an error yet the files appear identical?

 

; //****************************************\\

; ImgBurn Version 2.4.1.0 - Log

; Saturday, 26 April 2008, 17:32:51

; \\****************************************//

;

;

I 17:19:44 ImgBurn Version 2.4.1.0 started!

I 17:19:44 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2)

I 17:19:44 Total Physical Memory: 1,048,044 KB - Available: 705,912 KB

I 17:19:45 Initialising SPTI...

I 17:19:45 Searching for SCSI / ATAPI devices...

I 17:19:45 Found 1 DVD-ROM, 1 DVD-RW, 1 DVD

Edited by laserfan
Posted
W 17:29:45 Miscompare at LBA: 879596, Offset: 812, File: \VIDEO_TS\VTS_01_2.VOB

W 17:29:45 Device: 0x18

W 17:29:45 Image File: 0x98

Try to find out exactly what this is via the sector viewer, for example. If it really is an 0x18, then ImgBurn is reading it OK. If it's actually 0x98, then you might have a reading issue with the drive emerging (or a memory issue).

 

The fact that it is exactly 1 bit different (bit 3) is what might give cause for LUK to suggest memory issues.

 

Regards

Posted (edited)
W 17:29:45 Miscompare at LBA: 879596, Offset: 812, File: \VIDEO_TS\VTS_01_2.VOB

W 17:29:45 Device: 0x18

W 17:29:45 Image File: 0x98

Try to find out exactly what this is via the sector viewer, for example. If it really is an 0x18, then ImgBurn is reading it OK. If it's actually 0x98, then you might have a reading issue with the drive emerging (or a memory issue).

Thanks for your reply; I'm having trouble understanding this though. :blush:

 

Assuming the "Offset" value in the error log is in Decimal; when I look at the burned disc using any of my drives using Sector Viewer, at LBA 879596, offset x32C (812) I note that it is 18. But according to the log, the "Image File" (actually it's not from an image, I just burned the files off the hdd) suggests the original was 0x98, that what's on the disc is incorrect i.e. that ImgBurn burned it wrong??? Is there a way this specific location/value can be ID'ed in the original file on the hard disk, or even on the original DVD, from the LBA/Offset values? I suppose I can try to look for a pattern match in the VTS_01_2.VOB file...

 

Or are you saying simply that since WinMerge said "file on DVD+R = file on hard disk drive" then the log is saying ImgBurn read a different value from the hdd due to some memory error (or hdd read error or even virtual memory/hdd glitch somewhere I suppose).

 

I have been experiencing "verify" errors with all 3 of my drives (Pio 103 and 109, brand-new LG GCC-H20L) so I am indeed beginning to suspect a hardware problem, though Memtest+ certainly gives my RAM a clean bill of health. Maybe I have a glitch on a hard drive, but this seems like a long shot given the different hard drives I burn from... :(

Edited by laserfan
Posted

To make life easier, make an image, mount it in as a virtual drive and then do binary comparison between the hdd files and the virtual drives one (do it 2 or 3 times to be sure!)

 

Now burn your image and then check again.

 

How many passes did you let memtest run through?

Posted
Assuming the "Offset" value in the error log is in Decimal; when I look at the burned disc using any of my drives using Sector Viewer, at LBA 879596, offset x32C (812) I note that it is 18.

So ImgBurn read the disc OK and reported it OK. The question then still resides with your HDD or your memory.

 

Regards

Posted

Please bear with me--this is very curious:

 

Yesterday I used ImgBurn to make an .iso of a fileset and then mounted that .iso with VirtualCloneDrive and compared files with WinMerge. Three VOB files failed to compare (about 20 files total in set). Then I tried another tool Folder2Iso and made another .iso and mounted it. Got one VOB file that mis-compared with WinMerge. Then I did this fileset again with ImgBurn, mounted it, and got all files to compare OK. But just one good ISO out of three, so something is definitely wrong w/my setup (in no case did I even burn a disc to DVD+R) but I'm not convinced of a hardware problem (yet), because...

 

A couple days ago I'd run Memtest+ (from disc) overnight and then yesterday ran HCI Memtest into this a.m. and get Zero errors. None. Clean bill of health for the CPU and RAM. Using 3 hdd here, one for System & one for the fileset and a third for saving the ISOs to--yesterday I chkdsk-ed and defragged the heck out of them and they all seem fine.

 

But it occurred to me that it's always a VOB file that miscompares, a 1Gb file, in every case. After googling a bit yesterday I came across some info that some people have memory problems with gaming, and in particular 1Gb machines tend to be a problem. I have a 1Gb RAM machine. So I'm going to tinker w/PagedPoolSize in the Registry and also look to acquire some more memory, maybe boost mine PC to 3Gb. Anyone here share my hunch? Possible WindowsXP issue w/1Gb RAM and 1Gb files I'm comparing???

 

One (more, other) question: If ImgBurn is set to assure 32K padding, does this mean that if padding is applied, that the READ file will miscompare with the BURNED/ISO'ed file, or does Verify know to ignore this somehow?

 

Thanks for bearing with me; it appears we are out of the realm of possible ImgBurn issues, but if I have a setup problem then maybe others here do as well... :(

Posted

32k padding is in the file system (between files), not the file itself - so it's size doesn't change.

 

What will/may change though is the offset pointers in the IFO files.

 

So you won't always be able to do a file compare outside of the program between the raw files on your hdd and the files on the disc - hence the reason for making an ISO and comparing to the files within that (once mounted) to the ones on the disc.

 

Verify does not compare file against file, it compares sector against sector. If one doesn't match then it performs a lookup to see what's at the specific LBA and displays the file name if it finds anything.

Posted
Verify does not compare file against file, it compares sector against sector.
So if I understand this correctly, even when ImgBurn is burning from hdd directories/files, and not an .iso image, it first Creates For Itself an iso image (is this what "Building Image Tree" and "Preparing Image" are doing? in the logs), burns it to disc, and then verifies the just-burned disk sector-for-sector against the (temporary) image it's created for itself?

 

If that's correct, where is the temporary image created, on the ImgBurn drive (in my case C:\Program Files\ImgBurn)? Or perhaps "ImgBurn Images" or "Queue" from the File Locations Setting?

 

Many thanks for your detailed replies, and your indulgence. I've just run an exhaustive check of drives to match my RAM testing and all looks fine. Next step is to try more RAM I guess, assuming a possible WinXP issue, then finally a complete re-install (yuk!) of Windows...

Posted

The build function/code always outputs an image but depending on your choice of 'output', it's either streamed to the write/verify buffer or it's dumped to a file.

 

There is no 'temp' file.

 

The 'Building Image Tree' stage is where it's scanning the folders added to the 'source' window and adding all the files to its internal structure.

The 'Preparing Image' bit is where it makes sense of all those files and calculates their order, physical location within the image and other stuff to do with the file systems and their layout.

Posted

Think of the verifying as rebuilding the image and reading, not writing.

 

In your case, what I'd do now is make ISOs before building every time for the time being (ie build to HDD). The switch to write mode and write. Wait till you get you next miscompare. You'll then have the ISO to re-compare it against (on another PC or DVD drive for example).

 

Regards

Posted
...what I'd do now is make ISOs before building every time...

Thanks blu, I was doing just that as you were posting. First, I made an .ISO from a video titleset, mounted that ISO using VirtualCloneDrive, and did a Verify, which came-out perfect:

 

I 18:46:28 ImgBurn Version 2.4.1.0 started!

I 18:46:28 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2)

I 18:46:28 Total Physical Memory: 1,048,044 KB - Available: 693,616 KB

I 18:46:28 Initialising SPTI...

I 18:46:28 Searching for SCSI / ATAPI devices...

I 18:46:28 Found 1 DVD-ROM, 1 DVD-RW, 1 DVD

Posted

Have you done a scan on the disc? That might reveal something.

 

Regards

Posted
Have you done a scan on the disc? That might reveal something.

Do you mean from How to check if your burn is a good one? Although last updated in 2005, is CDSpeed still preferred or is DVDInfoPro (I don't have) better?

 

I notice also your Burn guide suggests 4x burning; I've been using 8x with 16x Verbatim media. Although 4x isn't listed as a supported speed for the Verbatim, is that speed still OK to use?

 

Thanks for your patience. I'm off to run the CD Speed tests.

Posted

Ner0 CDSpeed is now at 4.7.7.something. Download it from www.cdspeed2000.com

 

Running 8x on those discs should be fine - at least on a stable system. Something's NQR on yours though, obviously.

 

Regards

Posted (edited)
Ner0 CDSpeed is now at 4.7.7.something.... Something's NQR on yours though, obviously.

Actually there's a new utility DiscSpeed 4.11.2.0 just out. My scans look good...nothing there that I can see.

 

Took me a second or two to decipher NQR in your post--got it! Indeed!

 

Grasping at BIOS straws now, like 32bit transfer mode & such. I will come back if I ever get this fixed... :blush:

Edited by laserfan
Posted

If you have 2 sticks of memory in computer take out 1 try verify, still the same take out the 1 stick and replace with the other, if still the same make sure you have memory set to SPD in bios and that any overclock of cpu is switched off and try again.

 

Check filters for anydvd dvd43 etc or anything else including maybe how winmerge interacts with your computer and disable delete them.

  • 1 month later...
Posted
If you have 2 sticks of memory in computer take out 1 try verify, still the same take out the 1 stick and replace with the other, if still the same make sure you have memory set to SPD in bios and that any overclock of cpu is switched off and try again.

 

Check filters...

After a month of fiddling with this computer literally day-and-night (I'm retired), which as Blutach said was clearly Not Quite Right, while I can't say "it's fixed" indeed it's working a lot better, though I just had, after 4 or 5 perfect burn/verify cycles in a row, another (solitary though) "miscompare". Among the things I've done:

 

1. Replaced my 1Gb of RAM with 2Gb

2. Replaced the hard drive that was my Startup/system drive

3. Turned-on OPC and have been using 2x w/ImgBurn despite that my discs are 16x

 

A lot of other things have been done, including switching from Cable Select to Master/Slave jumpering, but in the end I think there's a possibility of all of these things coming into a "perfect storm" to thwart my burn/verify efforts:

 

1. Too little RAM and too much use of the hdd-based Paging file for these huge files I'm burning (many >4Gb)

2. A flaky disk drive that might have been glitching-out when overheated; man this one's a bitch and I'm still wonderin' about it

3. A marginal 100disc cake of Verbatims? My storage location isn't "cool & dry" enough here in the hot, humid, sunny South?

 

Regardless, I now own & use a passel of PC integrity/torture testers, including not just MemTest86+ but also HCI Memtest, Prime95, TestIO, and Bart's Stuff Test. Highly recommended to anyone who wonders if their PCs are Perfect, or maybe Not Quite.

 

I'd still like to see an option w/ImgBurn to Not Stop on a miscompare, as I noted in another thread, but didn't want to leave this thread go unresolved so there you have it. I think I'm done...whew!!! Thanks to all who stopped-by... :innocent:

×
×
  • Create New...

Important Information

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