[F:ConvertScmToBin][L:2432] GetLastError: 2, The system cannot find the file specified.

[mrpijey]

Please be sure to read through the entire README before reporting.

Version
32 bit, AnsiBuild, 20230909T161424

Describe the bug

During a dump of a CD this error pops up 5 times before it starts the actual dump:

Creating (Track AA).scm & .sub (LBA) 355698/ 355698
Creating (Track 0).scm & .sub, (Track 1)(-LBA).scm & .sub (LBA) -1154/ -10000
Failed to read. readsize=2256, total_read=20805792/20808048 [F:ConvertScmToBin][L:3067]
[F:ConvertScmToBin][L:2432] GetLastError: 2, The system cannot find the file specified.

What file is it looking for? (ConvertScmToBin?). I can't find any online references to this file, nor is it included with the files from the github release.

Previous releases had no extra files and I have not seen this error with previous releases.

[saramibreak]

What file is it looking for?

Failed to generate "(Track 1)(-LBA).scm & .sub".

[mrpijey]

It's not a title I chose to set, it's automatic. The filename output I chose was "Disc01". So I don't know why it tries to generate those files, it's default in the application.

It does however create the files on the drive, but I don't understand why it errors out. Some parsing issue?

[MrPepka]

Send all logs

[saramibreak]

The filename output I chose was "Disc01". So I don't know why it tries to generate those files, it's default in the application.

Yes, it failed to generate "Disc01 (Track 1)(-LBA).scm & Disc01 (Track 1)(-LBA).sub".
For the preservation purpose, from -150 to -1 LBA needs to read, but from -150 to -76 sometimes fails to read due to the cache reading from the drive.

[OldMadMan]

@mrpijey Well, the copy of DIC provided by BetaArchive's guide is an old version.

The developer has recently added a feature. By default, in addition to dumping the main part of the CD, DIC will also dump these three parts: Track 0, Track AA and Track 1(-LBA). I don't quite understand the purpose of these parts, But this seems to make the disc to be dumped more.... complete.

I've re-dumped hundreds of MSDN CDs and based on what I've encountered, dump these extra tracks (especially Track1 -LBA) doesn't always succeed, and like the developer said, this feature seems to rely on read data from the optical drive's cache, and even if the same disc be dumped multiple times, the data read from the cache is not exactly the same each time. And there is a certain probability of reading failure.

I have asked developers about similar issues before, and the answer I received so far is that there is no solution to completely solve the read error. Currently, read errors mostly occur on discs containing audio tracks (such as Windows HCT discs). However, because the Plextor optical drives used for reading are all very old, sometimes it is difficult to tell whether the problem is related to the aging laser head.

[mrpijey]

alright thank you. I know the BA copy is out of date, I was starting to dump more discs for the archive and wanted to get a new version of DIC for it and to update the BA copy when I encountered these errors and wondered why they occur.

But from what I understand these errors can be ignored then? They do show up in the logs, and the files are created on the drive, so I just wonder what the errors are really about. It looks like it tries to do something with files it can't find, so it's very unclear. Maybe the code should then include some check where it checks for the files before it tries to process them and not generate these errors.

I've had zero issues in the past with dumping CDs and DVDs with my plextor drive, so I wonder, can I safely ignore these errors? Or is it something I need to pay attention to?

[OldMadMan]

@mrpijey The following are some phenomena I noticed when using DIC to dump over 500 MSDN CDs (they may not be errors, but it has been difficult for me to judge due to my insufficient knowledge). These phenomena are ordered from high to low frequency of occurrence. The script I use is provided by BA.

No. 1: "No unintentional C2 errors" instead of "No C2 errors"
DIC determines whether the disc is copy-protected by detecting the exe file in the disc. According to my experience, as long as a Microsoft CD contains a large number of exe files (Windows NT etc.), there is about a 70% to 80% chance that DIC will report that it "found an unknown string" during the detection process, and as long as this report appears, at the end of the dump process, DIC will always report "No unintentional C2 errors" instead of "No C2 errors".
Since I don't understand how this works, my guess is that DIC believes that if it does not detect that a disc is copy-protected, but finds an "unknown string" during the detection process, then it is possible that this string is the manufacturer's Deliberately installed protection measures.
At present, I can only think that this prompt does not mean that there is an error in the captured data.

No. 2: "SecuROM 1st version (a.k.a. OLD)" detected
As mentioned above, DIC will detect whether the disc is copy protected. As soon as it finds the "unknown string", it immediately starts detecting the type of copy protection the disc has. For Microsoft discs, in most cases, the detection result is that no protection measures are detected, but in a few cases, DIC will detect that the disc is protected by "SecuROM 1st version (a.k.a. OLD)". I have doubts about this test result because many friends have told me that Microsoft's CDs are usually not copy-protected. I once asked the developer about this, and the answer I got was that if the SubQ channel (forgive me, I don't know what this is) returns an incorrect value during the reading process, DIC will think that the disc is protected by SecuROM.
At some point, using detergent to clean the disc surface, or slowing down the reading speed, may cause DIC to no longer report that SecuROM is detected when the disc is read again. But in other cases, DIC will always report. I think this situation may be related to whether the disc is clean to some extent. In the final analysis, I never dare to be 100% sure whether the disc is truly copy-protected. My only option was to purchase additional copies of the same disc to dump at a later date and keep the one of the two copies that had no copy protection detected.

No.3: "Failed to read [F:ConvertScmToBin][L:xxxx], System cannot find file"
As we mentioned above. At present, there seems to be no better way besides trying many times.

No.4: "ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE"
When DIC detects exe, there is a small probability that it will report that "LOGICAL BLOCK ADDRESS OUT OF RANGE" of a certain exe file. According to the developer, this problem may be caused by a problem with the master tape used by Microsoft to compress the disc, which incorrectly marked the "Location of Extent" and "Data Length" parameters of exe. It is said that this has no impact on the actual captured data, but I am somewhat worried.

[saramibreak]

@mrpijey

I've had zero issues in the past with dumping CDs and DVDs with my plextor drive, so I wonder, can I safely ignore these errors?

Yes, if you don't dump the Track1 -LBA.

Maybe the code should then include some check where it checks for the files before it tries to process them and not generate these errors.

I will consider it..

@OldMadMan

No. 1

Intentional C2 errors have SafeDisc. If /sf is used, "No unintentional C2 errors" is used.

No. 2

I will consider it to avoid false positives. (If possible)

No.4

Such error discs are rare but occasionally seen.