- July 29, 2020
- 1
- 0
- Home Country
-
United Kingdom
Hello!!!
I use a handy app called catchin' sync to roughly check the AV sync of audio/video on my HTPC/TV. It's not as accurate as a dedicated opto-electronic calibrator but it's more than adequate for this application and much better than trying to do things by eye (even when the lack of sync is massively obvious, subjective tweaking is a rough ride ;-)
After setting up MP2 (auto refresh rate changing enabled) I checked how far ahead or behind audio is for different FPS/refresh rates.
This is what it (consistently and clearly) told me:
23FPS offset = 90 ms out of sync
24FPS offset = 170 ms out of sync
25FPS offset = -30 ms out of sync
29.97FPS offset = -90 ms out of sync
These massive (and more importantly massively different) figures are not all that surprising IMHO. Most displays seem to perform very differently at different refresh rates (and that's even with most - if not all - configurable processing disabled).
The thing is, I couldn't find any way in MP2 to set different audio delays depending on the refresh rate.
Instead i had to come up with a ludicrous workaround (see end of post in case you really want to know!!!)***
The thing is, this isn't a subtle effect. This isn't even arguing the virtues of MadVR vs LAV. This is a massive/obvious/very annoying problem that probably affects anyone who has refresh rate switching enabled, so I have to ask:
(1) Are people just disabling refresh rate switching, sticking to one refresh rate and setting one offset value in LAV Audio if needed? (Simple life but not exactly videophile
)
(2) Are people using a similarly convoluted workaround to me! (You poor fellow OCD suffering people!)
(3) Are people actually tolerating/not noticing as much as 100+ ms of sync disparity (need glasses, much???!!!!)
(4) Something else? Am I missing something? Is there an easier way to achieve this? (I am quite stupid.)
I'm confident the answer is (4) and someone will enlighten me ... Because I'm struggling to believe (1) when we all go to such great lengths to optimise our setups, yet even MP1 doesn't seem to have a built-in method to resolve this pretty major requirement after years and years and years (and years and....) of development.
I also struggle to believe (3). Again, this is a massive/obvious/very annoying problem that probably affects anyone who has refresh rate switching enabled. It's a show-stopper. Perhaps people just give up with HTPC or give-in to compromise? I still find that all hard to believe....
One further question:
(5) Whilst looking at this it became apparent that not only is it essential to solve this problem to resolve very significant lip sync issues, but that reclock (or something similar) is absolutely critical to solve another sync issue: drift in sync due to the inevitable mismatch between GPU and audio clocks. I believe J River has the ultimate solution in VideoClock, which uses the madVR info about the display clock to keep things completely in sync end-to-end. And note, this has nothing to do with the other intended functions of reclock but it is another thing that, surely, should just be part of any serious HTPC software?????
Anyway, please help me out here with this big (if not THE biggest ) first wold question of all time
ATB,
JC
***
(1) Install reclock and make it the audio renderer in MP2, set output to directshow and use it's trigger VBScript function
(2) Install EqualizerAPO (AFAIK sits between audio renderer and audio driver and allows a delay, specified in a text file in ms, to be added to the audio path and can be changed in real-time at any point)
(3) Create VBScript to change the delay setting in the EqualizerAPO text file depending on the fps reported by reclock
(4) If a negative delay is needed this must be set in LAV Audio (see below), so pick the highest figure. A simple calculation is then needed to achieve the required overall offset for each fps
Note:
I use a handy app called catchin' sync to roughly check the AV sync of audio/video on my HTPC/TV. It's not as accurate as a dedicated opto-electronic calibrator but it's more than adequate for this application and much better than trying to do things by eye (even when the lack of sync is massively obvious, subjective tweaking is a rough ride ;-)
After setting up MP2 (auto refresh rate changing enabled) I checked how far ahead or behind audio is for different FPS/refresh rates.
This is what it (consistently and clearly) told me:
23FPS offset = 90 ms out of sync
24FPS offset = 170 ms out of sync
25FPS offset = -30 ms out of sync
29.97FPS offset = -90 ms out of sync
These massive (and more importantly massively different) figures are not all that surprising IMHO. Most displays seem to perform very differently at different refresh rates (and that's even with most - if not all - configurable processing disabled).
The thing is, I couldn't find any way in MP2 to set different audio delays depending on the refresh rate.
Instead i had to come up with a ludicrous workaround (see end of post in case you really want to know!!!)***
The thing is, this isn't a subtle effect. This isn't even arguing the virtues of MadVR vs LAV. This is a massive/obvious/very annoying problem that probably affects anyone who has refresh rate switching enabled, so I have to ask:
(1) Are people just disabling refresh rate switching, sticking to one refresh rate and setting one offset value in LAV Audio if needed? (Simple life but not exactly videophile
)(2) Are people using a similarly convoluted workaround to me! (You poor fellow OCD suffering people!)
(3) Are people actually tolerating/not noticing as much as 100+ ms of sync disparity (need glasses, much???!!!!)
(4) Something else? Am I missing something? Is there an easier way to achieve this? (I am quite stupid.)
I'm confident the answer is (4) and someone will enlighten me
... Because I'm struggling to believe (1) when we all go to such great lengths to optimise our setups, yet even MP1 doesn't seem to have a built-in method to resolve this pretty major requirement after years and years and years (and years and....) of development.I also struggle to believe (3). Again, this is a massive/obvious/very annoying problem that probably affects anyone who has refresh rate switching enabled. It's a show-stopper. Perhaps people just give up with HTPC or give-in to compromise? I still find that all hard to believe....
One further question:
(5) Whilst looking at this it became apparent that not only is it essential to solve this problem to resolve very significant lip sync issues, but that reclock (or something similar) is absolutely critical to solve another sync issue: drift in sync due to the inevitable mismatch between GPU and audio clocks. I believe J River has the ultimate solution in VideoClock, which uses the madVR info about the display clock to keep things completely in sync end-to-end. And note, this has nothing to do with the other intended functions of reclock but it is another thing that, surely, should just be part of any serious HTPC software?????
Anyway, please help me out here with this big (if not THE biggest ) first wold question of all time
ATB,
JC
***
(1) Install reclock and make it the audio renderer in MP2, set output to directshow and use it's trigger VBScript function
(2) Install EqualizerAPO (AFAIK sits between audio renderer and audio driver and allows a delay, specified in a text file in ms, to be added to the audio path and can be changed in real-time at any point)
(3) Create VBScript to change the delay setting in the EqualizerAPO text file depending on the fps reported by reclock
(4) If a negative delay is needed this must be set in LAV Audio (see below), so pick the highest figure. A simple calculation is then needed to achieve the required overall offset for each fps
Note:
- One reason this is necessary is because LAV Audio delay cannot be changed during playback - hence the need for something like EqualizerAPO to adjust the delay once the refresh rate is known.
- If negative settings are needed (audio is late compared to video) - as in my case for 29.973 - you have to do this in LAV Audio. Not sure how it achieves this as presumably it actually means delaying the video (maybe it 'talks' to LAV Video?)
- Reclock has to output to directsound for EqualizerAPO to work (hence WASAPI exclusive/bit perfect is not possible unfortunately)
- From what I gather, reclock messes up live TV as it has no knowledge of the broadcaster clock, so this method may be a non-starter for people with TV cards (including me!), but I need to look into this.
- There's no x64 version of relock so this method dies with x86?
- This workaround only addresses the need to establish a fixed offset for different fps/refresh rate combinations. One improvement would be to, say, make on the fly adjustments with a remote to allow one-off av sync adjustments (i.e. for poorly produced videos) whilst watching. The delay could be stored in a config file that’s associated with the video (for subsequent recall). Though I haven’t established whether I can do this yet.