Betamax: Sync issues during certain scenes

[davidvankemenade]

Checklist

• ✅ I have searched the issues page for any duplicate issues open or closed and confirmed that this bug has not been reported before.
• ✅ I have tested the issue with the current build.
• ✅ I have attached log files, uploaded sample data, and commands used so that the issue can be easily reproduced by the developers.

Bug Description

As (old) Betamax recorders didn't have flying erase heads, transitions from one scene to another can be quite messy. I noticed that newer versions of vhs-decode lose sync as a result of these transitions, while older versions cope better.

Steps to Reproduce

1. Download the sample file (Google Drive was full)
2. With latest commit (https://github.com/oyvindln/vhs-decode/commit/0a137f952f99803976d979e8bb4990655cfe8267), execute ./vhs-decode --frequency 40 --chroma_trap --recheck_phase --pal --threads 4 --tape_format Betamax DvK-Betamax-PAL-SyncIssues.s16 output

Expected Behavior

Horizontal and vertical syncs are (reasonably) stable: Created with Windows build 0.1 (https://github.com/oyvindln/vhs-decode/releases/tag/vhsdecode_0.1)

Actual Behavior

Horizontal syncs are not stable during certain scenes:

Environment

• Decode version: latest commit (https://github.com/oyvindln/vhs-decode/commit/0a137f952f99803976d979e8bb4990655cfe8267)
• Operating System: Ubuntu

Additional Information

Horizontal syncs are stable when using

• Decode version: Windows build 0.1 (https://github.com/oyvindln/vhs-decode/releases/tag/vhsdecode_0.1)
• Operating System: Windows 10

Would it be possible to combine the sync stability from the earlier version with the decoding improvements added in later commits?

Log files: Windows decode 0.1.log Ubuntu decode commit 0a137f952f99803976d979e8bb4990655cfe8267.log

[oyvindln]

It seems some tweaks I did between the 0.1 and 0.2 releases caused it to get worse though he last commit helps with at least the current sample as I think it's more to do with the fact that the samples have levels that are a bit above spec which wasn't properly taken into account before this fix. It'll be included in the next windows .exe bundle this weekend if you don't want to manually install yourself.

You can also disable some of the hsync detection refinement with the --drh option, (or entirely with --skip_hsync_refine) in case it bugs out even with that) as a workaround though that may also make the image slightly less stable on good portions (more so if you use disable it entirely).

[davidvankemenade]

Thanks for solving this so quickly @oyvindln! I've done a quick test using the latest commit and it seems to work fine at my end as well.

Thanks in advance for the upcoming fresh .exe.