|
|
|
#1
8th April 2012, 16:45
|
|||
|
|||
Weird Quirk - Getting miscompares on verify, on ONE ISO, on ONE file
I'm pretty sure at this point that this isn't really an AnyDVD problem, but it might be interesting as a case study (bear with me it's kind of long). I've been working on it for several days now. I'm just not sure where to report this, but I feel like I want to say something somewhere. This almost seems like a computer science problem.
 Here's what happened: I picked up a $10 Blu-Ray - "Hills Have Eyes (1977)" on Amazon, and tried to back it up. (Which I now read is a crappy DVD upscale AND I've used several blanks but I am more interested in troubleshooting at this point... just wanted to get that out of the way...) I used ImgBurn 2.5.6.0 and 2.5.7.0, AnyDVD 7.0.2.4 and 7.0.2.6, and blank Verbatim BD-25's (source is single layer). When I first tried it, on verify, I got several miscompares. Most all were either one or two sectors with the same checksums. First thought... bad blank. So, I tried another blank from a different spindle. Same result, some miscompares in the same sectors, some in different sectors. Next... it could be a bad optical drive. Replaced the drive. It's a Sony BWU-100A IDE. (I have some spares.) SAME result. So, probably not the drive. Miscompares can be caused by RAM or CPU stability problems. So, I went to check that next. I ran a Memtest86 for an hour and CPU Stability for an hour. NO errors! So, probably not that. Next... I/O comms issue? I backed the disc up to a network attached storage drive (My Book World). I ALSO backed it up to a locally attached IDE hard disk. Still getting miscompares. At this point I am noticing that the miscompares are always happening on the same 14 gig file - 00006.m2ts - seemingly throughout the whole file. Most, but not all, of the miscompare checksums look the same! I next tried backing up, burning, and verifying a different title ("A Lonely Place to Die" Region A Blu-Ray). It worked fine, no miscompares! Next, I backed up Hills Have Eyes again to the MyBook, and verified the resulting ISO to the ORIGINAL *WITH* AnyDVD running. Miscompare still there. Still can't totally rule out bad error correction on a drive, or I/O Comm. So, this is what I did: I made an AnyDVD decrypted ISO of Hills Have Eyes to the MyBook (with whatever miscompares are probably on it). Then, I CLOSED AnyDVD, CLOSED ImgBurn, then used Windows Explorer to COPY the ISO from the MyBook to a shared directory on the desktop IDE drive. THAT should be the same file! Then, using a laptop, I mounted the ISO on the MyBook using Virtual Clone Drive, started ImgBurn, and did a VERIFY to the ISO on the shared directory on the IDE drive on the desktop. I got miscompares! And again, just in the one 14 gig 00006.m2ts file! This is straight Windows copy!! OK, so I tried this: I attached a SECOND MyBook World network attached storage drive to my LAN, then COPIED the ISO from the first MyBook drive to the second using the LAPTOP. Did the mount/verify as above, and got NO miscompares! Next, I tried doing the SAME thing... COPYING the ISO from the first MyBook drive to the second MyBook drive using the DESKTOP (where the problem appears to be). I got two miscompares! AGAIN, **ONLY** in 00006.m2ts. I tried it again, and this time got one miscompare in 00006.m2ts, but in a different sector. Finally, I tried it a third time, and I got no miscompares. SO... it seems to ONLY happen on the DESKTOP. And it happens when being completely off the local buses, but apparently, not as often when not.. but it STILL happens. But ONLY on the desktop, NOT on the laptop. So, what could it be? Drive, I/O comm, RAM, CPU, seem to be ruled out. So does AnyDVD or any software other than windows. Bad drive filter maybe? I checked the registry.. ALL standard filters for optical AND hard drives, nothing weird. But so far, this seems to affect ONLY the AnyDVD decrypted ISO of the Hills Have Eyes Blu-Ray, and ONLY in the 00006.m2ts file! I then decrypted to ISO and backed up another Blu-Ray ("A Serbian Film" Region A Blu-Ray)... and it was fine! I verified the copied disc to the ISO a second time... no miscompares. I put the other disc I successfully backed up earlier in and verified THAT a second time... no miscompares. Finally, I made an ISO backup of Hills Have Eyes, but DIDN'T use AnyDVD... I left it encrypted. THAT gives no miscompares! The ONLY hypothesis I have right now... the desktop has ECC RAM, the laptop doesn't. If bad error correction can cause this, and it's not the drive, then it very well could be the ECC RAM. But... this ECC RAM passes Memtest and the system seems to back up other Blu-Rays fine. I've backed up my entire collection of over 1,000 on this system, and since getting the miscompare, it seems it's ALWAYS the same file, ONLY on the decrypted ISO of Hills Have Eyes, and not on other discs (which I admit I've only tried three so far; the two I mentioned plus Hills Have Eyes encrypted). SO... could this actually be a fluke?? Could it possibly be, that JUST the right sequence of bytes in a file could trigger ECC RAM to correct a byte error that does not exist? Or could SOMETHING on Windows affect this? As part of troubleshooting, I did remove all AntiVirus before all the testing above. (I only had WebRoot SecureAnywhere.) This is a Windows XP SP3 system with the latest updates applied. (Both Desktop + Laptop.) Has ANYONE ever heard of ANYTHING like this happening? Am I the first to encounter this weirdness? I doubt any developers would want to spend serious time on this, unless of course they found it interesting. I have no problems uploading the ISO to SlySoft if they want to take a look... or they could just buy it from Amazon. This is the USA Blu-Ray disc of Hills Have Eyes. I've attached the following for anyone who might want to poke around (the logs are arranged in the sequence they were created): \ImgBurn Logs 01_ImgB_LP2D_Success1.txt This is a backup of "A Lonely Place to Die" Blu-Ray. It was made after several attempts to back up Hills Have Eyes and I got miscompares. It was successful. 02_ImgB_HHE_Burn_Fail1_Verify1.txt This is the typical result I get when trying to decrypt to ISO and back up Hills Have Eyes on the desktop using AnyDVD + ImgBurn. Four miscompares then I aborted. 03_ImbB_HHE_Any_Fail.txt This happened when making an ISO of Hills Have Eyes and verifying it to the original with AnyDVD running. I aborted after a miscompare. 04_ImgB_ASF_Burn_Success1.txt 05_ImgB_ASF_Burn_Success1.txt Two successful burns and verifies of "A Serbian Film" Blu-Ray using AnyDVD and ImgBurn. 06_ImgB_HHE_Burn_Fail1_Verify2.txt Another verify of Hills Have Eyes. Miscompares in some of the same sectors, plus some other ones as well. 07_ImgB_HHE_Burn_Fail1_Verify3_CDIO.txt Tried using Elby CDIO in ImgBurn for another Hills Have Eyes verify. Made no difference. 08_ImgB_HHE_Burn_Fail1_Verify4.txt Another miscompare verify of Hills Have Eyes. 09_ImgB_LP2D_Success2.txt A second verify of the ISO of "A Lonely Place to Die" Blu-Ray. Success, as before. 10_ImgB_HHE_Burn_Fail2_1xClean.txt Just to try it, I cleaned the Hills Have Eyes disc, and read, burned, and verified at 1x speed. This actually seems to have caused MORE miscompares. But, again, ONLY in 00006.m2ts. 11_ImgB_HHE_Copy_Fail2_Laptop_Verify5.txt This was where I copied the Hills Have Eyes ISO from the MyBook to the Desktop IDE via Windows, then mounted the MyBook ISO and verified to the Desktop IDE via a Laptop. Miscompares in 00006.m2ts. 12_ImgB_HHE_Copy_NAS2NAS_Fail1.txt 13_ImgB_HHE_Copy_NAS2NAS_Fail2.txt Here I copied the Hills Have Eyes ISO from the MyBook to a SECOND MyBook using the DESKTOP. First log has two miscompares, second has one miscompare. All in 00006.m2ts. Another attempt of this was successful (so far the only one from the desktop, but it's on an ISO **created** on the desktop, so it probably had the miscompare thing happening when it was created); log from this isn't attached. Also not attached is a successful verify of a NAS to NAS copy using the LAPTOP to do the copying. 14_ImgB_HHE_EncryptedBurn_Success.txt Here is a SUCCESSFUL copy, burn, and verify of Hills Have Eyes when AnyDVD is NOT used and the copy is ENCRYPTED. No miscompares. It seems some sequence of data in the decrypted 00006.m2ts is triggering something, perhaps ECC RAM??? \AnyDVD Logs AnyDVD_7.0.2.6_Info.zip AnyDVD_7.0.2.6_Info_Z_THE_HILLS_HAVE_EYES.zip Last edited by Pelvis Popcan; 9th April 2012 at 15:34. 
|
|
#2
8th April 2012, 19:49
|
|||
|
|||
|
What happens if you make a protected ISO and compare it against the original without AnyDVD running?
What happens if you decrypt that protected ISO multiple times? (Without remounting it or disabling AnyDVD or changing any AnyDVD settings between each rip.)
|
|
#3
8th April 2012, 20:02
|
||||||
|
||||||
|
Quote:
Quote:
From my logs on various attempts of the same ISO: Quote:
Quote:
Quote:
Quote:
|
|
#4
8th April 2012, 20:05
|
|||
|
|||
|
Well imgburn does notify you to DISABLE anydvd cause it can mess with verification
__________________
Project: Supernova OS: Vista Ultimate X64 ||MB: Asus P5Q-E || CPU: Intel Q9550 || CPU Cooler: Asus Triton 79 || RAM: 8GB Corsair XMS2 5-5-5-18 GPU: Asus GTX 680 DirectCU II OC 2GB|| Monitor: Asus VG278 || HDD: 2x Samsung Spinpoint F1 1TB Optical Drive 1: LG BH10LS30 || Optical Drive 2: LG BH08LS20 || Optical Drive 3: LG DVD-RAM GH20NS10 Home Theatre Setup: TV: Panasonic TX-P42S20 || Blu-ray Player: Panasonic DMP-BD85 || Sound: 5.1 Surround Logitech Z-5500 via fiber optic cable
|
|
#5
8th April 2012, 20:10
|
|||
|
|||
|
One thought I had was to disable ECC in BIOS settings, but when I do that, the system doesn't boot.
I guess the only thing that can be done to investigate further is to replace the RAM with Non ECC RAM and see if it has an effect. Not sure if it's worth it if it only affects this one disc. This is my infamous old desktop and has needed badly replaced for years now. It has always gotten the job done though when it comes to backing up. I've never experienced miscompares until now. I can't be 100% positive where the problem is... if there is a hardware or even software fault, I would expect to see this affect all discs and all files, not one file on one disc... but then again, I have seen faulty hardware before that causes predictible behavior. It's not common, but it can happen. I guess if I keep using it in the coming weeks/months we'll see if this happens on other discs.
|
|
#6
8th April 2012, 20:11
|
|||
|
|||
|
Quote:
|
|
#7
8th April 2012, 20:44
|
|||
|
|||
|
Another thing I should mention here... this was long and complicated enough already... one thing that occurred to me was that this COULD be a bug in ImgBurn. In other words... did the CRC's of the ISO files match, but ImgBurn still report miscompares? I did use Express Checksum Calculator throughout. (And it was a PAIN IN THE *SS). The checksums of the files didn't match when there were miscompares. The files really were different... it's not an ImgBurn bug. The bytes in the ISO file actually do change when copied via Windows on that desktop. (I even tried TeraCopy, that had no effect.)
 IN FACT... when Express Checksum Calculator is used on the Desktop on the decrypted Hills Have Eyes ISO, it can produce a DIFFERENT checksum each time because of this whole miscompare quirkiness!!
Last edited by Pelvis Popcan; 8th April 2012 at 20:53.
|
|
#8
9th April 2012, 15:30
|
|||
|
|||
|
Not sure why this was moved to third party products. ImgBurn isn't a factor... it happens on a straight Windows file copy... but ONLY on the ISO file that is DECRYPTED with AnyDVD. So, if ANY software is applicable to this, it would be AnyDVD.
Thanks a lot.
|
|
#9
9th April 2012, 20:13
|
|||
|
|||
|
Take ImgBurn and burning to media out of the equation.
A few further tests: 1. Use VCD to mount the protected ISO and turn AnyDVD on. Then use AnyDVD's build-in rip-to-image to create a decrypted ISO. Repeat to create another decrypted ISO. Use sha1sum.exe to calculate the checksum of both decrypted ISOs. Do they match? If so, what does ImgBurn's verification say? 2. Mount both decrypted ISOs using VCD. Use sha1sum.exe to calculate the checksum of 00006.m2ts on both volumes. Do they match? If not, do they match with AnyDVD disabled? If they match, what does ImgBurn's verification say? 3. Copy 00006.m2ts from the ISOs onto your NTFS partition. Use sha1sum.exe to calculate the checksum. Do they match? If not, do they match if you copy while AnyDVD is disabled? If they match, what does ImgBurn's verification say?
|
|
#10
9th April 2012, 20:46
|
|||
|
|||
|
While I haven't done those specific tests, I did pretty much take ImgBurn / burning out of the equation, as well as AnyDVD, once the ISO is decrypted.
I am confident that any program that reads the data of the unencrypted ISO on that desktop will exhibit that behavior. I believe the answer to these would be: 1) The checksums wouldn't match. ImgBurn would show as above on each one. 2) Same as 1, with AnyDVD disabled. 3) Again, same as 1, they wouldn't match, with AnyDVD disabled. I have since backed up two more Blu-Ray discs on the desktop, both dual layer: The Fighter (Region A) and Repulsion (Region A). No miscompares. Either it's at the motherboard level and it's ECC RAM being triggered somehow, or, it could be some piece of software or driver file that somehow gets triggered by something in the file stream. It's definitely not a hard disk drive filter. It would be interesting if someone with ECC RAM on their system could try this disc with AnyDVD + ImgBurn + Verify. I don't know if the implementation of ECC RAM would differ from motherboard to motherboard, or even from DIMM to DIMM. It's so bizarre. I've never seen anything like this! That's why I wanted to get more exposure. ANY ideas from ANYONE would be helpful.
|
 |
| Tags |
| imgburn, miscompare, verify |
| Thread Tools | |
| Display Modes | |
|
|
Linear Mode
