henryk86
commented
3 months ago This seems to fix Issue #101. I may be misunderstanding Hamming Window, but it seems like it should be used for parts of the audio that go above the limit and that you want to bring back to within the limits, but still preserve the effect by smoothing it out. The fact that we were applying this to the whole recording made the start and end of the audio file quiet, but the middle the loudest. I honestly don't think we should be changing the recording in any way. Users can and likely should be doing that through external tools, such as Audacity. It has features such as Normalization, which would likely accomplish what this hamming window was trying to do.
First thank you for the deep analysis and removing the hamming window.
The hamming window was recommended by chatgpt (Chatgpt is still stupid, you have to verify everything it generates, I failed here). The problematic sound file sounds fine afterwards, but I missed to check another previously good working sound file. So the actual bugfix to the previous bug was the min max adding some lines later and would have been sufficient. So removing the hamming window is completely fine. And yes we should not modify the sound file in such way which is technically not necessary.
This seems to fix Issue #101. I may be misunderstanding Hamming Window, but it seems like it should be used for parts of the audio that go above the limit and that you want to bring back to within the limits, but still preserve the effect by smoothing it out. The fact that we were applying this to the whole recording made the start and end of the audio file quiet, but the middle the loudest. I honestly don't think we should be changing the recording in any way. Users can and likely should be doing that through external tools, such as Audacity. It has features such as Normalization, which would likely accomplish what this hamming window was trying to do.