Completed my 1st rip. Calculated SHA1 checksums for all files and exported to Excel. Running 2nd rip now and then will compare. I will post my table of results once complete.
5th Time lucky! Got a match on the main M2TS (MD5 - 14e31f62ae67377107a20005fb1e499d) - just checking the rest of the files. Can also post SHA1’s of all files if anyone is interested.
Did two rips back-to-back of Wonder Woman (US) and calculated the SHA1 for every file both times. I then ran a comparison of both sets of data and determined that both rips were identical. No issue with mismatched checksums. I am using an LG WH16NS60. See attached analysis: Wonder Woman (US).xlsx (25.3 KB)
Thanks - I’ll now try a couple of rips using different combos of drives and PCs to see if I can find a pattern. Looking at my notes from my early rips the Laptop and BU40N seems to have produced good rips, and the PC with the BH16NS55 is more hit and miss. Not sure of the PC and BU40N. I’m going to test just copying Planet Earth Disk 1 00059.m2ts as it is the smallest at 17GB (and hence quickest) to see if I can narrow it down.
Can also confirm - two back-to-back rips of Wonder Woman (US) - one using the Copy to Hard Disk feature of DeUHD, and one just using Explorer to copy 00001.m2ts. Both rips have identical MD5s for 00001.m2ts, and also matches @Balthazar2k4’s SHA1 of 00001.m2ts.
Thanks. Just did 3 good rips of PE 59.m2ts on my laptop using the BU40N… then a rip on my Main PC with the BU40N was bad. So it does not seem to be the drive but something about my PC… time to start eliminating things…
My current theory on my bad rips is that it the DeUHD decryption process does not like either:
- My OC settings esp when other processes are hammering the cores during ripping. I seem to get a good rip when nothing major is happening on the CPU but get bad rips when other intensive processes are running. To test this theory, I’m running Prime95 Blend Test while ripping, get a bad rip, drop the OC, retest. I’d rather stable than the bleeding edge (though I’ve already tested the RAM using MemTest86 and did a CPU stress test overnight @ 5GHZ)…or:
- Other Processes accessing the disk when ripping is underway. I use JR Media Center for playback and it scans the drives. One test was to access the disk from JRMC while ripping and that rip did not go well. If the above test fails I’m going to try shutting down JRMC (etc) while ripping is happening.
Thanks for the help - Looks like it was my OC. Dropping from 5 to 4.8ghz seems to have sorted it. Did a bunch of rips and it is all good (even with the cores being hammered at the same time by Prime95). Doing a 2nd test now to see if DeUHD is thread safe by doing simultaneous rips from both drives are the same time.
It would be good to know if DeUHD releases an “updated” decryption so we have an indication to re-rip the impacted discs.
I just sent the following to Support:
Could you please consider a way to advise when you update your decryption for a particular disc? There have been a couple now with errors when they were first released as supported, but were later “fixed”. Instead of having to retest every disc already ripped to see if there is a later “fix”, it would make much more sense to add something to your webpage or a notification via the app that there is a later decryption set for an already ripped disc.