Well, I guess the tolerable desync concept is somewhat debatable, so far all my script had 15 as value, so I could bypass some other annoyance like extended sound glitch. I'll probably just add a setting for the tolerable desync, where minvalue would be 1 so we can get a checkpoint as soon as there a desync. This way, we can see what kind of "audio output" we shall get from one game to an another. So it should be fine.
Even at setting of 1 for tolerable desync, the script should be going backwards at most 15 frames to cover the sound delay.
Note1: All green bar are also desync
Note2: Some major desync will only be fixed by a savestate at desync, in such case... we might just have wasted all the previous savestate trying to bypass the desync himself.
So yeah, the best matchup at some point would probably to anticipate if there a specific "strategy" pattern to favorise. Some strategy would be
-Use the backward tas-savestate for minor desync,
-Use eternal-savestate(that is actually processing frame from a backward tas-savestate) for minor desync point
-Use tas-savestate directly for major desync point
Note: the difference between major and minor desync would be, that the game is likely to desync in the next "few" frame(let's say max 15 frames)
Also, keep in mind that our goal is trying to make plan for getting an efficient "list of savestate" to load while replaying the at last pass of the run in an automated way.
For testing purpose I'll just make the workflow as simple as possible using savestate at desync point, but step by step and while testing with several game, we should be able to enhance the workflow to make it better, while using the best strategy avalaible, avoid possible issue, etc..
---
// The filename was allocated using malloc. Do something about that.
free(filename);Just to make sure, the savestates made are always from TAS SPU, and not Eternal SPU, right? Might be another misunderstanding, but using savestates from Eternal SPU will probably cause more desyncs, hence why I am making sure...
I believe I've seen this before and it was due to loading the state while the game is not rendering from the initial game load, so loading a bit later fixed it.
{500, 1000, 1500, 1921, 2000, 2500, 2685, 2804, 2828, 2947, 3000, 3072, 3197, 3326, 3356, 3453, 3500, 3578, 3705, 3831, 3961, 4000, 4090, 4217, 4344, 4469, 4500, 4596, 4725, 4852, 4880, 4977, 5000, 5105, 5235, 5360, 5500, 5612, 5741, 5868, 6000, 6122, 6247, 6279, 6377, 6431, 6500, 6543, 6662, 6787, 6916, 7000, 7043, 7170, 7295, 7422, 7500, 7549, 7695, 7735, 7823, 7950, 8000, 8075, 8202, 8329, 8456, 8500, 8583, 8710, 8835, 8891, 9000, 9147, 9266, 9401, 9500, 9520, 9649, 9774, 9899, 10000, 10024, 10151, 10279, 10407, 10500, 10532, 10659, 10786, 10911, 11000, 11038, 11165, 11290, 11417, 11500, 11543, 11669, 11794, 11919, 12000, 12044, 12169, 12294, 12419, 12500, 12544, 12669, 12721, 12795, 12819, 12887, 12941, 12981, 13000, 13045, 13100, 13243, 13303, 13386, 13410, 13500, 13529, 13553, 13593, 13672, 13698, 13748, 13815, 13839, 13958, 13982, 14000, 14036, 14101, 14125, 14245, 14373, 14397, 14500, 14572, 14659, 14683, 14735, 14749, 14802, 14826, 15000, 15019, 15073, 15112, 15174, 15311, 15375, 15500, 15530, 15554, 15614, 15628, 16000}
Desync is at frame 415. We save the tasSPU sate at frame 400. We capture the movie up to frame 415 with eternalSPU. Then we LOAD the tasSPU state from frame 400. In the encode, the frame 430 will be equal to our movie frame 415, but right after the tasSPU state (from frame 400) was loaded (at frame 415), there is the sound glitch. So we give eternalSPU these extra frames.
But while doing this, we must dump another list - a list of avisynth trim commands with the corresponding frames. There's no command to cut out a bunch of frames in avisynth, only to pick and process some segment, so we need to append all the segments we pick with Trim. But what frames to trim at?
As I said, we already have the properly sounding frames 0-415 from eternalSPU. So the first Trim command would use this segment. Then we shift the frame number forward by the diff between 400 and 415 (extra frames offset) and have the second segment starting at frame 430. Let's assume it needs to end at frame 810 then. At frame 810 we load the state from frame 800 (this means we have the new offset of 10 frames) and the next segment will start at the video frame 820, etc.
So here is the code that must be dumped to a different text file, it then will be directly copypasted to our usual avisynth script and used for encoding.
Language: avisynthTrim(0, 415) + \ Trim(430, 810) + \ Trim(820, 1000)
Language: avisynthAVISource(...) Remove(415, 15) Remove(811, ...) ... function Remove(clip c, int i, int Count) { c Trim(0, -i) + Trim(i + Count, 0) }
frame 0000000000000000000015611 frame 0000000000000000000015612 frame 0000000000000000000015613 frame 0000000000000000000015614 Now awaiting for any incoming desync. Now trying fix the desync at frame 142 ... No savestate/checkpoint found near the desync, the emulator will reset.
Now it looks like the detect application launched by sync script doesn't use TASspu, since there is a desync at EVERY frame, and it is not fixed by loading checkpoints..
-The sync script will launch an another instance of pcsxrr using the detect script with a switch plugin feature. The last time I tried(some month ago) it used to work, but now for some reason, now I encounter a desync fest around the first few kill. To fix that: *Restore your backup folder(or restart from the very beggining if you didn't used a backup) *Start the sync script using the Eternal plugin. *Close the second instance using the detect script. *Manualy launch a new pcsxrr instance using the detection script and the TAS sound plugin. And that's it, no more desync fest. As I said, these additionnal step might be required as long as I/we didn't figure what's up with the switch plugin feature that may or not work sometime. Just make sure to at least test without these step for your first time.
+fsvgm777 never censoring anything.
Since I don't know how to package them can I request one please, I want to test this out too.
