y-brehm / waveAlign

Python repo for audio loudness matching in order to end the loudness war between DJs.
3 stars 0 forks source link

Issue/4/improve loudness calculation for non sausage tracks #16

Closed y-brehm closed 1 year ago

y-brehm commented 1 year ago

This adds support for windowed loudness calculation with truncated windowing. Truncated windowing becomes a problem in case of a very large window size compared to the length of the input audio array(which will usually not happen). The result of the truncation basically is, that a different window size is used compared to the window size defined by the user, in case the window count does not perfectly fit the length of the audio data. In a real-world scenario this difference will probably only consist of a few hundred samples max and therefore can probably be neglected.

I compared this method to zero-padding the input audio data (for cases where the input length is not a multiple of the window size) and realized that the performance dropped dramatically. I did not use a lot of time for the comparison though, so I added a TODO to investigate this further.

Other than that I also added PEAK and RMS loudness calculation for making this tool also useful for other audio batch-processing tasks. RMS is faster than LUFS calculation but gives less accurate results.

I also addressed some refactorings since I had to touch a lot of stuff.

SimonZimmer commented 1 year ago

Pls also update the README according to the new available options :)

maosi100 commented 1 year ago

General question: why do both of you use double underscores for defining "private" attributes and methods? Apart from the general "everything is public" approach in Python, aren't double underscores reserved for mangling methods to classes and a single underscore should be used to indicate "private"?

see: https://stackoverflow.com/questions/7456807/should-i-use-name-mangling-in-python

SimonZimmer commented 1 year ago

This is a sort of style choice coming from the job. The goal of this style is to write Python in such a way that comes as close as possible to traditional OOP languages like C++ (which is a very special style as one can argue). Because encapsulation is a main concept of trad OOP, access to private methods of a class should be ideally impossible. While that's not doable in Python, the next best thing is name mangling because it is maximally inconvenient and a violation would be spotted with most ease.

I'm aware of some discussions on this but I also don't see any fixed standard for this, so it's a style choice IMO.

Reading through the SO thread, it shows some agreement and some disagreement with this style, so I'd say it illustrates the lack of standard.