Alternative sync description

[vadosnaprimer]

The checkbox should inform what it does and what it affects. In some cases it must be turned off to dump frames accurately. For example, Gambatte drops frames with altsync, GBHawk duplicates them. Some info is here and I totally disagree that it's not a huge deal overall. We just need to know which cores need it on and off.

[fsvgm777]

I, myself, would prefer if alternate sync dumped all of the frames and not dropping or duplicating them. For instance, the PS1 boot sequence drops a LOT of frames with alternate sync enabled when dumping, while they're all there with it disabled. I once checked at which framerate the PS1 boot sequence was meant to dump, and it turned out to be 60000/1001 FPS and not ~59.292 FPS.

[Spikestuff]

sitting here always disabling it (unless it's PAL PS1 games) Heh.

Remember when this was automatically disabled in earlier versions? I do. That was a better time.

[Sonia-7]

Now whenever I dump a movie I have to go to "Config and Record AVI/WAV" instead of straight "Record AVI/WAV" in order to uncheck it, which is kinda bothersome.

If at least it was possible to save the unchecked box as default, it'd not be necessary to uncheck it every time.

[nattthebear]

For cores with weird frame timing (GB in adaptive mode), it's easier for most people to spot an audio hiccup than a video hiccup, so alternate should be the default. For cores with strict sound timing (NES, SNES, etc), alternate is always better, so alternate should be the default. For cores with completely broken sound timing (N64), alternate is always better, so alternate should be the default.

Would you all stop crying if you could turn on the "fuck up my audio" option permanently in the config?

[vadosnaprimer]

I think the best solution would be to give meaningful hints right in the dialog near the checkbox instead. Upon pondering I saw that audio is supposed to be reliable source of global sync when video and input have weird timing, but in some cases it's just not the case. For example, in PS1 BIOS screen, NTSC mode, alt sync breaks the interlaced field order. Why would it have to break it there? Seems strange.

[nattthebear]

VideoProvider doesn't know about interlaced, so the dumping code doesn't know about interlaced. If all that were wired in, the dumper would probably have to skip two "frames" at a time (really fields) in interlaced mode if it needed to skip. Of course, that wouldn't work out well because the other operation, duplicating two fields at a time, would look horrible and juddery due to how timing works.

Interlacing sucks.

[fsvgm777]

Interlacing sucks.

And that's why I'd much rather have alternate sync dump all the frames instead of duplicating/dropping frames, because you will run into problems trying to deinterlace footage if either the top or the bottom field gets skipped (resulting in two consecutive top or bottom fields). Whether that's actually feasible is a different story.

Not to mention there are games that actually run at 480i (notably Tekken 3), so have fun deinterlacing that if one field gets dropped. It will cause a huge mess.

[nattthebear]

Your request is pointless. If alternate sync dumped all of the frames, exactly 1:1 with what the emulator produced, how would it compensate for audio/video desync? By reworking the audio? Then it would be normal sync. Maybe the normal sync method could be improved with a better audio stretch/squeeze algorithm, sure. But that's a different question.

[fsvgm777]

If alternate sync dumped all of the frames, exactly 1:1 with what the emulator produced, how would it compensate for audio/video desync?

By dumping at the actual frame rate instead of some target frame rate and dropping/duplicating frames in the process. Obviously, dumping at the target frame rate with alternate sync while dumping all of the frames will result in audio/video desync.

Come to think of it, a PAL PS1 actually has instances where it runs at 60 FPS during the boot sequence (just enable frame rate display and run any PAL PS1 game with audio throttle). When dumping with alternate sync, this results in a lot of dropped frames (evident). On regular sync, the timings are completely screwed due to it dumping 60 FPS video at 50 FPS (while dumping all of the frames) and also has the very nasty side effect of screwing up the audio big time. As an aside: My PAL PS1 behaves the exact same as with BizHawk set to Audio Throttle (and when dumping with alternate sync).

What I did notice is that SMS and PCE have a frame rate specified in their respective movies (around 59.9 FPS), yet they dump at a flat 60 FPS. Maybe the same should be done for PS1 (as in 60000/1001 FPS for NTSC, a flat 50 for PAL)?

[vadosnaprimer]

Come to think of it, a PAL PS1 actually has instances where it runs at 60 FPS during the boot sequence (just enable frame rate display and run any PAL PS1 game with audio throttle).

If this is true, we must split on known framerate changes. I know right now this isn't implemented, and I don't now if we can get this info from the cores.

[fsvgm777]

Come to think of it, a PAL PS1 actually has instances where it runs at 60 FPS during the boot sequence (just enable frame rate display and run any PAL PS1 game with audio throttle).

If this is true, we must split on known framerate changes. I know right now this isn't implemented, and I don't now if we can get this info from the cores.

Here's a video showing the PS1 boot sequence (and the demo disc I had in it at the time of recording) on a 2-in-1 CRT+VCR (that's why I'm showing the tape options, since it shows the video system).

Of note that since these are the tape options, it will show "AUTO" during the PAL segments (because it supports recording into PAL, SECAM and MESECAM).

As you can see, it switches between PAL and NTSC several times, which matches with Audio Throttle in BizHawk (as it does clearly indicate 60 FPS during the NTSC segments).

BTW: This is an unmodded SCPH-5502.

[nattthebear]

By dumping at the actual frame rate instead of some target frame rate and dropping/duplicating frames in the process. Obviously, dumping at the target frame rate with alternate sync while dumping all of the frames will result in audio/video desync.

I think you're misunderstanding things. Bizhawk does not support true VFR (and probably never will). The reason any of these "sync methods" for dumping exist is because there's no true VFR.

Given that CFR is in use, you can take the mismatching audio and video and either squeeze frames, or squeeze samples.

[nattthebear]

Some good things that could use separate issues (but won't likely be done):

1. Support true VFR in Bizhawk, including audio/video but also input.
2. Track interlace properties (top/bottom field) through the video chain.

For this issue, all we need to do is add some clarifying text to the checkbox.

[vadosnaprimer]

Don't close it yet, it's good to have everything related discussed while we're at it. There's more that @fsvgm777 and I are researching atm.

[ghost]

Sorry, I'm late to the party!

It might be worth noting that along with the concerns raised about dropped fields in regards to interlacing and alternate sync, this also can affect progressive footage in negative ways. As an example, ssections of footage that were previously steadily duplicating every second frame (think 30fps in a 60fps video) occasionally stray by a frame, meaning the assumption that every second frame could be safely decimated would be wrong and could cause a significant number of dropped frames if the footage were to be handled under this incorrect assumption. That being said, it's already heavily implied and should be obvious to most.

For cores with weird frame timing (GB in adaptive mode), it's easier for most people to spot an audio hiccup than a video hiccup, so alternate should be the default. For cores with strict sound timing (NES, SNES, etc), alternate is always better, so alternate should be the default. For cores with completely broken sound timing (N64), alternate is always better, so alternate should be the default. This is something I strongly agree with. A lot of the decision between alternate sync and not is whether it's subjectively better to have audio stutter or fps stutter, and audio is definitely the most intrusive of the potential drawbacks.

As proper VFR dumping seems both impractical and unlikely at this point, there might be some different avenues that could be explored. I had a bit of a thing and came up with the following suggestions, but keep in mind that they're not necessarily intended be practical solutions, only examples.

In situations where alternate sync would solve audio problems but also drop occasional frames, would it be possible to dump at a multiple of the internal frame rate or a custom frame rate? Dumping a 60fps title at 120fps would ensure that no frames are lost and then the file can be handled from there. Similarly, in 50/60 VFR situations, 300 could be used (it's ridiculous, but could be converted to 60fps for CFR encoding or dedupped for 50/60 VFR without dropping frames).

Alternatively, if regular sync was to be used to preserve field order in interlaced dumps, would it be possible to add an option blend or interpolate overlapping sound samples in a way which is less intrusive in a dumped video?

I don't expect either of the above ideas to actually be viable solutions, they're just the first dumb band-aids hacks I could think of. I only wanted to raise the point that there might still may be different ways to improve the dumped video, particularly in VFR > CFR situations.

[vadosnaprimer]

I do believe that splitting on framerate changes is better. It allows to manipulate the resulting segments the way you want. Also it was confirmed that N64 samples are generated inconsistently from frame to frame, but it seems the overall amount of them is still correct, so maybe all that's needed for N64 is putting consistent amount of samples to the actual dump.

[ghost]

I agree that that is a much better idea (my thoughts weren't supposed to be actual solutions, anyway). Are there any cases of currently included cores giving VFR (or non-standard) output that can't be serviced in this way?

[nattthebear]

I do believe that splitting on framerate changes is better.

That's not practical in the short term though. (Short term meaning before Bizhawk adds proper support and knowledge for VFR, interlace, and all of that.) All the dumping api sees is individual video frames. Each video frame is delivered with some number of audio samples, and with just that knowledge the system has to guess at the current framerate. There's one nominal framerate constant provided by the emulator.

I think you'll find that in most of these pathological situations, you can't tell the optimal thing to do until you look at all of the data at once.

[nattthebear]

I've created what I think is an actionable and achievable ticket from this https://github.com/TASVideos/BizHawk/issues/2137