Thanks again for the fix! Here are the logssarami wrote:Yes. Btw, the problem still exists in this dump. (subchannel)tenyuhuang wrote:Probably it's this really huge offset that caused all these issues, is it?
I fixed it. Retest and upload all logs, plz.
It seems good.tenyuhuang wrote:Here are the logs
Thank you very much for all the fixes!sarami wrote:It seems good.tenyuhuang wrote:Here are the logs
e.g. https://redump.info/disc/33409/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.
Code: Select all
dic xgd2swap e nfsu 4 3825924 108976 3719856https://www.mediafire.com/file/eq80y20l9cwf48f/fileJackal wrote:but the output dump is 3825798 sectors?
Indeed fixedsarami wrote:https://www.mediafire.com/file/eq80y20l9cwf48f/fileJackal wrote:but the output dump is 3825798 sectors?
- fixed: seek position when reading error occurs [xbox only]
It's weird.F1ReB4LL wrote:track 14 as audio and toc/sub desync
Code: Select all
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]Code: Select all
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 subQsarami wrote:Is there the sub file of t..p?