Redump Forum

pablogm123 wrote:====== Check SubP to W, OperationCode: 0xbe, Subcode: 1(=Raw) ======
Sub Channel LBA 0
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P ff ff ff ff ff ff ff ff ff ff ff ff
    Q 41 01 01 00 00 00 00 00 02 00 28 32
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 03
    T 00 00 00 00 00 00 00 00 00 00 00 02
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 02

====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x08(=Raw) ======
Sub Channel LBA 0
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P ff ff ff ff ff ff ff ff ff ff ff ff
    Q 41 01 01 00 00 00 00 00 02 00 28 32
    R 00 00 00 00 00 00 00 00 00 00 00 01
    S 00 00 00 00 00 00 00 00 00 00 00 03
    T 00 00 00 00 00 00 00 00 00 00 00 02
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 03
    W 00 00 00 00 00 00 00 00 00 00 00 00

I uploaded exe including this function.

I am wondering if this pattern could be predictable. And the reason of its existance: intentional, an accidental mastering artifact...?

I don't know this pattern in detail too...

And
To: axisleon
subject: DC ripping is very slow
Improved it. Please test.

Tested:

http://www.mediafire.com/?6w3noqvyw4glvit

/m      If MCN sector exists in the last sector of the track, use this
                For WonderMega Collection [Mega-CD]

On Mega CD and Saturn titles MCN is always in the last sector of the track. Only PCE titles have MCN in the first sector of the track. You should treat MCN sectors as the last sector of the track by default. And "/m" parameter should be for PCE discs, where "MCN sector exists in the first sector of the track".

F1ReB4LL wrote:

/m      If MCN sector exists in the last sector of the track, use this
                For WonderMega Collection [Mega-CD]

On Mega CD and Saturn titles MCN is always in the last sector of the track. Only PCE titles have MCN in the first sector of the track. You should treat MCN sectors as the last sector of the track by default. And "/m" parameter should be for PCE discs, where "MCN sector exists in the first sector of the track".

Indeed? Fixed it.

Sure:

https://redump.info/disc/30958/
https://redump.info/disc/32498/
https://redump.info/disc/32560/

These discs sometimes contain a MCN frame in certain audio tracks transitions, where there are no indexes 00 and whatnot in these audio-audio transitions. Those frames belong logically to the next track, as dicted by the TOC.

Certain buggy app (well, not optimized to dump game discs with audio tracks) used in the past (EAC) treated these things as artificial indexes 00, especially when combined with TOC versus subcode desyncs.

pablogm123 wrote:These discs sometimes contain a MCN frame in certain audio tracks transitions, where there are no indexes 00 and whatnot in these audio-audio transitions. Those frames belong logically to the next track, as dicted by the TOC.

Certain buggy app (well, not optimized to dump game discs with audio tracks) used in the past (EAC) treated these things as artificial indexes 00, especially when combined with TOC versus subcode desyncs.

No, I've asked to assign these sectors to the previous track by default, since many Saturn and Mega CD ones are mastered this way. Only PCE CD discs need EAN sectors assigned to the next track. Default - EAN goes to the previous sector, /m - EAN goes to the next sector

Only example I have physically (or at least I am aware of that) with that kind of "colission" is track 35 of /disc/29188/. A MCN frame appears in the track 34 - index 01 / track 35 - index 00 transition.



That MCN frame belongs to previous track, pregap is 00:02:02 (Sony style) and, at least this one, was ripped finely by DIC without doing anything special. I didn't specify any /m parameter even if back then was already encoded.

Proof:
https://www.mediafire.com/?3z1r6o4yxe9d7om

Motormash probleem seems to be fixed in latest build. Image is being created now.

How to fix c2 errors by the way. Is it done automatically and how to verify it is indeed fixed?

Simply, via rereading lots of times the bad sectors until being lucky and get a reread without C2 errors for any bad sector. Not always possible, though.

If the disc to dump is really in awful condition (label side heavily scratched, corroded by long exposition to water, disc edge bad sealed and metallic layer is corroded by oxygen...), no matter how much you reread the problematic sectors, data returned will be always bad and therefore unrecoverable. Miracles don't exist.

MrX_Cuci wrote:Is it done automatically and how to verify it is indeed fixed?

C2 rereading is broken in DIC.