2,576 (edited by sarami 2020-07-25 12:51:57)

@tenyuhuang
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Try and upload logs.

sarami wrote:

@tenyuhuang
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Try and upload logs.

Thank you for the build, here's the logs:

Post's attachments

mk_demo_t2.7z 9.28 kb, 1 downloads since 2020-07-25 

You don't have the permssions to download the attachments of this post.

2,578

Re-uploaded. Link is same. Try again, plz.

sarami wrote:

Re-uploaded. Link is same. Try again, plz.

Thank you very much! It worked! big_smile

Probably it's this really huge offset that caused all these issues, is it?

     Combined Offset(Byte)   9784, (Samples)  2446
    -   Drive Offset(Byte)    120, (Samples)    30
    ----------------------------------------------
           CD Offset(Byte)   9664, (Samples)  2416
    Overread sector: 5
    SubChannel Offset: 0

I've also attached all log files if anyone's interested.

Post's attachments

mk_demo_t3.7z.001 1 mb, 4 downloads since 2020-07-26 

mk_demo_t3.7z.002 933.47 kb, 3 downloads since 2020-07-26 

You don't have the permssions to download the attachments of this post.

2,580 (edited by sarami 2020-07-26 23:46:16)

Uploaded test version.

user7 wrote:

dic crashing on a press disc dvd-r that isobuster dumps fine

logs: https://drive.google.com/file/d/1O8K0ft … sp=sharing

The problem is this code. http://forum.redump.org/post/56490/#p56490
Disabled it. Your disc can be dumped but Simcity 3000 (USA) can't be dumped again.

tenyuhuang wrote:

Probably it's this really huge offset that caused all these issues, is it?

Yes. Btw, the problem still exists in this dump. (subchannel)
I fixed it. Retest and upload all logs, plz.

sarami wrote:
tenyuhuang wrote:

Probably it's this really huge offset that caused all these issues, is it?

Yes. Btw, the problem still exists in this dump. (subchannel)
I fixed it. Retest and upload all logs, plz.

Thanks again for the fix! Here are the logs big_smile

Post's attachments

mk_demo-t5.7z.001 1 mb, 3 downloads since 2020-07-27 

mk_demo-t5.7z.002 905.35 kb, 3 downloads since 2020-07-27 

You don't have the permssions to download the attachments of this post.

2,582

tenyuhuang wrote:

Here are the logs

It seems good.

sarami wrote:
tenyuhuang wrote:

Here are the logs

It seems good.

Thank you very much for all the fixes!
May I ask what's the cause of those "sub indexes" and what are they? I've ran into dumps like this a few times and wans't sure why.

2,584

tenyuhuang wrote:

May I ask what's the cause of those "sub indexes" and what are they? I've ran into dumps like this a few times and wans't sure why.

e.g. http://redump.org/disc/33409/
sub indexes are created when TOC indexes and Subchannel indexes do not match.

2,585 (edited by Jackal 2020-08-05 16:04:50)

I dumped with:

dic xgd2swap e nfsu 4 3825924 108976 3719856

but the output dump is 3825798 sectors?

logs attached

Post's attachments

nfsu.zip 10.11 kb, 1 downloads since 2020-08-05 

You don't have the permssions to download the attachments of this post.

2,586

Jackal wrote:

but the output dump is 3825798 sectors?

https://www.mediafire.com/file/eq80y20l9cwf48f/file
- fixed: seek position when reading error occurs [xbox only]

2,587 (edited by Jackal 2020-08-06 19:08:22)

sarami wrote:
Jackal wrote:

but the output dump is 3825798 sectors?

https://www.mediafire.com/file/eq80y20l9cwf48f/file
- fixed: seek position when reading error occurs [xbox only]

Indeed fixed cool

2,588

Something weird for http://redump.org/disc/72268/ misdetects track 14 as audio and toc/sub desync for tracks 13 and 14, t..p dumps it properly (no "audio" and no desync).

Post's attachments

SKT-1123(DICtest20200806).7z 4.05 mb, 1 downloads since 2020-08-11 

You don't have the permssions to download the attachments of this post.

2,589

F1ReB4LL wrote:

track 14 as audio and toc/sub desync

It's weird.

LBA[091152, 0x16410]: P[ff], Q[41130104080900201727f796]{ Data,      Copy NG,                  Track[13], Idx[01], RMSF[04:08:09], AMSF[20:17:27]}, RtoW[0, 0, 0, 0]

91152 is the 1st sector of track 14 and subP is correct but subQ points the last sector of track 13. This sector has no subQerror.

LBA[091151, 0x1640f]: Track[13]: SubP[00]:[0x3f] -> [0xff]
LBA[091152, 0x16410]: Track[13]: SubP[00]:[0x3f] -> [0xff]
LBA[092069, 0x167a5]: Track[14]: SubQ fixed using next subQ

Is there the sub file of t..p?