Package: normalize-audio Version: 0.7.7-17 Dear maintainer,
I observe bad loudness values that encroached my music database via normalize-audio running on an amd64 host. I observed it with an Ubuntu install, but I can reproduce it at the source with the binary from Debian, too. Thing is: I can only reproduce this with Debian/Ubuntu binaries. When I download and build the source archive of normalize-0.7.7, even when applying the Debian patches (most recent tried), the resulting binary works fine. But both the one installed from Ubuntu 22.04.5 LTS (normalize-audio 0.7.7-16) and an extracted binary out of normalize-audio_0.7.7-17_amd64.deb show the bad behaviour. While this only occurs with MP3 files, replacing libmad via LD_LIBRARY_PATH with either of the Debian, Ubuntu or my on build, does not change the outcome. Something in the way normalize-audio itself is built for Debian packaging causes this. I reproduce the issue with these steps: # get any test file, this one is public and small wget https://scm.orgis.org/mpg123/trunk/src/tests/sweep.mp3 A good output looks like this: $ normalize-audio -qn sweep.mp3 -9.3888dBFS -5.1133dBFS -2.6112dB sweep.mp3 A bad output looks like this: $ normalize-audio -qn sweep.mp3 1938.4438dBFS -5.1133dBFS -1950.4438dB sweep.mp3 This occurs randomly: $ for n in $(seq 1 1000); do normalize-audio -qn sweep.mp3; done | grep -v 9.388|wc -l 200 $ for n in $(seq 1 1000); do normalize-audio -qn sweep.mp3; done | grep -v 9.388|wc -l 240 There seems to be a chance of about 20 to 25 % for me that the results of the loudness level and the adjustment are random values (including NaN). The peak value is always correct. Valgrind has one hint: $ valgrind normalize-audio -qn sweep.mp3 ==1799210== Memcheck, a memory error detector ==1799210== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1799210== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==1799210== Command: normalize-audio -qn sweep.mp3 ==1799210== ==1799210== Conditional jump or move depends on uninitialised value(s) ==1799210== at 0x11157A: ??? (in /usr/bin/normalize-audio) ==1799210== by 0x111791: ??? (in /usr/bin/normalize-audio) ==1799210== by 0x488FED2: ??? (in /usr/lib/x86_64-linux-gnu/libmad.so.0.2.1) ==1799210== by 0x4890427: mad_decoder_run (in /usr/lib/x86_64-linux-gnu/libmad.so.0.2.1) ==1799210== by 0x1118A8: ??? (in /usr/bin/normalize-audio) ==1799210== by 0x10E26A: ??? (in /usr/bin/normalize-audio) ==1799210== by 0x10DBD2: ??? (in /usr/bin/normalize-audio) ==1799210== by 0x49F7D8F: (below main) (libc_start_call_main.h:58) ==1799210== -9.3888dBFS -5.1133dBFS -2.6112dB sweep.mp3 ==1799210== ==1799210== HEAP SUMMARY: ==1799210== in use at exit: 0 bytes in 0 blocks ==1799210== total heap usage: 77 allocs, 77 frees, 127,987 bytes allocated ==1799210== ==1799210== All heap blocks were freed -- no leaks are possible ==1799210== ==1799210== Use --track-origins=yes to see where uninitialised values come from ==1799210== For lists of detected and suppressed errors, rerun with: -s ==1799210== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) But it says the same for my self-built normalize binary that so far never gave bad numbers. Also: $ mpg123 -qw sweep.wav sweep.mp3 $ for n in $(seq 1 1000); do normalize-audio -qn sweep.wav; done | grep -v 9.388|wc -l 0 It happens only in the code path for MP3s. But the decoding itself seems good (peak value). Maybe you can at least reproduce this with the correct toolchain and build setup? A little disclaimer: As I'm upstream for mpg123, it itched me at first to just replace libmad usage with libmpg123, but the decoder library itself doesn't seem to be the issue, but the usage of which together with compiler settings, I guess. Alrighty then, Thomas
