Grand Theft Auto Chinatown Wars (ULES01347):- Game crashes at the opening plane sequence since v0.9.1-842-g00f8ae5 (Atrac3+ issue)

[solarmystic]

Issue is as stated in the title.

First singular responsible build/commit found via bisecting is v0.9.1-833-gcf8a3e4 https://github.com/hrydgard/ppsspp/commit/cf8a3e4df1cb8f0b6cd1dec8c23952faf2cf19c9 which was merged into master with v0.9.1-842-g00f8ae5 https://github.com/hrydgard/ppsspp/commit/00f8ae5f2d07e8103c3e0eb838ae93762ce6dbdd https://github.com/hrydgard/ppsspp/pull/3772

Last unaffected revision is the one right before the commit was merged into master, v0.9.1-841-g26f935b https://github.com/hrydgard/ppsspp/commit/26f935bbe58d971831b88a97aec6d48995b65997

Problem reproduction:-

1. Download any 32 or 64 bit build from v0.9.1-842-g00f8ae onwards on the buildbot. (Self compilers can skip straight to the first responsible commit, v0.9.1-833-gcf8a3e4 by using the git reset --hard cf8a3e4df1cb8f0b6cd1dec8c23952faf2cf19c9 command). Make sure you've obtained the at3+ audio plugin and have it enabled in the Audio settings of the emulator.
2. Start a new game using default settings. If you have any previously created savedata for the game, move it elsewhere temporarily for the purposes of this reproduction.
3. During the opening white plane sequence that occurs right after the autosave screens, the game will crash, taking down the emulator with it and producing a Windows Error Report.

Windows Error Report:-

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: PPSSPPWindows64test0833unkat3.exe
  Application Version:  0.0.9.1
  Application Timestamp:    523737bd
  Fault Module Name:    at3plusdecoder64.dll
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp:   51af42d5
  Exception Code:   c0000005
  Exception Offset: 000000000000191a
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:    1033
  Additional Information 1: a32a
  Additional Information 2: a32a948565dd0feee1241d919b183e78
  Additional Information 3: d926
  Additional Information 4: d926d33c8a125bedaf5c40a6fc624afa

Stack Trace from affected 64bit debug build:-

Stack Trace from affected 32bit debug build:-

Logfile from an affected 64bit debug build until it crashes:- http://www.mediafire.com/download/9g0wbo629ngccuq/ppssppDebug64.7z

Logfile from an affected 32bit debug build until it crashes:- http://www.mediafire.com/download/623e117assjgycz/ppssppDebug32.7z

Temporary solution:-

Play through that entire section without the atrac3+ plugin enabled. Game will not crash if the plugin is either disabled or missing from your ppsspp directory. Game will lack BGM if you do that though.

[sum2012]

@raven02 I just another try.Can you try this code hack work or not ? (I work) if (inbytes > 0 && inbytes == atrac->atracBytesPerFrame) change to if (inbytes > 0 && inbytes == atrac->atracBytesPerFrame && SamplesNum < finish) {

[dbz400]

I'm using 32bit build as well .Will try your code.

[dbz400]

It works well and no crash . @unknownbrackets , what do you think ?

[dbz400]

The following one seems to be the function called to crash

Atrac3plus_Decoder::Decode(atrac->decoder_context, atrac->data_buf + atrac->decodePos, inbytes, &decodebytes, buf);

int ret = frame_decoder(context, inbuf, inbytes, &channels, &buf);

[dbz400]

@sum2012 , i think it just somehow skipped the decoding at all as there should be conversation among those soliders as well as background music.

[sum2012]

@raven02 So that I call this one is a hack code.

[unknownbrackets]

Does it work fine in JPCSP still? I noticed some of the results from the tests I did were implemented in JPCSP:

http://code.google.com/p/jpcsp/source/detail?r=3392 (again I realize it uses a different decoder...)

-[Unknown]

[dbz400]

Yep, JPCSP seems to be changed the logic for BufferInfoForResetting. Trying to figure out hw to translate them to here

           // Assuming "atracBytesPerFrame" bytes in the input file for each "maxSamples" samples.
            int inputFileSampleOffset = inputBuffer.isFileEnd() ? 0 : inputFileDataOffset + sample / maxSamples * atracBytesPerFrame;
            int resetWritableBytes = inputBuffer.isFileEnd() ? 0 : inputBuffer.getMaxSize();
            int resetNeededBytes = inputBuffer.isFileEnd() ? 0 : atracBytesPerFrame * 2;

[unknownbrackets]

Seems to be affecting Tales of the World Radiant Mythology 3 as well, most likely.

http://forums.ppsspp.org/showthread.php?tid=1807&pid=50652#pid50652

-[Unknown]

[sum2012]

I think that should fix\work arround this before major release

[dbz400]

I think it would be good to know if the new atrac3+ ffmpeg implementation did same crash here.

[solarmystic]

This issue should be labelled with the atrac3+ label.

[solarmystic]

This game no longer crashes upon starting a New Game after https://github.com/hrydgard/ppsspp/pull/4221 was merged into master.

However, it cannot be considered fixed yet, as the BGM just stops playing instead at that segment instead of crashing, so a bug is still present.

Notably, the crash related to atrac3+ when loading a savegame in GTA Vice City Stories https://github.com/hrydgard/ppsspp/issues/3805#issuecomment-24659414 also no longer occurs after the maxim stuff got merged to master as well, consider that one fixed.

[solarmystic]

Logfile is also spamming these lines repeatedly too:

48:08:716 mix sound th I[ME]: HW\MediaEngine.cpp:108 FF: GHA amplitude mode 0
48:08:716 mix sound th I[ME]: HW\MediaEngine.cpp:108 FF:  is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
48:08:716 mix sound th E[ME]: HLE\sceAtrac.cpp:605 avcodec_decode_audio4: Error decoding audio -1163346256
48:08:716 mix sound th E[ME]: HLE\sceAtrac.cpp:793 UNIMPL sceAtracGetInternalErrorInfo(0, 09fcf274)
48:08:716 mix sound th I[ME]: HLE\sceAtrac.cpp:929 sceAtracReleaseAtracID(0)
48:08:816 mix sound th I[ME]: HLE\sceAtrac.cpp:1233 0=sceAtracSetHalfwayBufferAndGetID(08bfec80, 00001000, 00040000)
48:08:816 mix sound th W[ME]: HLE\sceAtrac.cpp:1114 This is an atrac3+ stereo audio
48:08:817 mix sound th I[ME]: HLE\sceAtrac.cpp:735 0=sceAtracGetBufferInfoForResetting(0, 0, 09fcf238)
48:08:848 mix sound th I[ME]: HLE\sceAtrac.cpp:935 sceAtracResetPlayPosition(0, 0, 262144, 0)
48:08:849 mix sound th I[ME]: HLE\sceAtrac.cpp:1248 sceAtracSetLoopNum(0, -1)

[hrydgard]

probably another case of the game playing junk data, confusing instead of crashing the new Atrac3+ code.

[solarmystic]

Finally properly fixed with https://github.com/hrydgard/ppsspp/pull/4483 with the https://github.com/hrydgard/ppsspp/commit/225f8efbb9e8c4209723b9ce50b114c263a54403 commit provided by @papel

The game no longer crashes at the aforementioned spot, and the BGM doesn't cut off either, it continues to play throughout the entire sequence.

https://github.com/hrydgard/ppsspp/issues/3805#issuecomment-24659414 in GTA VCS is also properly fixed, with game now playing the appropriate dialogue during that opening scene, with no crashes.

Big thanks to @papel for the responsible commit that fixed it.

Closed.

[sum2012]

It is a good news :)

[unknownbrackets]

Just to say, I'm pretty certain I can create a test that shows this is not "properly" fixed. It may be fine for now, but that doesn't mean it's what the PSP does, but I don't like things that aren't at all what the PSP does being called "proper." The only proper fix is to make it work the way the PSP observably does. An unknown quantity (possibly zero, probably less than before) of games could depend on correct behavior.

-[Unknown]

[hrydgard]

Agree, but was the previous behaviour matching the PSP in all cases? If not we are choosing between two hacks, and if we're at that stage, might as well choose the one that fixes the most games. Ideally of course we should match the PSP's behaviour, we need a better testsuite.

[unknownbrackets]

Again, I'm just saying it's not a "proper" fix. It may be a "good hack."

-[Unknown]

[hrydgard]

Right, yeah.

[ydamigos]

@unknownbrackets and @hrydgard if you own a PSP which is the best tool to examine PSP's behaviour? pspautotests, jpcsptrace?

[unknownbrackets]

The combination of the two. However, pspautotests is probably better for testing how something should work. JpcspTrace is better for seeing how it's being used.

-[Unknown]

[ydamigos]

I'll give it a try to find out how sceAtracGetBufferInfoForResetting should work. First thing to find documentation of these tools.

[unknownbrackets]

http://forums.ppsspp.org/showthread.php?tid=2822&pid=56026#pid56026 https://github.com/hrydgard/pspautotests#readme

https://github.com/hrydgard/pspautotests/blob/master/tests/audio/atrac/resetting.expected

-[Unknown]

[ydamigos]

@unknownbrackets thank you!!!

[solarmystic]

Sorry for the improper use of "proper", I should've clarified what I meant.

What I meant by "proper" was that the game just exhibits the correct behaviour since the commit instead of being muted like before, not that the fix itself is "proper".