DiscImageCreator
DiscImageCreator copied to clipboard
saramibreak
[F:ConvertScmToBin][L:2432] GetLastError: 2, The system cannot find the file specified.
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.
What file is it looking for?
Failed to generate "(Track 1)(-LBA).scm & .sub".
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?
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.
@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.
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?
@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.
@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.
Was this ever resolved? I am today using the newest version and I still get tons of these errors.
Every _mainError.txt file now always show
Failed to read. readsize=2232, total_read=20805792/20808024 [F:ConvertScmToBin][L:3490]
Failed to read. readsize=2232, total_read=20805792/20808024 [F:ConvertScmToBin][L:3490]
Failed to read. readsize=2232, total_read=20805792/20808024 [F:ConvertScmToBin][L:3490]
Failed to read. readsize=2232, total_read=20805792/20808024 [F:ConvertScmToBin][L:3490]
Failed to read. readsize=2232, total_read=20805792/20808024 [F:ConvertScmToBin][L:3490]
even the main _20240601T211847 file shows this (which is also a bug)
cd D Disc01.bin 16 /d8 /c2 400 /q [F:ConvertScmToBin][L:2854] GetLastError: 2, The system cannot find the file specified.
[F:ConvertScmToBin][L:2854] GetLastError: 2, The system cannot find the file specified.
[F:ConvertScmToBin][L:2854] GetLastError: 2, The system cannot find the file specified.
[F:ConvertScmToBin][L:2854] GetLastError: 2, The system cannot find the file specified.
[F:ConvertScmToBin][L:2854] GetLastError: 2, The system cannot find the file specified.
Will this ever be adressed?
This was a standard Windows Server 2003 disc which dumps otherwise fine, I have checked the contents with an older MDF dump of the same disc and it all matches, yet it spits out these errors on every new CD I dump from now on. It should not spit out a critical error if there are none, and I use the mainError files to determine if there's an issue with the dump or not, which is impossible now since every dump spits these out regardless if the dump itself is fine or not.
From what I understand in the documentation my drive is on the recommended list and should be able to dump the AA and -1 files, so what's the issue here then if it occurs with every dump?
For reference my entire dump log for this title has been included. dump_log.txt
Thanks for the quick reply!
Tried this version, it still errors out and writes it out to the mainError file.
Is this really a critical error? Or should I just ignore it?
I re-dumped two of my older discs and they worked without any errors, but now it did start again with some other re-dumps. The end img file still works properly and is identical to previous dumps, so how critical are these? Any way to skip dumping them?
Or if it's a matter or retries, will increasing the retries make any difference? It stops in the same place every retry. In every instance where there's an error it always stops at -1154 and then retries.
When read the lead-in area, AMSF is counted up like this. test (Track 0)_subReadable.txt
But AMSF of your disc is not counted up correctly. Disc03 (Track 0)_subReadable.txt
As a result, app can't read LBA (-150 ... -1) of the track 1 and can't dump the pregap of the track 1, but other sectors (0 ... 313313) can be reading accurately. If you don't preserve the pregap of the track 1, there's no need to worry about this problem.
But this happens to basically every disc I dump. I've dumped around 60 games now and about 40 MS discs, most of them has the exact same issue.
Is there a way to fix this? Or even a flag to skip reading this to avoid getting the constant errors (and slowdowns when it retries 5 times)?
This is somewhat related to https://github.com/saramibreak/DiscImageCreator/issues/281, no? Those issues only happen to me when using a Plextor drive and only after DIC started to read those tracks (AA, -LBA) like redumper does. Are you using a Plextor @mrpijey? @saramibreak are those tracks relevant in any way? Shouldn't there be an option to dump them, otherwise just dump the regular sectors like previous versions of DIC did?
I can dump the pregap sector of the track 1 using Plextor PX-760A. I don't know why malvarenga123 and mrpijey can't read these sectors. If there is a possibility, the cables connected to the drive might be affected in some way.
are those tracks relevant in any way? Shouldn't there be an option to dump them, otherwise just dump the regular sectors like previous versions of DIC did?
Some discs have meaningful data in those sectors. I am convinced that dumping those sectors is important for preservation.
If it were cabling there would have been other issues with dumps, and apart from this particular issue there are none.
And I agree, it is important for preservation, which is why I hope for some kind of solution or explanation of why I can't dump these. At least it doesn't affect the actual data, but it would have been nice with some options perhaps to skip the dumping of these? Or an option to add more retries (default is 5 retries) to try to force the drive to read it? As I've mentioned, some discs actually succeed in dumping this, so it's not a problem with every disc.
Well, I've done some more dumping, almost every disc gives me the exact same error now. Out of perhaps 100 discs only 1 or 2 actually continued properly past this point, so I don't know what's special about those discs. And I have no other issues with this drive either, it dumps stuff perfectly fine.
Checking Pregap sync, msf, mode (LBA) -7926
Reading DirectoryRecord 1/ 1
Checking SubQ adr (Track) 1/ 1
Creating (Track AA).scm & .sub (LBA) 10226/ 10226
Creating (Track 0).scm & .sub, (Track 1)(-LBA).scm & .sub (LBA) -1154/ -10000
Failed to get (Track 1)(-LBA)
Retry 1/5
Creating (Track AA).scm & .sub (LBA) 10226/ 10226
Creating (Track 0).scm & .sub, (Track 1)(-LBA).scm & .sub (LBA) -1154/ -10000
Failed to get (Track 1)(-LBA)
Retry 2/5
Creating (Track AA).scm & .sub (LBA) 10226/ 10226
Creating (Track 0).scm & .sub, (Track 1)(-LBA).scm & .sub (LBA) -1154/ -10000
Failed to get (Track 1)(-LBA)
Retry 3/5
Creating (Track AA).scm & .sub (LBA) 10226/ 10226
Creating (Track 0).scm & .sub, (Track 1)(-LBA).scm & .sub (LBA) -1154/ -10000
Failed to get (Track 1)(-LBA)
Retry 4/5
Creating (Track AA).scm & .sub (LBA) 10226/ 10226
Creating (Track 0).scm & .sub, (Track 1)(-LBA).scm & .sub (LBA) -1154/ -10000
Failed to get (Track 1)(-LBA)
Retry 5/5
Always on -1154/-10000. Always.
All other parts of the dump is just fine.
I've tried different options, different speeds, nothing changes. And unfortunately I don't have any other DIC-compatible drive for CD dumps to test on.
Please add an option to skip this part since while worthy of preservation it slows down the dumping and adds errors to the logs where there are none. Maybe one of the logs can note that this part was skipped during dumping or something. But it's very annoying now since it happens on every disc.
Thanks for all the help, but I have yet to understand why this happens or why it's necessary to force the dump of it.
Some discs have meaningful data in those sectors. I am convinced that dumping those sectors is important for preservation.
But those tracks are restricted to Plextor drives. The disc will be dumped without them with other drives without any indication that something is missing. This is exactly the case when I dumped a regular data CD without protection with both a Plextor Premium and a ASUS BW-16D1HT.
It' easy to add an option to skip but I want to know why mrpijey and malvarenga123 can't read pregap sectors of the track 1. I suspect the IDE-USB adapter. If not so, other installed programs controlling the drive may be interfering.
In my case it's an USB Plextor Premium. So the case is from Plextor itself. Also, like @mrpijey, some discs DO read those tracks without errors. Tracks AA and 0 are created, only (Track 1)(-LBA) gives an error. If I try with redumper, after a few retries trying to read the lead in, the drive starts doing some strange noises. Log: plextor.zip
I think this is probably the reason superg added the following options to redumper:
--plextor-skip-leadin skip dumping lead-in using negative range
--plextor-leadin-retries=VALUE maximum number of lead-in retries per session (default: 4)
In my case it's an USB Plextor Premium. So the case is from Plextor itself.
The only other thing I can think of is
- Other installed programs controlling the drive
- OS
- Motherboard
But how come the Asus log does not show any issues? And what about @mrpijey dumps with the same issue?
how come the Asus log does not show any issues?
This method is only used by plextor drive because non-plextor drive can't read lead-in area directly and 1st track pregap sectors can be read only 147 or so.
This method is only used by plextor drive because non-plextor drive can't read lead-in area directly
So are all dumps made with non-plextor drives incomplete? That would mean most of redump's database is incomplete (which we know it isn't the case), as DIC didn't start trying to read it until recently.
I still wonder what can you do with lead-in data. AFAIK, it can't be burned to a CD nor any software will make use of it. In fact, it's only adding extra stress on very old drives that will break down sooner than later. Is there any protection that requires it? If there is, then DIC should only read it in when dumping discs with that protection.
The solution, IMHO, would be to replace those error messages with what is actually happening: failure to read the disc's lead-in. An option to skip it altogether would be welcome as well.
The solution, IMHO, would be to replace those error messages with what is actually happening: failure to read the disc's lead-in.
malvarenga123 and mrpijey can be read disc's lead-in, which is Track 0 or 00. You are failing to rip pregap sectors of track 1. Pregap sectors of track 1 are not lead-in.
An option to skip it altogether would be welcome as well.
I understand that I should add an option for those not interested in ripping pregap sectors of track 1. Wait, plz.
You are failing to rip pregap sectors of track 1.
Ok, then that should be the error message.
disc's lead-in, which is Track 0 or 00
Isn't it better to name them Lead-in instead of Track 0/00/AA?