jiixyj / libebur128

A library implementing the EBU R128 loudness standard.
MIT License
402 stars 76 forks source link

Thoughts on improving performance #122

Open guillaumekh opened 2 years ago

guillaumekh commented 2 years ago

libebur128's performance is well suited for live streams, but it can be a bit slow when working with files, especially large ones.

For example, running loudness-scanner w/ TP detection takes about 2 minutes to scan a 2 hours WAV file on my development machine.

Has anyone given some thoughts on how to improve the library's performance?

I have considered the following at this point:

It's probably worth noting my employer is open to contracting w/ someone to work on this.

sdroege commented 2 years ago

multithreading: looking at the algorithm's spec (see FIGURE 1, page 3), it seems that at the very least it should be possible to parallelize the first stages on a per-channel basis. I'm also wondering if it would be possible to divide a file into multiple segments, and distribute analysis of those over multiple threads.

We did some experimenting with that in a Rust port of this library. Multi-threading wasn't really worth it there in the bigger picture when doing chunked analysis, see https://github.com/sdroege/ebur128/pull/42#issuecomment-798969214 specifically and the whole PR. There's Rust API now for doing chunked processing from the application side though.

There might be other approaches to multi-threading that are more worthwhile though, or maybe chunked processing speeds up everything considerably for your use-case.

FWIW, the Rust port is slightly faster than the C version by some other optimizations but not 3x-4x faster. How much depends on your setup.

caustik commented 1 year ago

I was able to optimize short-term and momentary full-file analysis by chunking the audio across the number of available threads and then adding some "preroll" aligned to the block boundary for each thread. Of course create unit tests to validate your results are identical to sequential processing. This doesn't handle integrated, but for my particular use case I didn't need that anyway.