search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.24k stars 2.9k forks source link

Possible audio artifacts using speed=1.001 on Windows 10 (mpv 0.8.0 precompiled by lachs0r) #1610

Closed SSCBryce closed 9 years ago

SSCBryce commented 9 years ago

So, using default wasapi, or dsound produces the same affect. ao=pcm even creates files that sound just as distorted, and playing the file in Foobar also sounds the same. So here I've simply encoded roughly she same amount of time from the dump with the only difference being with speed=1.001 and the other without. They have no other playback options or anything related to ao.

https://a.pomf.se/sovadz.7z

I've confirmed with other people running Windows (not that that should matter), and they can hear it. You're looking for a choppiness effect that's particularly audible when the symbol instrument clashes near the end.

mia-0 commented 9 years ago

The scaletempo filter sounds choppy, yes. That’s what we hoped af=rubberband would fix.

SSCBryce commented 9 years ago

Hoped? Is it not refined yet then, and that's why it's not default? Or are you tossing it away? I was advised to post here about this, so sorry this is turning into tech support.

mia-0 commented 9 years ago

It’s not the default for several reasons.

  1. It’s mostly untested
  2. It requires quite a bit of CPU time even when it should be a no-op
  3. It also currently causes timing issues that may lead to video stuttering
SSCBryce commented 9 years ago

Well I guess the testing on that begins instead. Just running with

speed=1.001 af=rubberband

in mpv.conf makes things sound instead of choppy, but like they're in a tin can or something. And that manual page for rubberband is the most scary thing I've seen since the blob when I was very young. Any suggestions for extra parameters that matter to play with?

mia-0 commented 9 years ago

Unfortunately, nothing specific comes to mind because all parameters affect how tinny rubberband sounds. But maybe try af=rubberband=channels=together. It has some other negative side-effects but could at least help for stereo channels.

SSCBryce commented 9 years ago

Wait wait wait. Are you sure you understood correctly? Unless --speed implies scaletempo, I wasn't using it. Shouldn't it be possible to increase speed and just let the audio sound slightly higher pitched without choppiness? Considering 1.001 would hardly change how it sounds, no?

mia-0 commented 9 years ago

Use audio-pitch-correction=no in that case.

SSCBryce commented 9 years ago

Ohhh, so it was audio-pitch-correction that was causing that, not scaletempo? But that makes it weird that our problems were lining up so well anyway. Something doesn't make sense here. Some questions: Can =no be used on anything?

And, I feel like this is almost cheating, coming from reclock. Is there a way to also get this thing to sync to vsync refreshes too? There's no way this would be judder-free... right? That's all I was seeking with this in the first place, and I didn't read anywhere that these things were all implied.

mia-0 commented 9 years ago

audio-pitch-correction defaults to yes, which will add the scaletempo filter as needed.

Whether this is judder-free depends on a few factors. Timing accuracy of audio output and filters, driver vsync behavior, and whether the display refresh rate is evenly divisible by the video refresh rate. If it all works out, it should be judder-free with your speed option when watching at refresh rates that are a multiple of the video frame rate (e.g. 48 Hz or 72 Hz, maybe 24 Hz).

You could completely avoid this trick by setting a custom display mode with a refresh rate of around 71.93 Hz (remember, display EDIDs lie, check the spec sheet of your monitor for whether it supports more than 60 Hz).

SSCBryce commented 9 years ago

Mine's actually at 120hz, I believe that multiples in just fine with speed=1.001 on 23.976 content, right? So I think that's all the settings I can change that would matter...

Anyway though, about this post, maybe I'd advise disabling scaletempo, or audio-pitch-correction completely even if speed is used on Windows? Seems like everyone I know has the same problem, and considering most people want to do what I'm doing (speeding up 23.976 to 24), this might save headaches. And of course you could keep it like that only until you have a better solution. And they would still be in the docs, so it's not like people can't find them and try them out for themselves if they want.

SSCBryce commented 9 years ago

Anyway, glad this isn't a bug or anything. Thanks for the help.

ghost commented 9 years ago

Anyway though, about this post, maybe I'd advise disabling scaletempo, or audio-pitch-correction completely even if speed is used on Windows? Seems like everyone I know has the same problem,

We've just switched it to use scaletempo, because people complained...