Author |
Message |
Registered: May 2, 2009 | Reputation: | Posts: 490 |
| Posted: | | | | Quoting GreyHulk: Quote: I've said before, If anyone needs an old copy of AnyDVD (registered to me) which will solve the problem, I can send it. Just send me a private message and I will get it to you.
Neil I just found this thread, but I wasn't unaware of this problem. Although I must say I had hoped this was fixed by now, in some way. Either way, I want to get some things straight. • Does this affect (more) recent updates of AnyDVD? Which version(s) give the proper DiscID? • Does this affect UHD DiscID, or is it mostly prone to give invalid DiscID's for DVD's? • What are the reliable workarounds, and are there different scenarios? I have recently bought a BD 4K UHD drive. Pioneer BDR-212UHT to be specific. With it, I intend to submit all UHD discs I have bought and will buy. I have a "monster PC" for that drive. Will I (we!) encounter any problems? I would definitely consider purchasing an AnyDVD license given it will work as intended. I also have another "work" PC, on which I run both Win 10 and Win 7, and I have another BD drive for it. So thusly I could contribute non 4K BD DiscID's with that setup. I absolutely do not want to poison the DB neither locally nor online with bad DiscID's and I must say I am also worried that those that are contributed nowadays may be faulty. Last but not least: has anyone tried to actually contact Microsoft about this? I absolutely believe in trying that. If need be, we could team up to make our voices heard more loudly. However I don't really grasp where in all this the problems lie: Win 10 itself, AnyDVD or the optical drives? Or DVDProfiler? |
| Registered: November 24, 2008 | Reputation: | Posts: 1,285 |
| Posted: | | | | The problem is purely down to Windows 10 and only affects DVDs. The 1809 update seems to have started the issue.
AnyDVD, for now, solves the problem by calling the Disc ID direct from the drive, bypassing Windows altogether. That is why I have offered my (older but functional) copy for free to anyone who wants it, it's not worth forking out money to solve the issue for now.
Any other version of Windows is unaffected. Blu-rays are unaffected. | | | Last edited: by GreyHulk |
| Registered: March 13, 2007 | Reputation: | Posts: 767 |
| Posted: | | | | Quote: • Does this affect (more) recent updates of AnyDVD? Which version(s) give the proper DiscID? I have version 8.5.0.0. When AnyDVD is enabled, you'll get the 'old' DiscID. Scanning the DVD with AnyDVD running, will find it in the DVDP databas if it's there. 'New' DiscIDs are never found in the database when scanning the DVD. Quote: • Does this affect UHD DiscID, or is it mostly prone to give invalid DiscID's for DVD's? As far as I can tell, it only affects DVD's. Not blu-rays or UHD. Quote: • What are the reliable workarounds, and are there different scenarios? If there's no DiscID info in the database (either in the Disc Info field, or as a standalone DiscID profile), then we should submit the regular DiscID, without the interference of AnyDVD. We should consider that most contributors are not familiar with the disc id issues. The unfortunate thing is that the new DVD DiscIDs (the ones that are scanned without running AnyDVD) are not recognized by the DVDP program. That would require a program update.... Ken? Hello? Anyone?? Anyone who has contributed DiscID profiles with AnyDVD running, should flag these DVD profiles for removal, and resubmit. Quote: I have recently bought a BD 4K UHD drive. Pioneer BDR-212UHT to be specific. With it, I intend to submit all UHD discs I have bought and will buy. I have a "monster PC" for that drive. Will I (we!) encounter any problems?
I also have another "work" PC, on which I run both Win 10 and Win 7, and I have another BD drive for it. So thusly I could contribute non 4K BD DiscID's with that setup.
I absolutely do not want to poison the DB neither locally nor online with bad DiscID's and I must say I am also worried that those that are contributed nowadays may be faulty. Again, only for DVD's. Quote: I would definitely consider purchasing an AnyDVD license given it will work as intended. If we reach a consensus (or if there's an update to the contribution rules....) about not using AnyDVD for DVD contributions, then you shouldn't have to buy it. Quote: Last but not least: has anyone tried to actually contact Microsoft about this? I absolutely believe in trying that. If need be, we could team up to make our voices heard more loudly. Way back there was a ticket submitted to Microsoft Developers, but it was up to 10 supporters or something like that. I think you're overestimating the power of the DVDP community Quote: However I don't really grasp where in all this the problems lie: Win 10 itself, AnyDVD or the optical drives? Or DVDProfiler? The initial change came from Win10, but my opinion is that DVDP should have been updated to work correctly. Also, an important thing to mention once more, is that the DiscID issue only affects DVD's. Most of today's contributions are blu-ray and UHD, and there are no DiscID issues with these formats. Personally, I've never cared for HD formats. I'm still a big fan of DVD's, and I still contribute new ones, even if I might be the only one. |
| Registered: November 24, 2008 | Reputation: | Posts: 1,285 |
| Posted: | | | | Quoting DJ Doena: Quote: With mediadogg's help I wrote a small program that reads out the DiscID just like profiler does and used it to create a bug report with Microsoft using marcel's additional info about the cdrom.sys driver
Here's the Microsoft Feedback Hub link: https://insider.windows.com/
If you care to do so, please upvote using Windows 10 Feedback Hub. |
| Registered: November 24, 2008 | Reputation: | Posts: 1,285 |
| Posted: | | | | Please don't call them 'new' Disc IDs. They are wrong. All other versions of Windows report the correct Disc ID, Windows 10 reports an incorrect one - until they solve this problem. Once the problem is solved, these 'new' Disc IDs will just disappear. Please call them 'fake' Disc IDs if anything. All current versions of AnyDVD call the Disc ID direct from the drive. AnyDVD is no longer the problem it used to be. Quote: Quoting marcelb7: The unfortunate thing is that the new DVD DiscIDs (the ones that are scanned without running AnyDVD) are not recognized by the DVDP program. That would require a program update.... Ken? Hello? Anyone?? | | | Last edited: by GreyHulk |
| Registered: March 18, 2007 | Reputation: | Posts: 1,639 |
| Posted: | | | | Quoting marcelb7: Quote: Anyone who has contributed DiscID profiles with AnyDVD running, should flag these DVD profiles for removal, and resubmit. Why should these [be] flagged for removal when a certain Windows 10 update is the issue. | | | Last edited: by rdodolak |
| Registered: May 2, 2009 | Reputation: | Posts: 490 |
| Posted: | | | | Quoting GreyHulk: Quote: The problem is purely down to Windows 10 and only affects DVDs. The 1809 update seems to have started the issue.
AnyDVD, for now, solves the problem by calling the Disc ID direct from the drive, bypassing Windows altogether. That is why I have offered my (older but functional) copy for free to anyone who wants it, it's not worth forking out money to solve the issue for now.
Any other version of Windows is unaffected. Blu-rays are unaffected. Thanks for replying. I see. I myself have used AnyDVD for many, many years and it's essential to me, because of bypassing region locks and also getting rid of annoying, time consuming disc startups. (Albeit AnyDVD takes some time "scanning" discs before launch.) I'm using v. 7.6.9.2. and it seems to work as it should and also giving the correct DiscID. But not using it gives an incorrect DiscID, nor can I add a DVD to collection via the drive correctly. I'm not sure why, but when I am inside DVDProfiler and choose "Scan DVD-ROM Drive", nothing happens, regardless of having AnyDVD enabled or not. Quoting marcelb7: Quote: If there's no DiscID info in the database (either in the Disc Info field, or as a standalone DiscID profile), then we should submit the regular DiscID, without the interference of AnyDVD. We should consider that most contributors are not familiar with the disc id issues. I must say I disagree with this. First of all, it's not exactly difficult to get your hands on AnyDVD/AnyDVD HD and I'd think for a lot of us this program is rather essential, if you have region locked DVD's. Secondly, GreyHulk offers it here freely. And thirdly it's like sticking your head in the sand about the problem existing and it won't go away just because we start to submit hundreds or thousands of erroneous ("alternate") DiscID's. I think I will start to vote NO for any new DiscID contributions for DVD's unless they can prove it's the correct one. People are here to cooperate on contributing to the database. That means finding the proper answers, methods and solutions available, before you contribute. Anything else is just ruining the integrity of the DB, built up for so many years. Why should we accept "newcomers" or people who "can't" adapt? We have already established that there is at least one way to get around the problem at hand, so if we don't all adhere to this, what's the point? There's not even a reason for discussion as I see it. I'd go so far as to "blacklisting" people who can't or won't contribute properly. A bad DiscID is a bad DiscID and has no place ever in the DB (other than in your local). Even less so if Win 10 can generate several bad ones for the same disc. |
| Registered: October 22, 2015 | Reputation: | Posts: 275 |
| Posted: | | | | As far as I can see,there are two problems, namely, the online profile list and alternate DVDids.
Too often, the problems of the online profile list not showing UPC profiles when adding a disc is incorrectly blamed on the alternate DVDid issue.
ON-LINE PROFILE LIST and UPC PROFILES: On my Windows 10 and Windows 7 systems, I found NO UPC profile was listed when adding by disc, where the Disc Info was submitted and approved after beginning of 2017 (this is true for DVD, Blu-ray and 4K discs).
To eliminate windows 10 from the equation, I conducted various tests over the last six months on a windows 7 platform, with the following Add by Disc results for UPCs explained: ==> when you insert a disc, the Add by Disc screen will show the UPC if the Discid in the UPC profile was submitted and approved PRIOR to 2017.
==> when you add an additional Discid in the Disc info section of an existing UPC profile, the online profile list will accommodate the additional Discid. After approval, when you use the Add by Disc screen, the UPC will only show if there exists a Discid in the UPC profile that was submitted and approved PRIOR to 2017.
This problem appears to have started well before the Win10 ver1809 upgrade (13-Nov-2018) and the release of DVDP version 4.0 (16-Sep-2017).
I do note under "Bug Fixes in version 3.9" the following fix: Fixed: Identifies literally every title as hell on wheels, when adding by disc id
Did the problem exist then or did the fix introduce another problem that was missed in the beta testing phase?
ALTERNATE DISC-ID ISSUES: The biggest impact is on Win 10 users without AnyDVD software, they will ONLY find new DVD Discid profiles created using the alternate DVD Discid (HD-DVD, Blu-rays and 4K are unaffected), whereas the AnyDVD user will be able to find any Discid profile as well as any UPC profile whose discid was approved prior to 2017, by enabling/disabling AnyDVD.
The display of UPC profiles, created after beginning of 2017, by the "Add by Disc" process is a non-event. It won't display UPCs no matter whether the disc type is Blu-ray, 4K or DVD (good or bad id).
Overwriting Discids in a UPC profile is OK, the online database stores multiple Discids, but when you download it, its always the last entered Discid that is downloaded. So lock it if you want to maintain the previous Discid in the UPC profile. If the previous Discid was approved prior to 2017 then it will continue to show in the Add by Disc screen.
Will Microsoft fix the DirectShow API involved in the DVDid calculation? No, it is now listed as deprecated software, slowly being replaced by Media Foundation software. Also note that Microsoft forcibly removed their own Media Center and DVD player software, that used the DVDid for bookmarking, in the Win 10 ver1809 upgrade. So their intentions are clear.
Can Invelos fix the DVDid problem? Yes, they could if they tried. Currently, DVDP calculates the HD-DVD, Blu-ray and 4K Discids internally, whilst the DVD Discid uses Microsoft's DIRECTSHOW APIs. To fix it, Invelos will need to modify the program code to calculate the DVD Discid and ensure it is backward compatible. The quickest and simplest way for Invelos to incorporate the change is use existing public domain software that comes with its own C source code, and it does exist!
At the end of the day, I have found no evidence to prove the alternate DVD Discid is not unique, so its business as usual. Yes, I understand some search results are not complete, in particular, old DVD Discid profiles, but that is not a game-stopper.
When I compile a DVD box set, I use the Win 10 (no AnyDVD running) Discids, because the child Discids are accessible to all Win 10 users in the community, including those using AnyDVD software. | | | Last edited: by ObiKen |
| Registered: March 14, 2007 | Reputation: | Posts: 6,744 |
| Posted: | | | | Quoting ObiKen: Quote: Initially, I ran Process Monitor tool and an API monitoring tool to check what happens when dvdpro.exe adds a DVD Disc ID in the database. I could see files in the VIDEO_TS directory were being read and some attributes such as filename, file size and date and times were also read. But all the read data was correct and matched the values found on the DVD.
I ran the same test on many DVDs over many versions of Windows (XPsp2, Win7sp1, Win10v1709, Win10v1809, v1903, v1909) and found no evidence of corrupted data read from the DVDs.
Eventually, I did more research on the 64-bit CRC and found Microsoft's US patent which descibed the concept of the unique 64-bit CRC and how it could support bookmarking. I learnt that there were four steps in the calculation process:
Step 1: The filenames in the VIDEO_TS directory are collected and sorted alphabetically into a list
Step 2: For each filename in the list, the following structure is filled out and added to the CRC (all data fields are in LSB first): ==> unsigned 64 bit Integer: dateTime (the time elapsed in 100 nanosecond intervals from Jan. 1, 1601) ==> unsigned 32 bit Integer: FileSize ==> BYTE: Filename [filename Length] ==> BYTE: FilenameTermNull=0
Step 3: If present, the first 65,536 bytes of "VIDEO_TS.IFO are read and added to the CRC (if smaller then the entire file is added)
Step 4: If present, the first 65,536 bytes of "VTS_01_0.IFO are read and added to the CRC (if smaller then the entire file is added)
In a nutshell, each file's attributes in the VIDEO_TS directory and the first 65,536 bytes of data from VIDEO_TS.IFO and VTS_01_0.IFO are the inputs added to the concatenated binary polynomial equation that generates the 64-bit CRC.
With the above steps in mind, I revisited the previous capture files I had and it finally dawned on me something did change with Win10 ver1809.
On every Windows platform, steps 2,3 and 4 were being carried out properly. On the other hand, step 1 had changed: ==> Prior to Win10 ver1809, step 1 was being carried out properly. ==> From Win10 ver 1809 and onwards, only a subset of files in the VIDEO_TS directory were being read (VIDEO_TS.IFO, BUP and VOB, and VTS_01_0.IFO, BUP and VOB).
I can't give you a reason as to why the algorithm for calculating the DVD's unique 64-bit CRC changed, but I do note that both Microsoft's Windows Media Center application and Windows DVD Player application were both forcibly removed by the Win10 ver1809 upgrade, and both used the bookmarking feature via the DVD's unique 64-bit CRC!
Was the change just collateral damage? I'll leave that to someone else to take up the gauntlet. All I know is I finally convinced myself that CDROM.SYS was not the problem. Do you happen to know which CRC64 algorithm is being used? I.e. which polynominal? I've tried to trasnscribe the polynominal from the patent (page 19) with the help of https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Specificationinto these numbers, but neither MSB nor LSB worked: LSB: 0b1001_0010_1100_0110_0100_0010_0110_0101_1101_0011_0010_0001_0011_0001_1010_0100 (0x92c6_4265_d321_31a4) MSB: 0b0010_0101_1000_1100_1000_0100_1100_1011_1010_0110_0100_0010_0110_0011_0100_1001 (0x258c_84cb_a642_6349) | | | Karsten DVD Collectors Online
| | | Last edited: by DJ Doena |
| Registered: March 13, 2007 | Reputation: | Posts: 767 |
| Posted: | | | | Quoting rdodolak: Quote: Quoting marcelb7:
Quote: Anyone who has contributed DiscID profiles with AnyDVD running, should flag these DVD profiles for removal, and resubmit.
Why should these [be] flagged for removal when a certain Windows 10 update is the issue. Because the profile ID is generated from the Disc ID. It would be confusing if the two were different. |
| Registered: March 14, 2007 | Reputation: | Posts: 6,744 |
| Posted: | | | | Quoting ObiKen: Quote: Quoting proverbs311031:
Quote: disclosure: I've been in IT for over 25 years
long story short: when replacing the existing driver with older driver provided by iPatsa, my DVD-RW drive does not show as installed, even with all matching account permissions including TrustedInstaller when compared to existing build 18363 cdrom.sys driver, so there must be another "software hook or call being made".
Any suggestions on what I might be missing? Hmm, I tackled the problem differently, I started to work the problem from DVD profiler to the drive, not the other way round.
Initially, I ran Process Monitor tool and an API monitoring tool to check what happens when dvdpro.exe adds a DVD Disc ID in the database. I could see files in the VIDEO_TS directory were being read and some attributes such as filename, file size and date and times were also read. But all the read data was correct and matched the values found on the DVD.
I ran the same test on many DVDs over many versions of Windows (XPsp2, Win7sp1, Win10v1709, Win10v1809, v1903, v1909) and found no evidence of corrupted data read from the DVDs.
Eventually, I did more research on the 64-bit CRC and found Microsoft's US patent which descibed the concept of the unique 64-bit CRC and how it could support bookmarking. I learnt that there were four steps in the calculation process:
Step 1: The filenames in the VIDEO_TS directory are collected and sorted alphabetically into a list
Step 2: For each filename in the list, the following structure is filled out and added to the CRC (all data fields are in LSB first): ==> unsigned 64 bit Integer: dateTime (the time elapsed in 100 nanosecond intervals from Jan. 1, 1601) ==> unsigned 32 bit Integer: FileSize ==> BYTE: Filename [filename Length] ==> BYTE: FilenameTermNull=0
Step 3: If present, the first 65,536 bytes of "VIDEO_TS.IFO are read and added to the CRC (if smaller then the entire file is added)
Step 4: If present, the first 65,536 bytes of "VTS_01_0.IFO are read and added to the CRC (if smaller then the entire file is added)
In a nutshell, each file's attributes in the VIDEO_TS directory and the first 65,536 bytes of data from VIDEO_TS.IFO and VTS_01_0.IFO are the inputs added to the concatenated binary polynomial equation that generates the 64-bit CRC.
With the above steps in mind, I revisited the previous capture files I had and it finally dawned on me something did change with Win10 ver1809.
On every Windows platform, steps 2,3 and 4 were being carried out properly. On the other hand, step 1 had changed: ==> Prior to Win10 ver1809, step 1 was being carried out properly. ==> From Win10 ver 1809 and onwards, only a subset of files in the VIDEO_TS directory were being read (VIDEO_TS.IFO, BUP and VOB, and VTS_01_0.IFO, BUP and VOB).
I can't give you a reason as to why the algorithm for calculating the DVD's unique 64-bit CRC changed, but I do note that both Microsoft's Windows Media Center application and Windows DVD Player application were both forcibly removed by the Win10 ver1809 upgrade, and both used the bookmarking feature via the DVD's unique 64-bit CRC!
Was the change just collateral damage? I'll leave that to someone else to take up the gauntlet. All I know is I finally convinced myself that CDROM.SYS was not the problem. Thanks for all the analysis. This helped to code a C# version of the algorithm: Quote:
using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Text;
internal static class Program { public static void Main() { Console.WriteLine("Good way:"); string eGood = DiscIdCalculator.Calculate("E:"); Console.WriteLine(eGood); Console.WriteLine("Bad way:"); string eBad = DiscIdCalculator.CalculateForWin10_1809_AndHigher("E"); Console.WriteLine(eBad);
Console.WriteLine("Good way:"); string fGood = DiscIdCalculator.Calculate(@"F:\"); Console.WriteLine(fGood); Console.WriteLine("Bad way:"); string fBad = DiscIdCalculator.CalculateForWin10_1809_AndHigher("F:\\"); Console.WriteLine(fBad);
Console.ReadLine(); } }
/// <summary> /// Based on US patent US 6,871,012 B1 /// http://patentimages.storage.googleapis.com/pdfs/US6871012.pdf /// </summary> public static class DiscIdCalculator { private const int MaxReadOutLength = 65_536;
private const string VideoFolder = "VIDEO_TS";
private static readonly DateTime _baseDate = new DateTime(1601, 1, 1);
public static string Calculate(string driveLetter) { DriveInfo drive = GetDrive(driveLetter);
//Step 1: //The filenames of the VIDEO_TS directory are collected and sorted alphabetically IEnumerable<string> fileNames = Directory.GetFiles(Path.Combine(drive.Name, VideoFolder), "*.*", SearchOption.TopDirectoryOnly);
string result = Calculate(drive, fileNames);
return result; }
/// <summary> /// Since Windows 10 version 1809 the calculation algorithm has changed which leads to different (i.e. faulty) disc Ids. /// This method exists to reproduce the faulty results. /// </summary> public static string CalculateForWin10_1809_AndHigher(string driveLetter) { DriveInfo drive = GetDrive(driveLetter);
//Step 1: //The filenames of the VIDEO_TS directory are collected and sorted alphabetically, but only VIDEO_TS.* and VTS_01_0.* IEnumerable<string> fileNames = Directory.GetFiles(Path.Combine(drive.Name, VideoFolder), "VIDEO_TS.*", SearchOption.TopDirectoryOnly) .Concat(Directory.GetFiles(Path.Combine(drive.Name, VideoFolder), "VTS_01_0.*", SearchOption.TopDirectoryOnly));
string result = Calculate(drive, fileNames);
return result; }
private static DriveInfo GetDrive(string driveLetter) { if (string.IsNullOrEmpty(driveLetter)) { throw new ArgumentException(nameof(driveLetter)); }
DriveInfo drive = new DriveInfo(driveLetter);
if (!drive.IsReady) { throw new ArgumentException("Drive is not ready!", nameof(driveLetter)); }
return drive; }
private static string Calculate(DriveInfo drive, IEnumerable<string> fileNames) { List<FileInfo> files = fileNames.Select(fileName => new FileInfo(fileName)).ToList();
string result = Calculate(drive, files);
return result; }
private static string Calculate(DriveInfo drive, List<FileInfo> files) { files.Sort(CompareFiles);
List<byte[]> hashes = new List<byte[]>();
//Step 2: //The file headers from each file are computed in the CRC. foreach (FileInfo file in files) { AddFileMetaHash(file, hashes); }
//Step 3: //The data from the VMGI file ("VIDEO_TS\VIDEO_TS.IFO") is computed in the CRC. //If present, the first 65,536 bytes of "VIDEO_TS.IFO are read and added to the CRC (if smaller then the entire file is added) AddFileContentHash(drive, "VIDEO_TS.IFO", hashes);
//Note: On page 19 the patents talks about "the first VTSI file ("VIDEO_TS\VTS_xx_0.IFO")" but on page 20, it explicitly specifies "VTS_01_0.IFO". //Step 4: //The data from the first VTSI file ("VIDEO_TS\VTS_xx_0.IFO") is computed in the CRC. string vtsFileName = GetVtsFileName(drive); //If present, the first 65,536 bytes of "VTS_01_0.IFO" are read and added to the CRC (if smaller then the entire file is added) AddFileContentHash(drive, vtsFileName, hashes);
byte[] hashBytes = hashes.SelectMany(bytes => bytes).ToArray();
ulong hash = Crc64.Calculate(hashBytes);
string result = hash.ToString("X");
return result; }
private static int CompareFiles(FileInfo left, FileInfo right) { int compare = left.Name.ToUpper().CompareTo(right.Name.ToUpper());
return compare; }
private static void AddFileMetaHash(FileInfo file, List<byte[]> hashes) { //For each filename in the list, the following structure is filled out and added to the CRC (all data fields are in LSB first): //- Unsigned 64 bit integer: dateTime(the time elapsed in 100 nanosecond intervals from Jan. 1, 1601) //- unsigned 32 bit integer: dWFileSiZe //- BYTE bFilename[filename Length] //- BYTE bFilenameTermNull = 0
TimeSpan diff = file.CreationTimeUtc - _baseDate;
//unsigned 64 bit Integer: dateTime (the time elapsed in 100 nanosecond intervals from Jan. 1, 1601) ulong hundredNanoSeconds = (ulong)(diff.TotalMilliseconds * 10_000);
byte[] nanoSecondBytes = BitConverter.GetBytes(hundredNanoSeconds);
//unsigned 32 bit Integer: FileSize uint fileSize = (uint)file.Length;
byte[] fileSizeBytes = BitConverter.GetBytes(fileSize);
//BYTE: Filename [filename Length] byte[] nameBytes = Encoding.UTF8.GetBytes(file.Name.ToUpper());
//all data fields are in LSB first if (!BitConverter.IsLittleEndian) { Array.Reverse(nanoSecondBytes); Array.Reverse(fileSizeBytes); Array.Reverse(nameBytes); //untested, if Encoding.UTF8.GetBytes() also needs to be reversed on a BigEndian system }
List<byte[]> fileHashes = new List<byte[]>() { nanoSecondBytes, fileSizeBytes, nameBytes, new byte[] { 0 }, //BYTE: FilenameTermNull=0 };
byte[] fileHash = fileHashes.SelectMany(bytes => bytes).ToArray();
hashes.Add(fileHash); }
private static void AddFileContentHash(DriveInfo drive, string fileName, List<byte[]> hashes) { FileInfo file = new FileInfo(Path.Combine(Path.Combine(drive.Name, VideoFolder), fileName));
//If present if (file.Exists) { using (FileStream fs = new FileStream(file.FullName, FileMode.Open, FileAccess.Read, FileShare.Read)) { using (BinaryReader br = new BinaryReader(fs)) { //the first 65,536 bytes read and added to the CRC (if smaller then the entire file is added) int bytesToRead = file.Length >= MaxReadOutLength ? MaxReadOutLength : (int)file.Length;
byte[] content = br.ReadBytes(bytesToRead);
hashes.Add(content); } } } }
private static string GetVtsFileName(DriveInfo drive) { IEnumerable<string> fileNames = Directory.GetFiles(Path.Combine(drive.Name, VideoFolder), "VTS_*_0.IFO", SearchOption.TopDirectoryOnly);
List<FileInfo> files = fileNames.Select(fileName => new FileInfo(fileName)).ToList();
files.Sort(CompareFiles);
string result = files.FirstOrDefault().Name ?? "VTS_01_0.IFO";
return result; }
private static class Crc64 { /// <summary> /// source: https://github.com/rdp/dvdid/blob/master/0.2.0a/dvdid-0.2.0a/src/libdvdid/crc64_table.c /// </summary> private static readonly ulong[] _crc64Table = { 0x0000_0000_0000_0000, 0x0809_E8A2_9694_51E9, 0x1013_D145_2D28_A3D2, 0x181A_39E7_BBBC_F23B, 0x2027_A28A_5A51_47A4, 0x282E_4A28_CCC5_164D, 0x3034_73CF_7779_E476, 0x383D_9B6D_E1ED_B59F, 0x404F_4514_B4A2_8F48, 0x4846_ADB6_2236_DEA1, 0x505C_9451_998A_2C9A, 0x5855_7CF3_0F1E_7D73, 0x6068_E79E_EEF3_C8EC, 0x6861_0F3C_7867_9905, 0x707B_36DB_C3DB_6B3E, 0x7872_DE79_554F_3AD7, 0x809E_8A29_6945_1E90, 0x8897_628B_FFD1_4F79, 0x908D_5B6C_446D_BD42, 0x9884_B3CE_D2F9_ECAB, 0xA0B9_28A3_3314_5934, 0xA8B0_C001_A580_08DD, 0xB0AA_F9E6_1E3C_FAE6, 0xB8A3_1144_88A8_AB0F, 0xC0D1_CF3D_DDE7_91D8, 0xC8D8_279F_4B73_C031, 0xD0C2_1E78_F0CF_320A, 0xD8CB_F6DA_665B_63E3, 0xE0F6_6DB7_87B6_D67C, 0xE8FF_8515_1122_8795, 0xF0E5_BCF2_AA9E_75AE, 0xF8EC_5450_3C0A_2447, 0x24B1_9099_74C8_4E69, 0x2CB8_783B_E25C_1F80, 0x34A2_41DC_59E0_EDBB, 0x3CAB_A97E_CF74_BC52, 0x0496_3213_2E99_09CD, 0x0C9F_DAB1_B80D_5824, 0x1485_E356_03B1_AA1F, 0x1C8C_0BF4_9525_FBF6, 0x64FE_D58D_C06A_C121, 0x6CF7_3D2F_56FE_90C8, 0x74ED_04C8_ED42_62F3, 0x7CE4_EC6A_7BD6_331A, 0x44D9_7707_9A3B_8685, 0x4CD0_9FA5_0CAF_D76C, 0x54CA_A642_B713_2557, 0x5CC3_4EE0_2187_74BE, 0xA42F_1AB0_1D8D_50F9, 0xAC26_F212_8B19_0110, 0xB43C_CBF5_30A5_F32B, 0xBC35_2357_A631_A2C2, 0x8408_B83A_47DC_175D, 0x8C01_5098_D148_46B4, 0x941B_697F_6AF4_B48F, 0x9C12_81DD_FC60_E566, 0xE460_5FA4_A92F_DFB1, 0xEC69_B706_3FBB_8E58, 0xF473_8EE1_8407_7C63, 0xFC7A_6643_1293_2D8A, 0xC447_FD2E_F37E_9815, 0xCC4E_158C_65EA_C9FC, 0xD454_2C6B_DE56_3BC7, 0xDC5D_C4C9_48C2_6A2E, 0x4963_2132_E990_9CD2, 0x416A_C990_7F04_CD3B, 0x5970_F077_C4B8_3F00, 0x5179_18D5_522C_6EE9, 0x6944_83B8_B3C1_DB76, 0x614D_6B1A_2555_8A9F, 0x7957_52FD_9EE9_78A4, 0x715E_BA5F_087D_294D, 0x092C_6426_5D32_139A, 0x0125_8C84_CBA6_4273, 0x193F_B563_701A_B048, 0x1136_5DC1_E68E_E1A1, 0x290B_C6AC_0763_543E, 0x2102_2E0E_91F7_05D7, 0x3918_17E9_2A4B_F7EC, 0x3111_FF4B_BCDF_A605, 0xC9FD_AB1B_80D5_8242, 0xC1F4_43B9_1641_D3AB, 0xD9EE_7A5E_ADFD_2190, 0xD1E7_92FC_3B69_7079, 0xE9DA_0991_DA84_C5E6, 0xE1D3_E133_4C10_940F, 0xF9C9_D8D4_F7AC_6634, 0xF1C0_3076_6138_37DD, 0x89B2_EE0F_3477_0D0A, 0x81BB_06AD_A2E3_5CE3, 0x99A1_3F4A_195F_AED8, 0x91A8_D7E8_8FCB_FF31, 0xA995_4C85_6E26_4AAE, 0xA19C_A427_F8B2_1B47, 0xB986_9DC0_430E_E97C, 0xB18F_7562_D59A_B895, 0x6DD2_B1AB_9D58_D2BB, 0x65DB_5909_0BCC_8352, 0x7DC1_60EE_B070_7169, 0x75C8_884C_26E4_2080, 0x4DF5_1321_C709_951F, 0x45FC_FB83_519D_C4F6, 0x5DE6_C264_EA21_36CD, 0x55EF_2AC6_7CB5_6724, 0x2D9D_F4BF_29FA_5DF3, 0x2594_1C1D_BF6E_0C1A, 0x3D8E_25FA_04D2_FE21, 0x3587_CD58_9246_AFC8, 0x0DBA_5635_73AB_1A57, 0x05B3_BE97_E53F_4BBE, 0x1DA9_8770_5E83_B985, 0x15A0_6FD2_C817_E86C, 0xED4C_3B82_F41D_CC2B, 0xE545_D320_6289_9DC2, 0xFD5F_EAC7_D935_6FF9, 0xF556_0265_4FA1_3E10, 0xCD6B_9908_AE4C_8B8F, 0xC562_71AA_38D8_DA66, 0xDD78_484D_8364_285D, 0xD571_A0EF_15F0_79B4, 0xAD03_7E96_40BF_4363, 0xA50A_9634_D62B_128A, 0xBD10_AFD3_6D97_E0B1, 0xB519_4771_FB03_B158, 0x8D24_DC1C_1AEE_04C7, 0x852D_34BE_8C7A_552E, 0x9D37_0D59_37C6_A715, 0x953E_E5FB_A152_F6FC, 0x92C6_4265_D321_39A4, 0x9ACF_AAC7_45B5_684D, 0x82D5_9320_FE09_9A76, 0x8ADC_7B82_689D_CB9F, 0xB2E1_E0EF_8970_7E00, 0xBAE8_084D_1FE4_2FE9, 0xA2F2_31AA_A458_DDD2, 0xAAFB_D908_32CC_8C3B, 0xD289_0771_6783_B6EC, 0xDA80_EFD3_F117_E705, 0xC29A_D634_4AAB_153E, 0xCA93_3E96_DC3F_44D7, 0xF2AE_A5FB_3DD2_F148, 0xFAA7_4D59_AB46_A0A1, 0xE2BD_74BE_10FA_529A, 0xEAB4_9C1C_866E_0373, 0x1258_C84C_BA64_2734, 0x1A51_20EE_2CF0_76DD, 0x024B_1909_974C_84E6, 0x0A42_F1AB_01D8_D50F, 0x327F_6AC6_E035_6090, 0x3A76_8264_76A1_3179, 0x226C_BB83_CD1D_C342, 0x2A65_5321_5B89_92AB, 0x5217_8D58_0EC6_A87C, 0x5A1E_65FA_9852_F995, 0x4204_5C1D_23EE_0BAE, 0x4A0D_B4BF_B57A_5A47, 0x7230_2FD2_5497_EFD8, 0x7A39_C770_C203_BE31, 0x6223_FE97_79BF_4C0A, 0x6A2A_1635_EF2B_1DE3, 0xB677_D2FC_A7E9_77CD, 0xBE7E_3A5E_317D_2624, 0xA664_03B9_8AC1_D41F, 0xAE6D_EB1B_1C55_85F6, 0x9650_7076_FDB8_3069, 0x9E59_98D4_6B2C_6180, 0x8643_A133_D090_93BB, 0x8E4A_4991_4604_C252, 0xF638_97E8_134B_F885, 0xFE31_7F4A_85DF_A96C, 0xE62B_46AD_3E63_5B57, 0xEE22_AE0F_A8F7_0ABE, 0xD61F_3562_491A_BF21, 0xDE16_DDC0_DF8E_EEC8, 0xC60C_E427_6432_1CF3, 0xCE05_0C85_F2A6_4D1A, 0x36E9_58D5_CEAC_695D, 0x3EE0_B077_5838_38B4, 0x26FA_8990_E384_CA8F, 0x2EF3_6132_7510_9B66, 0x16CE_FA5F_94FD_2EF9, 0x1EC7_12FD_0269_7F10, 0x06DD_2B1A_B9D5_8D2B, 0x0ED4_C3B8_2F41_DCC2, 0x76A6_1DC1_7A0E_E615, 0x7EAF_F563_EC9A_B7FC, 0x66B5_CC84_5726_45C7, 0x6EBC_2426_C1B2_142E, 0x5681_BF4B_205F_A1B1, 0x5E88_57E9_B6CB_F058, 0x4692_6E0E_0D77_0263, 0x4E9B_86AC_9BE3_538A, 0xDBA5_6357_3AB1_A576, 0xD3AC_8BF5_AC25_F49F, 0xCBB6_B212_1799_06A4, 0xC3BF_5AB0_810D_574D, 0xFB82_C1DD_60E0_E2D2, 0xF38B_297F_F674_B33B, 0xEB91_1098_4DC8_4100, 0xE398_F83A_DB5C_10E9, 0x9BEA_2643_8E13_2A3E, 0x93E3_CEE1_1887_7BD7, 0x8BF9_F706_A33B_89EC, 0x83F0_1FA4_35AF_D805, 0xBBCD_84C9_D442_6D9A, 0xB3C4_6C6B_42D6_3C73, 0xABDE_558C_F96A_CE48, 0xA3D7_BD2E_6FFE_9FA1, 0x5B3B_E97E_53F4_BBE6, 0x5332_01DC_C560_EA0F, 0x4B28_383B_7EDC_1834, 0x4321_D099_E848_49DD, 0x7B1C_4BF4_09A5_FC42, 0x7315_A356_9F31_ADAB, 0x6B0F_9AB1_248D_5F90, 0x6306_7213_B219_0E79, 0x1B74_AC6A_E756_34AE, 0x137D_44C8_71C2_6547, 0x0B67_7D2F_CA7E_977C, 0x036E_958D_5CEA_C695, 0x3B53_0EE0_BD07_730A, 0x335A_E642_2B93_22E3, 0x2B40_DFA5_902F_D0D8, 0x2349_3707_06BB_8131, 0xFF14_F3CE_4E79_EB1F, 0xF71D_1B6C_D8ED_BAF6, 0xEF07_228B_6351_48CD, 0xE70E_CA29_F5C5_1924, 0xDF33_5144_1428_ACBB, 0xD73A_B9E6_82BC_FD52, 0xCF20_8001_3900_0F69, 0xC729_68A3_AF94_5E80, 0xBF5B_B6DA_FADB_6457, 0xB752_5E78_6C4F_35BE, 0xAF48_679F_D7F3_C785, 0xA741_8F3D_4167_966C, 0x9F7C_1450_A08A_23F3, 0x9775_FCF2_361E_721A, 0x8F6F_C515_8DA2_8021, 0x8766_2DB7_1B36_D1C8, 0x7F8A_79E7_273C_F58F, 0x7783_9145_B1A8_A466, 0x6F99_A8A2_0A14_565D, 0x6790_4000_9C80_07B4, 0x5FAD_DB6D_7D6D_B22B, 0x57A4_33CF_EBF9_E3C2, 0x4FBE_0A28_5045_11F9, 0x47B7_E28A_C6D1_4010, 0x3FC5_3CF3_939E_7AC7, 0x37CC_D451_050A_2B2E, 0x2FD6_EDB6_BEB6_D915, 0x27DF_0514_2822_88FC, 0x1FE2_9E79_C9CF_3D63, 0x17EB_76DB_5F5B_6C8A, 0x0FF1_4F3C_E4E7_9EB1, 0x07F8_A79E_7273_CF58, };
public static ulong Calculate(byte[] data) { ulong hash = 0xFFFF_FFFF_FFFF_FFFF;
for (int i = 0; i < data.Length; i++) { unchecked { hash = (hash >> 8) ^ _crc64Table[(data[i] ^ hash) & 0xFF]; } }
return hash; } } }
| | | Karsten DVD Collectors Online
| | | Last edited: by DJ Doena |
| Registered: October 22, 2015 | Reputation: | Posts: 275 |
| Posted: | | | | Karsten, that is fine work, indeed! | | | Last edited: by ObiKen |
| Registered: March 14, 2007 | Reputation: | Posts: 6,744 |
| Posted: | | | | I have attached the program code to the bug report here. To all: Please upvote the bug so that maybe MS solves it one day. | | | Karsten DVD Collectors Online
|
| Registered: May 2, 2009 | Reputation: | Posts: 490 |
| Posted: | | | | Thanks!
I'm not sure how you "upvote" though. There's no "button" to click to upvote. Do you write a comment and send?
Anyway, that's what I ended up doing. |
| Registered: March 14, 2007 | Reputation: | Posts: 6,744 |
| Posted: | | | | Quoting MikaLove: Quote: I'm not sure how you "upvote" though. You probably did it when I first filed the issue. | | | Karsten DVD Collectors Online
| | | Last edited: by DJ Doena |
| Registered: May 2, 2009 | Reputation: | Posts: 490 |
| Posted: | | | | I have no recollection of doing that, nor even using this hub.
However I see that for "Problems" I can only "add similar feedback", and for "Suggestions" I can upvote (or "agree" translated from Swedish). |
|
|