• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Lucky Number Sleven ISO does not play (resolved)

you can tell if a disc is most likely (minus bd+) properly decrypted by just playing the large m2ts files manually. If they play, you know its decrypted.
 
Yup doing this method for quick test, playing Blu-rays with MPplayer.
Just "moving" the .m2ts file with held mouse button to the MPlayer-icon on the Desktop linked to mplayer.exe.
Mostly with biggest one. But some Blu-rays movie discs have many .m2ts files for main movie , and if I remender correctly one such title was "Broke Back Mountain"

thefrog could test playing directly the m2ts video files in BDMV\STREAM with MPlayer program (just for testing purposes).
---
www.mplayerhq.hu =>downloads ->UPDATED MPlayer Windows builds HTTP =>(http://mplayerwin.sourceforge.net/downloads.html)
http://sourceforge.net/projects/mpl...r/r38008/mplayer-svn-38008-x86_64.7z/download
http://sourceforge.net/projects/mpl...MEncoder/r38008/mplayer-svn-38008.7z/download
Extract 7zip archive to your desired location into folder called "mplayer-svn-38008-x86_64"
In Win-Explorer Locate "mplayer.exe" and copy it as file-link icon from "mplayer.exe" to the desktop.
---

Mount your Blu-ray iso. In Win Explorer go to BDMV\STREAM.
Klick on one one .m2ts file in BDMV\STREAM file from the main movie and move this with still held mouse button over to the mplayer.exe-link icon on the desktop.
Check if it plays.

Another way, if the main movie consists of several m2ts files:
Go to the desktop and klick on mplayer.exe link icon -> Right Klick ->Properties.
At the tab "Link" where the path to the mplayer.exe is displayed, add some parameters how to run the mplayer.exe.
Please add following parameter behind:
br:// -bluray-device G:\BDMV\STREM
=>"...\mplayer-svn-38008-x86_64\mplayer.exe br:// -bluray-device "G:\BDMV\STREAM"

While G: is just an example for a drive letter of the mounted Blu-ray iso.
Perhaps yo umust change the "G:" to "H:" etc, so to which drive letter your iso is mounted in virtual drive.

...\mplayer-svn-38008-x86_64\mplayer.exe br:// -bluray-device "G:
should work, too.
So If only the drive letter without BDMV\STREAM please do not add a backslash \ behind G:
=>G:\ (=wrong). This is a syntax interpreting thing.
...\mplayer-svn-38008-x86_64\mplayer.exe br:// -bluray-device "G:\" <=wrong
...\mplayer-svn-38008-x86_64\mplayer.exe br:// -bluray-device "G:" <=correct

If you want several CPU cores (eg. 2) for decoding you can add "-lavdopts-threads=2
=>"...\YourPATH\mplayer-svn-38008-x86_64\mplayer.exe br:// -bluray-device "G:\BDMV\STREAM" -lavdopts threads=2

While G: is just an example for a drive letter of the mounted Blu-ray iso.
Perhaps yo umust change the "G:" to "H:" etc, so to which drive letter your iso is mounted in virtual drive.

Check if your Blu-ray plays now. Double check that the syntax is as provided by the example.
(Sometimes there if is a slythly mistake in the syntax like missing blanc space character between several program paramters etc. or misspelled paramter, so it appears as the disc wouldn't play and mplayer.exe exits at once.)
 
Last edited:
@theosch :

I deleted the 'Broken One" shortly after everything was working. I understand what you are saying about unencrypted MD5's not matching for different options of unencrypted ISOs and why.

'The Broken One' was made with a different set of options and possibly, but not certainly with a different AnyDVD version. I am reasonably sure that the protection was removed because the player log file says that there is no AACS protection (log file attached previously).

I am currently working on two other BDs that do not produce working ISO files. These are older pressings of Men In Black 2 and Conspiracy Theory. There just doesn't seem to be any reason they wouldn't be working.

Should I start a new Thread? I was going to poke it in various ways first. Not sure why some BD produce usable ISOs and some do not.
 
@theosch: I am going to follow your troubleshooting steps above with these other movies.

Thanks.
 
Update:

I have to apologize for having deleted the original 'broken' Slevin movie. I've moved on to a few other problem BD's and used the information everyone has provided in this thread to aid troubleshooting.

Here is an example of a BD I am dealing with: Star Trek TNG Season 2, Disc 1:
Code:
Size Bytes  Date         Filename
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

* 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.


Code:
File         MD5 CMD                           MD5-File
D1_broke.iso 7cbe6151fab1094d4a053c262f03a449  4ed7b3b613f17cadfa1c0ace2c8c7e33
D1_w32.iso   44726affdba16151e368a83c0ede5bf1  b11f2e94e6ffc2a99d94e1f9003422d5
D1.iso       b11f2e94e6ffc2a99d94e1f9003422d5  b11f2e94e6ffc2a99d94e1f9003422d5

I was very surprised. So the Win10 rip MD5 file and MD5 sum matched, but the previous two rips did not have the MD5 sum of the ISO match the MD5 file written by AnyDVD HD.

I have provided a ziplog file from the Ripping station.

So, what is broken on WinXP/32? Why is it one disk out of the UK Star Trek TNG (complete series).. and has persisted on that same disc for over a year. Any debugging thoughts? New ticket? Old Problem?

Additional Info: FileZilla was used to FTP this file (all times), the D1_w32.iso file as it was written to the ripping stations's HD shows corrupt on the w32 in VirtualDrive.

 

Attachments

  • AnyDVD_8.2.1.0_Info_F_STAR TREK TNG S2 D1.ziplog
    201.3 KB · Views: 3
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
=>46728010781 Jan 17 19:57 STAR TREK TNG S2 D1_w32.iso
=>46728871936 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.
 
Last edited:
@theosch :

I am not experienced with quoting.. attempting to answer your questions in order:

Are you sure that the md5sum of WinXP/32 rip and the Win10/64 rip do match each other ??
The md5 sum of the FILE does not match. The MD5 Files written by AnyDVD do match.
WinXP/32 rip = STAR TREK TNG S2 D1_w32.iso ? Correct? yes
Win10/64 rip = STAR TREK TNG S2 D1.iso ? Corrrect? yes

So the checksum of both can't match to each other anyway, due to different file sizes :)

I was careful with the provenance of each file. The WinXP vs the Win10 file are different sizes and different MD5 sums.. but AnyDVD HD 'thinks' it wrote identical bits (hence identical md5 sums in the file). I think the WinXP machine lost some of those bits.​

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?

I assume you meant to type _broke and _win32 files are the same size (happens to me also!)
The checksum would not be the same because the AnyDVD versions were different. However, the fact that they are the same size is interesting because whatever failure of WinXP happened happened twice and a year apart. The machine is the same from last year to this year. I did a HexDump on the .iso file and found the AnyDVD version to be different on _broke and _w32. Both (all) files are not encrypted.​

[Great information about older Debian messing with ISO files if not mounted -oro .. a circumstance I didn't know existed]

The 'broken' files do not mount on Win32 or Win10 with Virtual CloneDrive 5.5.0.
I am using FreeBSD (FreeNAS) -- the mount error is generic and unhelpful -- not even sure it has udf.
I can move the files to Linux to attempt to mount them, it might be more forgiving with a corrupt file.
In normal operation, i never mount the ISO file.. i let the Kodi player read them directly.


Thank you for your engagement. I appreciate troubleshooting.

--thefrog​
 
46728010781 Jan 3 2017 STAR TREK TNG S2 D1_broke.iso
46728010781 Jan 17 19:57 STAR TREK TNG S2 D1_w32.iso

Hm, the older STAR TREK TNG S2 D1_broke.iso is from January 3rd 2017.
And STAR TREK TNG S2 D1_w32.iso is from January 17th 2018 19:57.
Both from same machine (WinXP 32)
And both have same size. That's odd. I can't imagine that the HDD would lose the same amounts of bits by coincidence in the newer XP reripped iso as in the older one.
It's more likely AnyDVD bug (perhaps) losing some bits, as you proposed. Maybe AnyDVD uses some other parts of drivers in XP than in Win10 64, and the parts for XP maybe a bit buggy in some cases.
Yes I agree maybe you should tell RedFox (and maybe collect some more information from testing, see further below)
---
That's really interesting.
Well I had an issue with two different optical drives.
One optical drive (LIteON iHOS-104 reports higher sector count on most Blu-ray discs than all my other optical drives Pioneer BDR-205 and LG BH16NS40, which last both do have the same sector count reporting)
So I guess my LiteON iHOS-104 is wrong, but Pioneer and LG are right (because both the same sector count reportings)

But other issue are you using same optical drive model on both machines anyway.
----
@thefrog
You said you can try to mount in FreeBSD. Good chance it works. I had problematic isos myself e.g. from internet, which my Alcohol 120% virtual drive software in Windows was unable to mount, but Linux was able to do.
Could you mount the XP isos in FreeBSD? (Good idea)
I've an idea. There's also the sector count reporting in the disc.inf file. Please check the sector count reported in the disc.inf from AnyDVD in the isos from WinXP and from Win10.
Please check if the sector count reporting in disc.inf is the same as from the Win10/64 rip, if FreeBSD manages to mount the isos :)
If it is the same.
Also you can calculate the sectors which optical drive/AnyDVD has put in the disc.inf file to get the corresponding file size. Check if sector count matches to the iso file size in BYTES.
Blu-ray/DVD all use UDF (Universal Disc Format).
The Block/sector size in UDF is 2048 Bytes.
Check the sector count reported in disc.inf and multiply that with 2048 Bytes per sector in a calculator.

Example:
disc.inf

[disc]
type=BD-ROM
version=AnyDVD HD 7.5.5.0 (BDPHash.bin 14-11-27)
totalsectors=21000448 <==============================
label=INTO_THE_WILD_BD
speedmenu=0
region=2
3D=0
fps=23

Example
21000448 sector(s) * 2048 Bytes/sector =43,008,917,504 Bytes

Check if the calculated size from sector count reported in the disc.inf -file in the iso matches to the iso file size. So maybe it doesn't match also, and it's a hint that it's even more AnyDVD.

Do that with the iso from WinXP and from Win64 :)

For sure I'd use the iso from Win10/64. If it mounts it's surely the good one.

Well I agree that RedFox could try to fix it in XP, if it is an AnyDVD problem in WinXP.
If the sector count reporting in the ISO in the disc.inf created from AnyDVD differs to the iso file size, also, maybe I'd also tell RedFox :)
 
Last edited:
Code:
[disc]
type=DVD-ROM
version=AnyDVD HD 8.2.1.0 (BDPHash.bin 17-07-03)
totalsectors=22816832
layers=1
label=STAR TREK TNG S2 D1
speedmenu=0
region=-1
3D=0
fps=23

Size: 46,728,871,936
 
@Thank you
Which iso is that?
--
OK I guess one of this
46728010781 Jan 3 2017 STAR TREK TNG S2 D1_broke.iso <=according to cmd
46728010781 Jan 17 19:57 STAR TREK TNG S2 D1_w32.iso <=accroding to cmd

There's another thing that's not fitting.
The iso file size of 46728010781 Bytes of STAR TREK TNG S2 D1_broke.iso and STAR TREK TNG S2 D1_w32.iso itself does not contain a full number of sectors.
It is not divisable with 2048.

46728010781 Bytes * sector /2048 Bytes = That's 22816411.51416015625 sectors
In this case the "real" iso file size contains contains one part of a sector only.
That's not a full number, but a fraction number (ratio).
The iso is defintely corrupt. You have always complete count of sectors, not part of it on iso files!
The real sector count according to iso size should be integer, and the last digit is divisable with 2, I think on iso files.

Did you create both bad ISOs from WinXP as sparse files in AnyDVD image ripper? If yes, please leave sparse file checkbox in AnyDVD disabled.

Well I had the issue, that ISOs made as a sparse file with AnyDVD Image ripper the Alcohol 120% virtual drive software could not mount, maybe that also goes for Virtual Clone Drive.

[Edit]
OK. Sry I hope I'm not too much hurrying.
Is FreeBSD able to mount those two bad ISOs, too?
Goes that also for FreeBSD that it just mounts the good ISO from Win10 64?
(In your comment it was not so specific)
Well I guess not, otherwise a hexdump probably was not necessary. Just mount it, but I guess you tried that already.
 

Attachments

  • (Leave_checkbox_sparse_file_Unchecked).PNG
    (Leave_checkbox_sparse_file_Unchecked).PNG
    12.5 KB · Views: 3
Last edited:
The Drive is an LG: "HL-DT-ST BD-RE BP50NB40"

I am using hexdump to try to find the disc.inf on the 'bad' ISO (_w32).. this was from the 'good' ISO that is mountable and works.

Both 'bad' and the one 'good' ISO were *all* made with the same drive (an external USB)

I will update this comment when I get the information (it takes 9 minutes for an MD5-sum)
 
@Thank you
Which iso is that?
--
OK I guess one of this
46728010781 Jan 3 2017 STAR TREK TNG S2 D1_broke.iso <=according to cmd
46728010781 Jan 17 19:57 STAR TREK TNG S2 D1_w32.iso <=accroding to cmd

There's another thing that's not fitting.
The iso file size of 46728010781 Bytes of STAR TREK TNG S2 D1_broke.iso and STAR TREK TNG S2 D1_w32.iso itself does not contain a full number of sectors.
It is not divisable with 2048.

46728010781 Bytes * sector /2048 Bytes = That's 22816411.51416015625 sectors
In this case the "real" iso file size contains contains one part of a sector only.
That's not a full number, but a fraction number (ratio).
The iso is defintely corrupt. You have always complete count of sectors, not part of it on iso files!
The real sector count according to iso size should be integer, and the last digit is divisable with 2, I think on iso files.

Did you create both bad ISOs from WinXP as sparse files in AnyDVD image ripper? If yes, please leave sparse file checlbox in AnyDVD disabled.

[Edit]
OK. Sry I hope I'm not too much hurrying.
Is FreeBSD able to mount those two bad ISOs, too?
Goes that also for FreeBSD that it just mounts the good ISO from Win10 64?
(In your comment it was not so specific)
Well I guess not, otherwise a hexdump probably was not necessary. Just mount it, but I guess you tried that already.
 
Trying to catch up. The 'difference' in the ISO between the Good/Bad (Win10/WinXP) with same version of AnyDVD is somewhere in the first 2000 blocks of the ISO file.

I have not found anything that can mount the 'BAD' ISO files.

This is the first set (of 10 blocks) that differ. Still no luck on the disc.inf on the hexdump search yet.
Code:
dd if=STAR\ TREK\ TNG\ S2\ D1.iso bs=2048 count=10 skip=350 | md5 ; dd if=STAR\ TREK\ TNG\ S2\ D1_w32.iso bs=2048 count=10 skip=350 | md5
10+0 records in
10+0 records out
20480 bytes transferred in 0.000237 secs (86417853 bytes/sec)
278318557ffbc1dc1d90caf0df23aaff
10+0 records in
10+0 records out
20480 bytes transferred in 0.000231 secs (88647416 bytes/sec)
80511a30a267e1e2e770e71a10fe056d
 
OK, I'm not such good Unix expert (my brother and father know much more than me) :)

You could try, maybe a zip program manages to open the bad iso. I know that PowerArchiver (Windows program) can open UDF iso files.

You could also add the file size difference between STAR TREK TNG S2 D1.iso made with Win10 64, and STAR TREK TNG S2 D1_w32.iso with "dd" to the STAR TREK TNG S2 D1_w32.iso. Maybe then this mounts.

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 <==

46728871936 Bytes - 46728010781 Bytes = 861155 Bytes

=>
Code:
cp -a STAR\ TREK\ TNG\ S2\ D1_w32.iso STAR\ TREK\ TNG\ S2\ D1_w32_test.iso
sync
dd if=/dev/zero of=STAR\ TREK\ TNG\ S2\ D1_w32_test.iso bs=1 seek=46728010781 count=861155 conv=notrunc
(I think dd starts counting from 0, so seek=46728010781 should be correct (=starting to add 861155 Bytes at beginning from the 46728010782th byte) So this should be correct, shouldn't it?

After the 861155 Bytes of zeros (0) were added (backup using as test file), maybe this copy STAR TREK TNG S2 D1_w32_test.iso + with added additional 861155 Bytes will mount.
46728010781 + 861155 Bytes = 46728871936 Bytes

Maybe STAR TREK TNG S2 D1_w32.iso doesn't mount due to one not full real whole sector count seen from STAR TREK TNG S2 D1_w32.iso file size.
-------------------
Another thought:
What file size does "ls -l" list ? Or "ls -alsh" ?
http://extrabright.com/blog/2010/03/30/how-to-know-if-a-file-on-linux-is-sparse/
{...}
"It’s super easy, to know if a file is sparse or not. Just use the ‘s’ option of ls."
{...}

So Maybe the bad iso is a sparse file, that might be a reason why it's smaller.
I've seen zeros at start and beginning of Blu-ray media/ or ISO and when making especially a sparse ISO it might appear "shortened" /so some gaps with zeros (might) appear missing to filesystem/programs, if at all that I'm talking not any nonsense.
I'm not too familiar with what sparse files are and do. Maybe I'm wrong.
I'm not sure if sparse file can have anything to do with mount problems in Linux, FreeBSD, WIndows. But I know that my virtual drive software (Alcohol 120%) in Windows doesn't like it, if at all I remember correctly.

https://forum.redfox.bz/threads/virtual-clone-drive-refuses-to-mount-certain-iso-files.59695/
I don't know if this is the same problem, and if not, I'll start another thread. I created an ISO of the film Rage (I know, I know). VCD allows the ISO to be mounted. ISO was created allowing use of sparse file. However the mounted image is not accessible by Windows 8 (latest). The dialog box says "Windows can't access this disc". Daemon works fine. I'd rather use VCD.
---

This was posted in 2014 before Win10 was released. According to gr8sho since latest Win 8 (2014), VCD (or just Win8 Windows file Explorer itself only?) would have problems with sparse files, may this also goes for Win 10.
Did you make the bad ISOs as a sparse file?
 
Last edited:
I do _always_ have the 'sparse' box checked. I have ripped 100's with that configuration successfully. I can re-rip the BD again with and without it.

I doubt the 'sparse'ness survives the FTP anyway. I will update after I re-rip without the sparse-file checkbox.

The problem is early in the file.. so it is corrupt early in the filesystem header. Researching testing for sparse.

[Edit: Yes, both 'good' and 'bad' files were created as 'sparse']
 
OK, this is way too much text, so I'm not going to bother following up on all this.
But - I have a strong feeling, that all this is not at all about the thread topic, especially regarding the fact, that it is marked "resolved"?
If so, please either get back on topic or continue in a more appropriate section and thread.
Thanks.
 
@Pete strange pattern. MD5 Sum file written by AnyDVD HD on WinXP doesn't match the MD5 sum of the file that is written. ISO that is produced on WinXP is not valid... same BD on same drive attached to Win10 with same AnyDVD HD version produces ISO file with same MD5 Sum file written by AnyDVD HD as WinXP.. but the file is a valid ISO with an MD5 sum that matches the MD5 file written at creation.

It's rare. Happened while investigating Slevin and other things failing the same way. @theosch was helping get details and track down the facts of the issue.

Sorry for the wall of text. No idea where to go from here. I don't even know if the first paragraph of this reply is coherent.
 
@Pete strange pattern. MD5 Sum file written by AnyDVD HD on WinXP doesn't match the MD5 sum of the file that is written. ISO that is produced on WinXP is not valid... same BD on same drive attached to Win10 with same AnyDVD HD version produces ISO file with same MD5 Sum file written by AnyDVD HD as WinXP.. but the file is a valid ISO with an MD5 sum that matches the MD5 file written at creation.

It's rare. Happened while investigating Slevin and other things failing the same way. @theosch was helping get details and track down the facts of the issue.

Sorry for the wall of text. No idea where to go from here. I don't even know if the first paragraph of this reply is coherent.
If the checksum from file doesn't match, something outside of AnyDVD is defective, as the checksum is calculated during writing. That's the idea behind the checksum.
 
I do _always_ have the 'sparse' box checked. I have ripped 100's with that configuration successfully. I can re-rip the BD again with and without it.

I doubt the 'sparse'ness survives the FTP anyway. I will update after I re-rip without the sparse-file checkbox.

The problem is early in the file.. so it is corrupt early in the filesystem header. Researching testing for sparse.

[Edit: Yes, both 'good' and 'bad' files were created as 'sparse']

I'm sorry, that's me writing too much text.

@RedFox
The problem is reproducible on his WinXP-AnyDVD machine with "STAR TREK TNG S2 D1"-Blu-ray / maybe some other Blu-rays, correct thefrog?

Well if the HDD was damaged and it would overlap with the problematic ISO files, then why does it stilll get an md5sum on those files, too?
If HDD was damaged, there should be an input/output -error when trying to read the iso file when trying to calculate its md5sum.

That's interesting that ISO sparse files from some Blu-ray movies mount in VCD and that some don't.
If it's really not the HDD and not AnyDVD, maybe some sparse iso files from some movies are created and listed in the file system with an file size which is not divsable fully through 2048 Bytes.
If that can happen, maybe that's why some sparse ISO files mount, and some ISO sparse files from other Blu-ray movie discs don't.

But he ripped the same disc "STAR TREK TNG S2 D1" in Win10 as a sparse as well, and this mounts in VCD and md5sum from iso matches to md5 file from AnyDVD and file size is bigger.
Other discs made even from his WinXP machine don't make any problem, even as sparse.

It looks like that AnyDVD is not doing always the same thing in WinXP as in Win 10 with some discs (maybe only in ripping to sparse ISO), (if there's not any other disturbing factor that I have forgot)

@thefrog
Good idea to try to rerip without sparse (with WinXP)
I'm excited what the result will be :)

I think I have this completely figured out.
1/ 1/18: Copied BR, transferred to NAS. 'LUCKY_NO_SLEVIN.iso' (MD5 Sum matches neither Encrypted nor Unencrypted)
This BR ISO is corrupt. Doesn't work on any player.

Copying sparse files in fact can make problems when using files systems/programs which can't handle sparse files correctly. Maybe your NAS has own software/firmware incompatible for sparse.
Is your NAS on a SATA-HDD on a computer server with updated software, or is it an NAS-HDD-case with its own firmware?
Well the the question is if the sparse file from Win10 which works was also was created via /copied to your NAS.
 
Last edited:
If the checksum from file doesn't match, something outside of AnyDVD is defective, as the checksum is calculated during writing. That's the idea behind the checksum.

@James I was shocked to find files with an MD5 sum that didn't match the MD5 file. I can work-around the problem for the tiny percentage of Disc's that have had it -- now that I know it is a possibility. @theosch and myself thought it might be interesting to @RedFox

I am ripping the BD fat (non-sparse) now to satisfy a question.
 
Back
Top