Update:
* D1_broke.iso: This was a rip of the file over a year ago. All the other discs in the set worked except for this one. This ISO will not mount with VirtualDrive (says Corrupt). This is from the dedicated ripping station early in its career.
* D1_w32.iso: Attempting to resolve the issue, I re-riped the disk on the same ripping station with the same drive. This ISO will not mount with VirtualDrive (Says Corrupt). This is dedicated ripping station that has been used successfully for a year with very few problems.
* D1.iso: Attempting to isolate the problem, I move the BD-DRIVE to a Windows 10 Laptop and ripped the same disk again. This ISO works fine. This was with the same drive and USB cables as the ripping station.
According to the MD5 files generated by AnyDVD, the WinXP/32 rip and the Win10/64 rip matched. To verify, I ran an MD5 command on each of the ISOs.
Are you sure that the md5sum of WinXP/32 rip and the Win10/64 rip do match each other ??
WinXP/32 rip
= STAR TREK TNG S2 D1_w32.iso ? Correct?
Win10/64 rip
= STAR TREK TNG S2 D1.iso ? Corrrect?
At least the
file sizes of "STAR TREK TNG S2 D1_w32.iso" "and STAR TREK TNG S2 D1.iso" are
different.
See the upper table column of cmd.
Size Bytes Date Filename
46728010781 Jan 3 2017 STAR TREK TNG S2 D1_broke.iso
=>46728
010781 Jan 17 19:57 STAR TREK TNG S2 D1_w32.iso
=>46728
871936 Jan 18 00:51 STAR TREK TNG S2 D1.iso
So the checksum of both can't match to each other anyway, due to different file sizes
But "STAR TREK TNG S2 D1_broke.iso" and "STAR TREK TNG S2 D1.iso" have the same file size, so the checksum of both theoretically could be the same
"STAR TREK TNG S2 D1_broke.iso" = also an WinXP/32 rip from same older machine?
That the md5sum is the same still depends on, if
both were decrypted (if same AnyDVD version), or if
both were
not decrypted =encrypted (different AnyDVD version possible for same checksum)
46728010781 Jan 3 2017 STAR TREK TNG S2 D1_broke.iso
46728010781 Jan 17 19:57 STAR TREK TNG S2 D1_w32.iso
46728871936 Jan 18 00:51 STAR TREK TNG S2 D1.iso
You said you got different checksum calculation from command prompt between STAR TREK TNG S2 D1_broke.iso (WinXP 32 rip 2017 a yeag ago) and STAR TREK TNG S2 D1_w32.iso (also WinXP 32 - reipped recenty from 2018)
But according to AnyDVD md5- file both checksums are the same?
Maybe you reripped the same disc in the same directory? (seen from file names, the file names are different) But maybe you didn't mark checkbox to create addional .dvd file when reripping under different file name? (.dvd which is necessary for additional md5)
(So the new XP32 rip was actucally without md5 file)
So maybe you read md5sum text from the
old iso-md5 file and compared that to the md5sum from
new iso
calculated from cmd,
where you DID NOT tell AnyDVD to generate md5-sum text file (perhaps). SO maybe you mixed up s.th. ??
----
Another hint:
Please forget all that stuff told below, if you don't use Linux anyway, and if you don't edit isos with iso-editing-software like UtraISO etc, and if you don't have brothers and sisters playing around with isos in Linux etc
--
Are you using also Linux to mount your Blu-ray/DVD isos to play from Linux, too?
When you
don't explicitely mount an iso
as read-only in Linux, the iso file checksum can change. Well I've seen this on earlier Debian Linux version from within the last 3-5 years ago.
mouting without paramter (=read
+WRITE):
=>mount xyz.iso /mnt/mnt
"iso is write protected, mounting read-only"
(So without paramter this is read
+WRITE):
This message
"iso is write protected, mounting read-only" is because of UDF file system and iso files are normally read-only and not edited, only with special software in normal cases, just for burning to media or reading content in a virtual drive.
Still I've watched the iso file checksum then had chanced after executing the command: =>mount xyz.iso /mnt/mnt
This is because it might be the s.th. small information is stored/edited in the ISO-file header (e.g. when the ISO has been mounted/unmounted, at what date/time).
When it's not mounted as read-only, then there's potentially write access eg. to change s.th. in the iso header.
When I mount explicetely mount the iso file as read-only:
mount
-o ro xyz.iso /mnt/mnt
No such message appearing =>"iso is write protected, mounting read-only"
After mounting/unmounting an iso from read-only mode also the file checksum has NOT changed
Well in later/latest Debian Linux versions the iso file checksum hasn't changed any longer, even when mounting
without read-only parameter, though, I think, if I remember correctly.