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

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.

Inspect the dependency declaration for the exact samplerate==0.1.0 pin and review the compatibility impact of samplerate 0.2.4. Reproduce the issue with the provided Python 3.12 macOS arm64 commands, then verify that a normally resolved installation imports samplerate and passes pip check.