[Bug]: samplerate 0.1.0 bundles an x86_64-only dylib on macOS arm64

[flarkflarkflark]

Describe the bug

audio-separator==0.44.3 declares samplerate==0.1.0. On native macOS arm64, the PyPI samplerate-0.1.0-py2.py3-none-any.whl installs successfully but bundles an x86_64-only libsamplerate.dylib, so importing samplerate fails at runtime.

The wheel contents report:

samplerate/_samplerate_data/libsamplerate.dylib: Mach-O 64-bit x86_64 dynamically linked shared library

The same failure was reproduced on a GitHub-hosted Apple Silicon runner:

macOS 14.8.7
ARM64 / arm64
Python 3.12.10

cannot load library '.../samplerate/_samplerate_data/libsamplerate.dylib':
mach-o file, but is an incompatible architecture
(have 'x86_64', need 'arm64e' or 'arm64')

samplerate==0.2.4 publishes a CPython 3.12 macosx_10_13_universal2 wheel and imports successfully on that runner. However, substituting it makes the environment fail pip check because audio-separator pins exactly 0.1.0.

Reproduction

python3.12 -m venv .venv
. .venv/bin/activate
pip install "audio-separator==0.44.3"
python -c "import samplerate"

Expected behavior

The declared samplerate dependency should permit a release with native macOS arm64 support, such as 0.2.4, so a normally resolved audio-separator installation both imports on Apple Silicon and passes pip check.

Would you consider updating the samplerate requirement (globally or with an appropriate platform marker) after confirming compatibility with 0.2.4?

Existing issues checked

I found #284, but that report concerns Linux/aarch64 GH200 installation and does not cover the x86_64-only dylib shipped inside samplerate 0.1.0 on macOS arm64.

[flarkflarkflark]

Thanks for looking into this.

For additional context: this is currently blocking our macOS Apple Silicon upgrade path to audio-separator 0.44.3 in STEMwerk.

We confirmed that:

• audio-separator 0.44.3 installs successfully on macOS arm64;
• the failure only becomes visible when importing samplerate;
• replacing samplerate==0.1.0 with samplerate==0.2.4 fixes the native arm64 import;
• however, pip check then correctly reports a dependency conflict because audio-separator pins 0.1.0 exactly.

So a local dependency override or --no-deps workaround would produce a working runtime, but not a clean or supportable installation. We would strongly prefer an upstream release with a relaxed or platform-specific samplerate requirement.

If helpful, I can also test a pre-release or patched wheel on:

• native Apple Silicon;
• Python 3.12;
• the Demucs and RoFormer model routes used by STEMwerk.

I would also be happy to prepare a small PR adjusting the dependency metadata if you confirm that samplerate>=0.2.4 is acceptable.