I understand your tests were done with the special build I posted.
When audio is fine it's locked at 100% for the duration, otherwise it is cycling 98-100-102-100-98-100-102.
That's is the key. And I'm almost sure you didn't notice any scroll stutter or visible performance drop on the video, did you?
That would point to wrong time measurement by MAME. I've seen it before. I believe this started to happen when the core was "modernized" to use std::chrono instead of directly handing Windows timing API calls.
Back then we had to change std::chrono to use the "steady clock" instead of the "high resolution clock", otherwise it would cause the exact issue you're seeing when running on XP. Windows 7 seemed to work fine with both. The build I posted yesterday uses the high resolution clock instead, just like baseline MAME.
This bogus speed information wouldn't be an issue if it wasn't because GroovyMAME uses it as feedback for the audio sync feature, causing it to wobble.
In the old days the speed information was so stable with syncrefresh on that I decided to remove "audio sync" as a separate option. Maybe it's time to readd this option, although I hate doing it.
My guess is that it's the interaction between the actual pixelclock and the granularity of the system clock what's probably causing the issue.
You may try changing your system's clock source. Check the posts by Dr.Venom
here.