EXCEPTION_ACCESS_VIOLATION [SLES-02352]

[staticanime]

Received the below error using the CUE2CCD batch on South Park Rally [SLES-02352]

CUE sheet matches the one on ReDUMP.org: http://redump.org/disc/29574/

Running this through SINGLETRACK in advance, the generated CUE sheet has: TRACK 45 AUDIO INDEX 0 45:03:61 INDEX 1 45:05:61 INDEX 1 45:14:23 TRACK 47 AUDIO INDEX 0 45:20:01 INDEX 1 45:22:01

I suspect the problem is with the cue sheet rather than SBITools, but I'm just looking to confirm that.

[staticanime]

Modifying Track 46 in the original CUE from: FILE "South Park Rally (Europe) (Track 46).bin" BINARY TRACK 46 AUDIO INDEX 01 00:00:00 to: FILE "South Park Rally (Europe) (Track 46).bin" BINARY TRACK 46 AUDIO INDEX 00 00:00:00 INDEX 01 00:02:00

And Track 60 from: FILE "South Park Rally (Europe) (Track 60).bin" BINARY TRACK 60 AUDIO INDEX 01 00:00:00 to: FILE "South Park Rally (Europe) (Track 60).bin" BINARY TRACK 60 AUDIO INDEX 00 00:00:00 INDEX 01 00:02:00 has resulted in successful conversion, with no side effects to the game

[Kippykip]

Strangely, I wasn't able to reproduce the problem with the same game. Although my ReDump set has the filename of: South Park Rally (Europe) (En,Fr,De,Es) (Track XX).bin instead of South Park Rally (Europe) (Track XX).bin

Here's the log of mine:

Adding '2 second lead-in' for Track: 65 Adding timecode data for Track: 65 Adding '2 second lead-in' for Track: 66 Adding timecode data for Track: 66 Adding '2 second lead-in' for Track: 67 Adding timecode data for Track: 67 Adding '2 second lead-in' for Track: 68 Adding timecode data for Track: 68 Adding '2 second lead-in' for Track: 69 Adding timecode data for Track: 69 Adding '2 second lead-in' for Track: 70 Adding timecode data for Track: 70 Adding '2 second lead-in' for Track: 71 Adding timecode data for Track: 71 Adding '2 second lead-in' for Track: 72 Adding timecode data for Track: 72 Adding '2 second lead-in' for Track: 73 Adding timecode data for Track: 73 Adding '2 second lead-in' for Track: 74 Adding timecode data for Track: 74 Adding '2 second lead-in' for Track: 75 Adding timecode data for Track: 75 Adding '2 second lead-in' for Track: 76 Adding timecode data for Track: 76 Finished adding CD Audio subchannel data! Done converting! Everything exported to: 'CCD\South Park Rally (Europe) (En,Fr,De,Es)\'

What build of SBITools were you using?

[staticanime]

I was using 0.3.1 from the Releases page.

Just to note, there are two builds of South Park Rally on ReDump in Europe: South Park Rally (Europe): http://redump.org/disc/29574/ South Park Rally (Europe) (En,Fr,De,Es): http://redump.org/disc/807/

It's the 2nd one that I had issues with, first one was fine. Only difference was the 2nd one's Track 46 & Track 60 in the cue sheet only had one INDEX line, compared to 2 INDEX lines in the first.

[Kippykip]

Wow that is just weird, I've never seen audio tracks with a single index, let alone starting with INDEX 1 instead of INDEX 0. That's what would be causing the crash, I never wrote my tools to account for that.

[Kippykip]

Hmm, interesting. Attempting to burn it causes an error in ImgBurn as well. I could probably add a check to SBITools where it can apply the fix on the fly

[Kippykip]

Alright it won't burn in CloneCD aswell (it thinks it's a DVD?), because it's only got 1 dump on redump.org with no verifications, I'm acquiring a copy of this game on ebay, as it's cheap and appears to be the Australian PAL release which is easy for me to get.

I will dump with my PLEXTOR and see what the cue sheet outputs on my end.

[staticanime]

Yeah, I suspect the original dump is a little bit dodgy, so would be good to see what the cue from a new dump looks like!

[Kippykip]

I have another update from the VGPC team, apparently Bust-A-Move 3 DX also has the same INDEX error on it's redump cue. Once I get my copy of south park rally, I'll see what the process is to fix the problem and make it so SBITools detects it and corrects the CUE sheet automatically.

[staticanime]

I found one more example, but it's stupidity rather than an actual issue IMHO.

In Street Fighter Collection (Disc 1) (USA), the final track of the reDump cue sheet has the MODE listed (presumably) incorrectly as MODE2/2352 rather than AUDIO, and with a pregap of 3 seconds instead of the normal, which I've never seen before with any other discs. Editing the final track to AUDIO and reducing the pregap, the disc converted properly, and plays fine in BizHawk, albiet with limited testing

[cgarz]

Strange things indeed. I wonder how many other weird surprises there are. @Kippykip How easy would it be to scan every single PS1 redump cue for such strange errors? Does a tool exist that can batch scan cue sheets for sanity? If not this could be a good suggestion for SBITools. At your discretion ofc =D

[Kippykip]

Strange things indeed. I wonder how many other weird surprises there are. @Kippykip How easy would it be to scan every single PS1 redump cue for such strange errors? Does a tool exist that can batch scan cue sheets for sanity? If not this could be a good suggestion for SBITools. At your discretion ofc =D

The thing is, I'm not too sure how these cue sheets got messed up in the first place, so making automatic detection of something unknown could break it further. Although I might implement a detection/fixer for the first "South Park Rally" problem where it lacks a "INDEX 00" as that sounds easy to correct and detect, but if there's some other random glitches such as an audio track being detected as MODE2 track with a weird pregap like the above, then this is gonna get really hard to detect hahaha. I've sent a message to the VGPC group to check on the Street Fighter dump track, I'll keep you all updated.

Before I implement a fix for the first problem though, I'll wait for the South Park game to arrive in the mail so I can definitely confirm whether it was an original dumping problem, as well as know exactly how to 100% correct it in the CUE. There's also the possibility that the .BIN track file also got malformed during the original dump with the CUE, only one way to confirm.

[cgarz]

[...] I'm not too sure how these cue sheets got messed up in the first place, so making automatic detection of something unknown could break it further. [...]

Yea good point, I agree, automatic detection of what's up could easily get complicated fast. Perhaps a simple "hey, something is not right" might be easier at any sign of trouble though.

[...] Before I implement a fix for the first problem though, I'll wait for the South Park game to arrive in the mail [...]

Yea definitely the best course of action. Will you upload your dump to Redump?

[Kippykip]

Yeah I'll definitely upload to the redump team aswell, hopefully the condition is good when it arrives. I didn't get much of a response for the street fighter game problem, might be something to look into for the future.

[Kippykip]

The game arrived the day before I went camping, I'm back from my trip now. Can confirm, the cuesheet should be just like how you manually edited it (as kinda expected, but just wanted to make absolutely sure.) The MD5/SHA1 hashes match the track binaries so the cuesheet is the only error. http://forum.redump.org/post/69933/#p69933

At some point I will add a "auto correcter" in SBITools that fixes it on the fly. Thanks for helping out guys!

[Kippykip]

The "auto correcter" code has been implemented in SBITools 1.3.2 now. (So if a game is unburnable due to the bad redump.org cuesheets, just use -singletrack or convert it through SINGLETRACK.bat and it should be now burnable) Enjoy guys and thanks for reporting the issue!