DiscImageCreator

[user7]

Possible to have dic dump with both write offsets automatically in these instances? So it can be manually combined later.

[F1ReB4LL]

Possible to have dic dump with both write offsets automatically in these instances? So it can be manually combined later.

Maybe to make 2 sets of tracks in this case? Like, "dump" and "dump (fixed)"? Similar to "dump (Subs indexes)"? For the discs with both this bug and TOC/Sub desync it would mean 4 sets of tracks, though: "dump", "dump (Subs indexes)", "dump (fixed)" and "dump (Subs indexes) (fixed)".

There are other similar cases that need manual fixing to make the images usable, like https://redump.info/disc/39378/ or https://redump.info/disc/34036/

There are also many cases where only a couple of the last sectors are affected - like https://redump.info/disc/24202/

[iR0b0t]

3. pad all 0 bytes and put in LBA 949.
    or cut the excessive 120 bytes of LBA 949.

If i understood it right, this method is technically alternating the dump.
If this is true, i don't see these dumps as good once, except we use 2 sets of tracks as F1ReB4LL suggested.

[iR0b0t]

All those mastering errors are very nasty, probably would be better to leave those dumps scrambled,
beginning from the sector with anomalies.

If the anomaly starts in the pregap of the first track, then leave the entire disc scrambled.
We do not dump the first pregap, but since it belongs to the first track and is basically part of it, thats where the initial disc offset starts and should be kept.

This is my opinion, we can talk about it of course

Maybe to make 2 sets of tracks in this case? Like, "dump" and "dump (fixed)"? Similar to "dump (Subs indexes)"? For the discs with both this bug and TOC/Sub desync it would mean 4 sets of tracks, though: "dump", "dump (Subs indexes)", "dump (fixed)" and "dump (Subs indexes) (fixed)".

Yeah.

[sarami]

Silpheed (Sample) lefts 68255 sectors scrambled as far as I see the comments. Then, some CD-i (and FMT) discs should be so?

[iR0b0t]

Silpheed (Sample) lefts 68255 sectors scrambled as far as I see the comments. Then, some CD-i (and FMT) discs should be so?

I would say YES.

[DopefishJustin]

I'm getting an issue with several doujin PC games on CD-R media where there are C2 errors on the final two sectors and DIC will not complete the dump. From discussion on Discord it sounds like this is a common occurrence with CD-R discs and is most likely a mastering issue and not due to disc damage. But I can't see any way to make DIC ignore the errors and complete the dump.

Logs for two discs with the issue: http://interbutt.com/misc/CD-R%20problem%20logs.zip

[sarami]

I can't see any way to make DIC ignore the errors and complete the dump.

Execute without /c2.

[F1ReB4LL]

Silpheed (Sample) lefts 68255 sectors scrambled as far as I see the comments. Then, some CD-i (and FMT) discs should be so?

Silpheed was dumped with DIC, so it should already handle such discs properly (unless you've changed something recently), but it should probably additionally create a fixed image and we should probably add the fixed images somehow (maybe as yellow dumps?).

[sarami]

but it should probably additionally create a fixed image and we should probably add the fixed images somehow

I agree for your thought.

"dump" and "dump (fixed)"?

Is it "dump.scm" and "dump (fixed).scm" and "dump.img" and "dump (fixed).img" ?

This is a list to support.

Code: Select all

disc     | non fixed image | fixed image
---------+-----------------+------------
Silpheed | yes             | no
---------+-----------------+------------
Video CD |                 |
Music    | yes             | no
Sampler  |                 |
---------+-----------------+------------
FMT      | no              | yes
---------+-----------------+------------
CD-i     | yes             | no
----------------------------------------

Anyway, I'll get someday these mastering error discs to create the "dump" and "dump (fixed)" automatically...

@user7
Tell me the ebay or amazon or discogs link of "HighlightsVCD", please.