Improve flexibility of Meter.integrated_loudness
I have a few simple suggestions to improve the flexibility of Meter.integrated_loudness:
- return the times at which the loudness was calculated
- make the hop-size a parameter that can be set by the user
- could the block size also be a parameter? It does not seem to be used anywhere else
sorry, the time vector does not make sense. Since it's integrated. I was looking for a block wise loudness estimate. Maybe I'll code it. Would it be interesting for pyloudnorm?
Hi @f-brinkmann,
I think there is some interest in expanding the interface for loudness measurement. This may be easiest to implement with a new purely functional interface.
As you mentioned, currently we only return the final integrated measurement, but there has been a lot of interest in the short-term and momentary loudness measurements, that are also defined in the standard. These measurements would also require a new interface since they would return a set of time points with the loudness measurements at each of those points.
Did you have any specific use-cases in mind?
What do you mean by hop-size? Is this difference from block size?
Hi!
someone asked me, if I could quickly compute loudness curves for classic performances that's why I was looking into it. I did a very quick hack to return the intermediate results along with the time-stamps without looking for further information/recommendations in the standard: https://github.com/f-brinkmann/pyloudnorm/commit/54a3a427c1a59a5acf3841a88331e2a01e5ac963
One thought I had that might keep the re-coding to a minimum was to move most of the functionality in integrated_loudness to a private function, e.g., _loudness that does the common processing (if possible). integrated_loudness would then only do the averaging. A new function, e.g., instanteneous_loudness could do other specific processing and return the time-dependent values. For the new function, I thought more control over the block_size and overlap (thats what I ment with hop-size) might be nice.