Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Improve flexibility of Meter.integrated_loudness #43

Open
f-brinkmann opened this issue Dec 19, 2022 · 2 comments
Open

Improve flexibility of Meter.integrated_loudness #43

f-brinkmann opened this issue Dec 19, 2022 · 2 comments

Comments

@f-brinkmann
Copy link

f-brinkmann commented Dec 19, 2022

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?

@csteinmetz1
Copy link
Owner

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?

@f-brinkmann
Copy link
Author

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: f-brinkmann@54a3a42

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants