DiscImageCreator

[sarami]

There is no extension

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

[RibShark]

There is no extension

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

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

Code: Select all

# 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

[sarami]

but .010 and .011 files are still skipped

(link is same)
- fixed: check string length

[RibShark]

but .010 and .011 files are still skipped

(link is same)
- fixed: check string length

Thanks, working now!

[RibShark]

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

[sarami]

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

[Intothisworld]

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 Thank you for your time.

[RibShark]

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

[Jackal]

FYI, the supposed +30 reference offset that was discovered and announced by 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.

[Intothisworld]

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.