Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[Question] Volume normalization #10767

Closed
GeryHasd32 opened this issue Oct 21, 2022 · 15 comments
Closed

[Question] Volume normalization #10767

GeryHasd32 opened this issue Oct 21, 2022 · 15 comments

Comments

@GeryHasd32
Copy link

Does anyone know how to enable volume normalization like the one implemented in SMPlayer?

Thanks for the answer.

@CounterPillow
Copy link
Contributor

There are two ffmpeg filters for this which you can use through the --af option:

@richardpl
Copy link
Contributor

@GerryHasd32
Copy link

There are two ffmpeg filters for this which you can use through the --af option:

and speechnorm: https://ffmpeg.org/ffmpeg-filters.html#speechnorm

Thank you, of course, for the set of links to help informations, but I'm interested in a ready-made, tested variant that works adequately, so that you can write the appropriate parameter in mpv.conf, and not read the documentation and sort through options.

I tried several blanks earlier (I saw them somewhere on github or reddit) with both dynaudnorm and loudnorm, but none of them gave me the desired result.

SMPlayer is built on mpv, so this parameter should work with it as well, maybe someone was looking for it, let me know.

@richardpl
Copy link
Contributor

The only normalization I see in code of smplayer is volnorm, very fragile and abandoned filter from mpv side. The only other filter used in smplayer is acompressor without any parameters provided.

@GerryHasd32
Copy link

The only normalization I see in code of smplayer is volnorm, very fragile and abandoned filter from mpv side. The only other filter used in smplayer is acompressor without any parameters provided.

Maybe he is very fragile filter, but I was satisfied with his work in the SMPlayer.

Perhaps you know of another ready-made, tested and working parameter for mpv.conf?

@richardpl
Copy link
Contributor

Are you sure your smplayer installation is still using volnorm? What smplayer version you use?
I really doubt you actually use volnorm, unless you still use old mpv with old smplayer?

@hooke007
Copy link
Contributor

I check the lateset version of smplayer and get the following info from log.

--af-add=lavfi=[acompressor]
--af-add=@aeq:lavfi=[firequalizer=gain='cubic_interpolate(f)':zero_phase=on:wfunc=tukey:delay=0.027:gain_entry='entry(0,0);entry(62.5,0);entry(125,0);entry(250,0);entry(500,0);entry(1000,0);entry(2000,0);entry(4000,0);entry(8000,0);entry(16000,0)']

@lf94
Copy link

lf94 commented Jan 6, 2023

It'd be great if there was simply 3 options to invoke sensible parameters for these three filters! Such as --normalize="loudnorm", etc.

@richardpl
Copy link
Contributor

Never use loudnorm in single-pass, it is very bad.

@lf94
Copy link

lf94 commented Jan 6, 2023

It was just a suggestion for a syntax that could be used; and yeah that's even better to only show filters that are most fitting for this case :) I wouldn't know, but people like you do! :D

@lf94
Copy link

lf94 commented Jan 6, 2023

I want to be clear, this option is vital for when playing through personal audio collections (which I've gone back to doing after abandoning Spotify and Youtube Music). The volume range is extremely variable. Passing a --normalize would be so nice on any device. mpv has a lot of nice simple options like this, but not for normalization.

@lf94
Copy link

lf94 commented Jan 6, 2023

I did a quick 30 minute search around the web for invocations of dynaudnorm (seems to be the appropriate filter for this kind of problem), for anyone curious:

dynaudnorm=p=1/sqrt(2):m=100:s=12:g=15
dynaudnorm=f=150
dynaudnorm=f=200
dynaudnorm=p=0.9
dynaudnorm=g=7
dynaudnorm (bare, no parameters applied)

@lf94
Copy link

lf94 commented Jan 6, 2023

Using just dynaudnorm on its own is actually sufficient! Testing it here and really there's nothing particularly wrong with it. I would suggest just updating documentation to make it more obvious, or to make a --normalize option that is just an alias for --af=dynaudnorm.

@richardpl
Copy link
Contributor

dynaudnorm is dynamic normalization, and that may not be always wanted, but with big frame sizes and/or gausssize you will get behavior that is very similar but never same to offline normalization in 2 pass.

@lf94
Copy link

lf94 commented Jan 6, 2023

Right, but for the average case I think it's suitable - it's certainly doing the job here!

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

7 participants