search

taburineagle / MPC-HC-Looper

A/B looping program to complement the MPC-HC media player, with speed controls, playlist creation (and saving), and tie-in to my Looper Trimmer EDL editing program.
Other
15 stars 1 forks source link

Actual and displayed time mismatch #12

Open h0rn3z0r opened 3 years ago

h0rn3z0r commented 3 years ago

The IN point is always a bit off - it is noticeable when you need to start an event at some specific frame (e.g. exactly after scene change). There is also a 500ms offset between the actual timestamp in player and the displayed timestamp in GUI and OSD.

taburineagle commented 3 years ago

This one actually isn't a bug - I noticed right at the very beginning when I started Looper that there are 2 different time displays in MPC-HC (and MPC-BE, but this was before BE was a thing) - there's regular time, and "High precision" - and made a compromise. If you right click on the time in MPC-HC/BE and change it to "High precision", you see the time in more granular detail (with milliseconds), and the time is always 500ms more than what the normal time reports. Being that there is no programmatic way to determine whether MPC-HC is showing regular or "High precision" time, I settled with reporting all times in regular time, which is always 500ms behind what "High precision" reports the time is. IN point and current position time is always reported in regular time - it's still technically "correct" (in that, if you're on regular time, and you advance a media file frame by frame until it's on a second boundary, MPC-HC and Looper will both report the second advancing when it reaches the next frame), it just isn't "correct" in how "High precision" reports things.

h0rn3z0r commented 3 years ago

To make things clear, I am using the latest MPC-HC version (1.9.10) from clsid2 repo and not aware of how MPC-BE and old MPC-HC versions work in this regard. From my experience the "high precision" setting only affects milliseconds visibility. There is one "source of truth" - Navigate -> Go To box which contains current timestamp and it exactly matches the timestamp displayed in status bar, regardless of that setting.

and the time is always 500ms more than what the normal time reports

I cannot confirm that. Maybe your player version or settings are different?

This question needs a closer look to find out how the offset occurs. From my point of view, those time adjustments in Looper are totally unnecessary.

taburineagle commented 3 years ago

Ah, you are indeed correct - I was still using the last "official" MPC-HC build (1.7.13) and the behavior has indeed changed since the last officially released version, so you are correct. I wasn't sure how active the forked MPC-HC build was, so I wasn't using that as a benchmark, so that's me thinking in the past. The latest build of MPC-BE does seem to still use that offset timing though, for some reason, and I do want to keep Looper cross-compatible with both players (as they use the same API). That shouldn't be too hard of a fix to implement in Looper (although it would change how .looper files are loaded/parsed, as all of them from the past 7 years are offset by that 500ms) - however I'm most likely not going to be able to look into this until the end of the week, I have several other deadlines to meet this week.