ARM version of normalize randomly gives wrong results

[nplawes]

brew config AND brew doctor output OR brew gist-logs <formula> link

$ brew config
HOMEBREW_VERSION: 5.0.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: a36eea6fe705eef966f0acd609e471c9b7541a6b
Last commit: 8 days ago
Branch: stable
Core tap JSON: 26 Jan 01:20 UTC
Core cask tap JSON: 26 Jan 01:20 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.dPRivT9okg/org.xquartz:0
HOMEBREW_DOWNLOAD_CONCURRENCY: 24
HOMEBREW_EDITOR: vi
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 12
HOMEBREW_NO_ENV_HINTS: set
Homebrew Ruby: 3.4.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.8/bin/ruby
CPU: dodeca-core 64-bit arm_lobos
Clang: 17.0.0 build 1700
Git: 2.50.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.2-arm64
CLT: 26.2.0.0.1.1764812424
Xcode: N/A
Rosetta 2: false


nick$ brew doctor
Your system is ready to brew.


nick$ brew gist-logs normalize
Error: No logs.

Verification

• My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.
• My issue is not about a failure to build a formula from source.

What were you trying to do (and why)?

Trying to normalize and mp3 file to get the gain

What happened (include all command output)?

On ARM Mac, running the same command 10 times, gives 5 wrong results...

nick$ for i in {1..10} ; do /opt/homebrew/bin/normalize -nq file.mp3 ; done
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
1246.8728dBFS 0.0000dBFS -1258.8728dB file.mp3
414.5950dBFS 0.0000dBFS -426.5950dB file.mp3
2139.7512dBFS 0.0000dBFS -2151.7512dB file.mp3
504.6345dBFS 0.0000dBFS -516.6345dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3

What did you expect to happen?

On Intel Mac, running the same command 10 times is consistent (as expected)

nick$ for i in {1..10} ; do /usr/local/bin/normalize -nq file.mp3 ; done
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3
-8.1750dBFS 0.0000dBFS -3.8250dB file.mp3

Step-by-step reproduction instructions (by running brew commands)

brew install normalize
hash -r
for i in {1..10} ; do normalize -nq file.mp3 ; done

[SMillerDev]

Have you tried reporting this to the developers?

[nplawes]

I looked at the referred bug system from the homepage, but it does not appear active, so felt this was the best place to start. It would at least be good to confirm that someone else can reproduce the problem, since I only have one Mac with Apple Silicon, but many with Intel (and Linux boxes).

I have now submitted a bug report to savannah.nongnu.org, and to the developer on the off-chance it might get noticed

[ooye-sanket]

I’ve been looking into this ARM-specific issue and here’s what I’ve found so far:
What’s going wrong:
The random extreme values (1246dB, 2139dB, etc.) are classic signs of uninitialized variables. On x86, these variables happen to be initialized to reasonable values "by accident" due to how the stack is laid out. On ARM, the stack memory contains different garbage values, exposing the bug.

Why This is Happens:

• ARM and x86 have different calling conventions and stack layouts
• ARM is stricter about memory alignment
• Compiler optimizations differ between architectures
• The bug has likely existed since the original code but was hidden on x86

What I’m planning to do

1. Download and analyze the source code to identify the uninitialized variable(s)
2. Create a minimal patch that initializes the problematic variable(s)
3. Test the patch on ARM
4. Submit a PR to Homebrew with the fix
5. Also report the fix upstream to Savannah (even if inactive) and to Debian maintainers

Help i Need:
@nplawes - Could you share the test MP3 file (or any small MP3) that reproduces this? This will help me verify the fix works correctly.

I'll update this thread as I make progress with the source code analysis.
CC @SMillerDev, @nplawes

[nplawes]

Many thanks for looking into this. Something uninitialised does sound like a recipe for disaster :-( It sounds like it's just plain luck that the normal looking results are right... I have a work-around of looking at the results, and re-running if they look odd.

For me, I think it's all files, but I'll upload a small one.

While looking for a small file I found another bug, which is likely related... I have a small file (probably silence that I created) that x86 silently just exits, and arm works with random values on those odd occasions, and 'normalize: error reading file.mp3' for the others.

test.mp3

nick$ for i in {1..10} ; do normalize -nq test.mp3; done
1848.4580dBFS -25.6339dBFS -1860.4580dB test.mp3
283.3014dBFS -25.6339dBFS -295.3014dB test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3
1164.1697dBFS -25.6339dBFS -1176.1697dB test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3
-40.9682dBFS -25.6339dBFS 28.9682dB  test.mp3

[cho-m]

You may want to try seeing if source build with Debian patch fixes issue:

• https://sources.debian.org/patches/normalize-audio/0.7.7-21/fix-maxpow-initialization.patch/

Given corresponding Debian issue sounds similar:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106841

  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