The second solution sounds like you made two savestates when one is only needed. But from what I think I gather, you're saying it isn't possible to go backwards. The 15 frame number I keep talking about is for frames going backwards. If the workflow never goes backwards, the 15 frame number is useless then. I still think there is a miscommunication between us since seemly you keep insisting a savestate at the exact desync frame, while I keep insisting a savestate before the desync frame.
I should really draw a diagram.
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.
What extended sound glitch do you mean? Do you have an example that I can take a look at? I don't see how tolerable desync would fix this problem any more than going backwards at most 15 frames. Maybe this is what I have been missing but seemly all the proposed workflows does not go backwards. Is going backwards hard? Even at setting of 1 for tolerable desync, the script should be going backwards at most 15 frames to cover the sound delay.
If we keep the backup application 15 frames behind the check application, we could apply your request easily. But now we need the program to control 2 instances, Nach promised some IPC help.
You don't need a backup application, you just use the savestates made from step 1 which is a savestate every x (100?) frames.
For example. Desync on frame 1234. 1234 - 15 = 1219. Load savestate at frame 1200, aka the 12th savestate.
The final tool for the extra 100 desyncs? Of course not, but that's what what we are aiming for right? I don't think we should compromise accuracy for automation. It be better off the manual way then since it be more accurate.
I'm still not sure for the reason of tolerable desync. Only thing I can think of is the loading screens in AD are just slightly different a few times, but I think I fix those to be exact too (hence the pain). Here is what I envision as the steps.
All done with TAS GPU except step 3 (unless it can't sync with TAS GPU then we have a different problem)
1. Pass one - TAS SPU. Playback movie. Dump every frame hash. Savestate to disk every x (100?) frames.
2. Pass two - Eternal SPU. Playback movie, hash every frame, compare hash to the same frame number as TAS SPU (will fix loading problems?). If mismatch, load the closest previous savestate that is before 15 previous frames of the mismatched frame, playback movie until 15 frames before the hash mismatch frame, save state there, continue playback to see if the mismatch has been fixed if not, repeat with loading the savestate at 15 frames before mismatch frame, save state at 14 frames before hash mismatch, if still does not fix desync, then try 13, then try 12, etc..., until the mismatch is fixed, save the frame number difference from savestate that fix the desync to the hash mismatch (to be used later in Avisynth), and then delete all unneeded savestates. At the end of this step, most or all of the savestates from pass one should be gone as only the savestate from each desync made from pass 2 is left.
3. Pass three - Eternal SPU. Capture all the desync parts to one AVI sequence, loading each state at certain points after a desync and write the trim points to file.
Now steps 2 and 3 are probably not explained well enough, and some of step 3 may be impossible to do, so let me know and I can clarify as best as I can.
Again, I really do not think tolerable desync is needed at all, and if it causes it to have 100 more desyncs, I say meh since it is now all automated.
In your example, the save state for frame 2601 was where though? I think that matters. If it is 50 frames back, you need to get a save closer to frame 2601.
Usually that sync/desync pattern was on a loading screen.
So when I saw your post talking about this issue on loading screen, I knew tolerable desync feature was something necessary.
edit: At some point here an another crazy idea: We might need a "formula guideline" for checking the amount minor desync VS major desync in order to determinate what is the amount of tolerable frame desync in order to keep a right level of sanity for "sound memory" (using eternal plugin).
Someone understand what I mean? :D
Joke aside... I'll post some more progress soon.
Does lua know what frame you are currently on? The compare should only be on the same frame number. That will fix the missing loading frames problem.
Yeah I know, I could lower the value of the tolerable desync.
For instance with the Azure Dream movie, I keep getting this:
frame 2600 Hash ok
frame 2601 Desync
frame 2602 Hash ok
frame 2603 Desync
Almost always. And there so many loading screen, that make it even more problematic.
As you know, if we load a savestate at every let's say 50 frame. In the end you get almost the same result as using the TAS sound plugin. You see what I mean?
At some point, it's up the encoder to choose the right value for the tolerable desync.
In your example, the save state for frame 2601 was where though? I think that matters. If it is 50 frames back, you need to get a save closer to frame 2601.
last = scriptclip(last.trim(4331,0), """audiodub(last,last.timestretch(100+current_frame).killvideo)""")
Edit: On second thought, it might be more due to the fact you keep changing the sample rate per frame which is not possible to put together. I'm now not sure if my solutions work.
Hmm, I forgot the exact fix for it, the newer OoT runs use Jabo's plugin to fix it but it makes rendering slow on some systems. I thought this version was suppose to automatically fix it, but maybe there was some setting I'm forgetting.
Difficult or not, it shouldn't take almost 4 months to publish a 20 minute long run. I mean how is it that Muramasa, an hour long Wii run, got published in 3 weeks?
There is no excuse, I've just been lacking the time to do it. I do feel real bad for taking this long though, but it should be up soon finally.
Basically, you want to see what are in the files in the first place to see if you can just combine them without trans coding. If you are on Windows, get MediaInfo and post the information to pastebin.com or something for us to see.