Maybe we can make it faster ?

antatura commented 2 years ago

ffmpeg-normalize input.wav -p -n

Runtime: 10.956s

ffmpeg -i input.wav-map a:0 -af ebur128=peak=true:framelog=verbose -f null -

Runtime: 1.922s

slhck commented 2 years ago

This tool is doing two pass normalization. So it will always take at least twice as long as a simple ffmpeg call.

For a better comparison please test the loudnorm filter.

Add to that a little Python startup overhead and the increase in runtime is not unexpected.

antatura commented 2 years ago

En...I will test more. Thanks

slhck commented 2 years ago

➜ hyperfine --warmup 1 'ffmpeg -y -i test/test.wav -af loudnorm -c:a pcm_s16le out.wav' 'ffmpeg-normalize -f test/test.wav'
Benchmark 1: ffmpeg -y -i test/test.wav -af loudnorm -c:a pcm_s16le out.wav
  Time (mean ± σ):     365.1 ms ±   6.9 ms    [User: 325.4 ms, System: 34.8 ms]
  Range (min … max):   356.1 ms … 376.1 ms    10 runs

Benchmark 2: ffmpeg-normalize -f test/test.wav
  Time (mean ± σ):     608.0 ms ±  14.5 ms    [User: 489.7 ms, System: 92.7 ms]
  Range (min … max):   586.9 ms … 626.8 ms    10 runs

Summary
  'ffmpeg -y -i test/test.wav -af loudnorm -c:a pcm_s16le out.wav' ran
    1.67 ± 0.05 times faster than 'ffmpeg-normalize -f test/test.wav'

In these tests, ffmpeg one-pass is 1.67⨉ faster than ffmpeg-normalize on an M1 MacBook Pro.

slhck commented 2 years ago

I don't think this project could be any faster given a) its dependency on ffmpeg and b) the requirement to do two-pass normalization. So I'm closing this for now. If you have a specific suggestion on how to improve the speed, PRs are of course welcome!

slhck / ffmpeg-normalize

Maybe we can make it faster ? #196