Fix snapping audio times to current video position

[arch1t3cht]

Lots of text incoming, since timestamp wrangling is hell and I want to write down my reasoning before I inevitably forget it again in two weeks.

Before commit 5d4973a, snapping an audio line's end time to the "current video position" indicator line would reliably make the line end on the frame before the current video frame (i.e. make the current video frame be the first frame where the selected line is not visible any more).

Commit 5d4973a broke this, making the behavior of snapping audio times to the "current video position" inconsistent.

The commit in question is definitely not fully correct, ultimately just because the entire concept of implicitly converting millisecond timestamps to centisecond timestamps is flawed in and of itself, and bound to always fail in sufficiently crazy edge cases. Fixing the timestamp conversion properly would entail either working with centisecond timestamps from the beginning, or somehow making the process of converting timestamps aware of the context the timestamps are from (e.g. "coming from some frame timestamp").

However, this specific issue was only exposed by this commit, and not solely caused by it. Its root cause was just that the "current video position" marker on the audio display would mark the exact time of the current video frame, rather than the ideal start/end time for a line to start/end at that video frame. This is why only snapping to the "current video position" broke while snapping to keyframes worked fine. It's quite possible that snapping to the "current video frame" marker was just never thought of as a use case.

So, for now, #421 can just be fixed by positioning the "current video position" marker in the middle of the frame rather than at the frame's exact start, and
5d4973a can be untangled at some later time.

Fixes #421.

---

Still need to decide how to handle the fact that keyframe markers and current frame markers may now overlap.

[petzku]

First: This new snapping behavior itself is much better, thank you.

Still need to decide how to handle the fact that keyframe markers and current frame markers may now overlap.

Personally, I'm not 100% sure if this would really even be a problem, though I would certainly prioritize the keyframe marker. (It is generally easy to guess where the video playhead "should be", though I don't even see it being all too relevant in this case.) But, if we want to avoid it (reasonable), a 1px shift seems most logical to me (though it might not still be too easy to distinguish two adjacent vertical lines like that).

That said, I have slight personal preference to, if possible, keeping the video-playhead cursor visually positioned "on" the frame timestamp. However, I realize this is purely based on opinion, and is not even clearly always "desirable" (just as, to me, it is more "helpful" to see the video playhead indicator slightly offset from properly-frame-snapped times, it might be more confusing to someone else as to why lines are not snapped "correctly onto" the indicator). Most realistically, this is just not feasible.

Visual clarification of above paragraph

To make clear what I mean, I have grown used to recognizing timing like this (where the line start marker is directly on the playhead marker) as "bad":

and timing like this (where the line marker is slightly right of the line start time) as "good":

Meanwhile, with my suggestion, someone snapping a line's end time to the cursor would see this, and might be very understandably confused: