DiscImageCreator

[Jackal]

Hello,

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.

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: https://redump.info/discs/quicksearch/off … /audio-cd/
So feel free to request such a feature and we will allow such dumps.

[RibShark]

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.

[Jackal]

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

[RibShark]

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

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

[Intothisworld]

Thank you both for the replies and clarification.

[NovaAurora]

We've been discussing how to handle Audio CDs with data in the lead-in/lead-out when dumped at the default offset of DIC (See: https://redump.info/disc/28088/), and would like to ask if it's possible to:

*Scan lead-in and lead-out for non-zero data
*Calculate required offset to include data
*Prompt user (Y/N) if they would like to offset correspondingly
or
*a flag for this option, which MPF can implement as a default flag for Audio CDs (With a warning when flag not present)

Please let us know how you feel about implementing this or if there are any issues with this method.

[sarami]

https://github.com/saramibreak/DiscImag … /issues/95
If non-zero byte exists in the 1st lead-out, fix the combined offset.
If non-zero byte exists in LBA -1, check only.

[Jackal]

Latest DIC still outputting incorrect multisession cuesheets? /viewtopic.php?t=35641 … intergame/

And DIC or MPF are always scanning the .img instead of the .bin files, resulting in an incorrect error count for multisession discs. The gap between the sessions should not be included in the error count, because it's not included in the .bin tracks.

[NovaAurora]

User was using outdated July version, latest DIC has a fixed cuesheet, but it is still scanning the .img instead of .bin as mentioned above.

[scsi_wuzzy]

I mentioned this in another thread, but it might be more of interest to those in this thread:

I believe the Vinpower variant of the WH16NS48 (SVC Code 40) firmware (version 1.D3) may potentially be a good firmware for scrambled dumping on SVC Code NS40 drives. (Drives that, AFAIK, generally can't run the BW-16D1HT firmware, because it's designed for drives with SVC Code NS50.) This is a firmware that is somewhat popular in the disc burning community, because, unlike other firmwares, it supports doing quality scans on BD, BD-R, and BD-RE discs. As a bonus, it looks like it also supports scrambled reads via 0xBE and supports 0xF1 for reading from the cache. DIC doesn't currently have the drive in the database of 0xF1 capable drives, but I did a build of DIC with this drive added to the 0xF1 capable list and was able to dump a 0 offset disc (one that requires /mr in order to fetch lead-out sectors), and the dump matched the dump I previously made with my BW-16D1HT drive.

Maybe this is common knowledge, but I thought I'd mention it, because I didn't see this firmware mentioned in the Wiki and DIC doesn't recognize it. In fact, DIC doesn't even know the offset (+6 samples), because the WH16NS48 isn't in the driveOffsets.txt.