3,101

sarami wrote:

What is the problem? My unlicensed is no problem.

There are two problems:
When I use DIC supplied with MPF, Build 20210401T101950, if that helps, and dumping PS2 GameShark disc with /sf flag, after initial pass it tries to re-read some C2 sectors from BIG.DAT and as it never gets a match, dumping fails.
For other PS2 unlicensed I often get improper dumps with wrong error count, it deviates from 4475 errors count for such discs. All these discs are clean and I currently dump them using the earlier DIC version which always yields the exact 4475 errors. That version you built after I mentioned this earlier error count deviation and it always works for me.

3,102

superg wrote:

When I use DIC supplied with MPF, Build 20210401T101950

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

3,103

sarami wrote:
superg wrote:

When I use DIC supplied with MPF, Build 20210401T101950

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

I will use that.

3,104

sarami wrote:
superg wrote:

When I use DIC supplied with MPF, Build 20210401T101950

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.

Is there any desire to add support for accessing (Old Macintosh) HFS format discs? there are several open source projects that can show how it is done (hfsutils/C, HFSExplorer/Java).

It would make listing correct Contents much easier.

3,106

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"?

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,107

Does LaserLock Marathon always have "SNGM.010" and "SNGM.011"?

3,108

sarami wrote:

Does LaserLock Marathon always have "SNGM.010" and "SNGM.011"?

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

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,109

RibShark wrote:

Is there a way to better define which file to skip so it only skips "/SNGM/SNGM"?

Define only filename and extension.

3,110

sarami wrote:
RibShark wrote:

Is there a way to better define which file to skip so it only skips "/SNGM/SNGM"?

Define only filename and extension.

There is no extension

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,111

RibShark wrote:

There is no extension

https://www.mediafire.com/file/eq80y20l … st.7z/file
- fixed:
Only check files.

3,112

sarami wrote:
RibShark wrote:

There is no extension

https://www.mediafire.com/file/eq80y20l … st.7z/file
- fixed:
Only check files.

Too many files are being skipped:
https://i.postimg.cc/nLRkMgf5/image.png
Directory structure:
https://i.postimg.cc/YCSLj92r/image.png
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

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,113

RibShark wrote:

but .010 and .011 files are still skipped

(link is same)
- fixed: check string length

3,114

sarami wrote:
RibShark wrote:

but .010 and .011 files are still skipped

(link is same)
- fixed: check string length

Thanks, working now!

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,115 (edited by RibShark 2021-10-28 18:26:25)

The end of sector 0/the start of sector 1 when dumping both disc 1 and 2 of Fair Strike are filled with 0x55 when dumping on both ASUS and Plextor drives. Tools like ISOBuster are able to read those sectors fine, so something else is going wrong here.

Logs (later errors are the skipped file): https://rib.s-ul.eu/vsUmxVSe

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,116 (edited by sarami 2021-11-01 15:33:30)

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

3,117 (edited by Intothisworld 2021-11-05 05:31:46)

Hey there, I'm somewhat new to the community, but I have a question about audio CD drive offsets. I just discovered last night the old forum post where a guy called out EAC and AccurateRip for their drive offset references all being 30 samples off. I know this post made a pretty big splash in the field when it appeared back in 2006, so I'm assuming the DIC creators were aware of it... I'm just curious what the general opinion is of this info amongst the MPF/DIC tech crowd? I'm still very much a learner when it comes to all of this stuff, so beginner-friendly language would be very appreciated :P Thank you for your time.

3,118

Intothisworld wrote:

Hey there, I'm somewhat new to the community, but I have a question about audio CD drive offsets. I just discovered last night the old forum post where a guy called out EAC and AccurateRip for their drive offset references all being 30 samples off. I know this post made a pretty big splash in the field when it appeared back in 2006, so I'm assuming the DIC creators were aware of it... I'm just curious what the general opinion is of this info amongst the MPF/DIC tech crowd? I'm still very much a learner when it comes to all of this stuff, so beginner-friendly language would be very appreciated tongue Thank you for your time.

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.

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,119 (edited by Jackal 2021-11-05 10:16:47)

FYI, the supposed +30 reference offset that was discovered and announced by http://forum.redump.org/user/48/ was later disputed by his friend Truong (from Trurip). With his tests using an FPGA, he determined the true "zero" read offset to be +48 (used by Pioneer drives as read offset as opposed to the +30 used by Plextor) compared to EAC. When you look in Red Book there is a part somewhere which tells about 3 x 6 samples that could explain the 18 samples difference between the 2.

Anyway, it's all hearsay and irrelevant, because Redump uses combined offset correction whenever possible and for Audio CD's the EAC reference offset is the standard and used by databases like AccurareRip and CUETools that store checksums for many millions of discs. In the end it's just a number and if you only correct the read offset, regardless of the reference used, you can still end up with data being shifted into the pregap or lead-out that will be missing from the dump because the write offset isn't corrected.

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.

3,121 (edited by Jackal 2021-11-05 15:04:35)

Hello,

Intothisworld wrote:

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?

The TOC indeed tells you the length in LBA of each track. Offsets have no bearing here.

Intothisworld wrote:

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.

This should be possible and seems sensible in the cases where you want to capture non-zero bytes that would otherwise be lost. There are some discs already in the db that were dumped this way: http://redump.org/discs/quicksearch/off … /audio-cd/
So feel free to request such a feature and we will allow such dumps.

3,122

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.

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

3,123 (edited by Jackal 2021-11-06 00:51:38)

-12 seems way more common than 0, but otherwise you're right

3,124

Jackal wrote:

-12 seems way more common than 0, but otherwise you're right

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"

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

Thank you both for the replies and clarification.