DiscImageCreator (Page 125 of 141)

I only support the latest version. It's now 20211001T112852.

I downloaded the newest DIC version from the website and the problem is still there. I did 2 dumps of clean GameShark 2 disc and I'm getting different results (4476 vs 4477) errors.
Let me know if logs would be useful, I'll upload them.

I have a LaserLock Marathon disc with the protected file named "SNGM" in a directory called "SNGM" alongside two other files ("SNGM.010" and "SNGM.011") that do not have read errors. Adding "SNGM" to ReadErrorProtect.txt causes DIC to ignore all three files and sector 18 where the directory is defined. Is there a way to better define which file to skip so it only skips "/SNGM/SNGM"?

No, this is for Fair Strike which already has an entry in the DB but I want to verify. Other LaserLock Marathon games use different files.

(sidenote: I am fairly confident that all games in the DB with "LaserLock Star" protection ate actually Marathon, the timings match much better to when Marathon was released.)

There is no extension

Too many files are being skipped:

Directory structure:

I need to skip the "SNGM" file, but *not* the "SNGM.010" and "SNGM.011" files.

ReadErrorProtect.txt is

# This is a file not to read sector. Please write the file name you want to read skipping
SYSTEM.LSK
SNGM

but .010 and .011 files are still skipped

Thanks, working now!

https://github.com/saramibreak/DiscImag … g/20211101
*2021-11-01
- fixed: ReadErrorProtect

We correct by using the data track offset which can be easily determined by the sync, so adjusting for the "correct" offset would not affect any dumps, just the stated write offset.

As for that post, IIRC they did not present any compelling proof of their offset being any more correct besides "some guy in the industry said so", which is not good enough for me especially as said guy was basing his findings off the data track offset, which we know can vary depending on the disc.

This is good to hear. That saves me a lot of concern. What had me worried though, wasn't so much the potential lost data in the lead-in and lead-out (which I know does happen but is uncommon, and when it does is fairly easy to detect), but the alignment of the transitions between tracks. Those types of discrepancies seem like they would be much harder to detect, but slightly more significant to the integrity of the album itself. But I'm glad to hear that his claims were disputed. Sticking to the established AR convention seems like a sound route to me. : )

I do have a couple further questions, and a related request, if it's not too much trouble. The first question is in regards to pressing offsets. I know Nova already spoke to you a little bit about some of my questions there, Jackal, and I was pretty relieved by your response tbh. Cleared up a misunderstanding I had and put a big question to rest, thankfully. But I'm still wondering about one aspect of it. From what I understand, the table of contents at the beginning of an audio CD lays out all the LBAs (or timestamps?) for tracks throughout the disc. So when a disc has an offset pressing, say shifted +88 from another similar release, are the LBAs/timestamps in the TOC shifted by +88 as well?

And the second question is in regards to data potentially being shifted into the lead-in or lead-out... Would it be possible to add a feature to DIC where it automatically searches the lead-in/lead-out for non-zero bytes? And then if necessary adjusts accordingly (or at least tells you how to manually adjust accordingly)? Is there any technical limitation to something like that? If it is indeed possible, I'll go ahead and submit a request on the github, but if not, I don't want to waste anyone's time. Thanks again.

I have been doing some thinking and I believe that the "0" offset we currently have is likely correct. "0" is the most common write offset for CDs in the DB, and two of the listed common offsets in the new disc form are +588 and +1176, equal to exactly one half of, and one sector respectively. Should the true "0" offset be +30 or +48, these common offsets would be +558/+540 and +1146/+1130 instead which seems to be less logical than them being divisors of a full sector.

I thought so too, but:
http://redump.org/discs/offset/-12 - "Displaying results 1 - 500 of 1679"
http://redump.org/discs/offset/0 - "Displaying results 1 - 500 of 2584"