Closed davidvankemenade closed 10 months ago
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).
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.
Checklist
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
./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
Additional Information
Horizontal syncs are stable when using
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