Vocal split fails at runtime: librosa 1.0.0 drops audioread, which audio-separator still needs #407

Symptom

Lead/backing vocal split fails on an otherwise successful job. Separation, analysis and beat grid all complete normally.

done device=mps model=htdemucs_6s download=6.8s analyze=7.9s separate=30.4s total=52.7s
W stemdeck.pipeline vocal split failed: No module named 'audioread'
[stemdeck] model warmup: WARMUP_FAILED vocal_split No module named 'audioread'

Reproduced on macOS arm64, StemDeck 0.12.0 runtime pack.

Root cause

librosa 1.0.0 dropped its audioread dependency. audio-separator 0.44.5, which drives the vocal split, was written against librosa <1 and still imports audioread.

pyproject.toml declares librosa>=0.10 with no upper bound. The packaging scripts install with uv pip install "$REPO_ROOT", which resolves fresh from pyproject constraints and does not use uv.lock. So:

• uv.lock resolves librosa 0.11.0, which does depend on audioread
• the shipped runtime resolves librosa 1.0.0, which does not
• audioread is therefore absent from the artifact

Confirmed against an installed runtime pack:

librosa           1.0.0
audioread         *** MISSING ***
standard-aifc     *** MISSING ***   (was pulled in by audioread)
audio-separator   0.44.5
onnxruntime       1.29.0

librosa itself imports fine because 1.0.0 no longer needs audioread, and librosa's own lazy loading means nothing surfaces until audio_separator reaches for it. That is why only the vocal split fails.

Same class of failure as the existing demucs>=4.0.1,<4.1 and torch>=2.6,<2.7 pins: an unbounded upper bound let a breaking major release in.

Why CI did not catch it

All three packaging scripts verify the same stale import list:

• scripts/macos/make-runtime-pack.sh:145
• scripts/windows/make-portable.ps1:224
• scripts/linux/make-portable.sh:138

fastapi, uvicorn, yt_dlp, demucs, torch, torchaudio, librosa, pyloudnorm, soundfile

audio_separator and onnxruntime were added as runtime dependencies for the vocal split (#275) but never added to this check, so a build with a broken vocal-split dependency chain passes and ships. The runtime warmup does detect it (WARMUP_FAILED vocal_split), but only on the user's machine, after release.

Proposed fix

1. Pin librosa>=0.10,<1, with a comment explaining the audioread removal, matching what uv.lock already resolves and what audio-separator expects.
2. Add audioread as an explicit dependency, using the same platform marker as audio-separator, so this survives an eventual move to librosa 1.x.
3. Add audio_separator and onnxruntime to the import verification in all three packaging scripts, platform-guarded so Intel macOS (where the feature is deliberately gated off) still passes.

Related, out of scope here

The packaging installing from pyproject.toml rather than uv.lock is what allowed the shipped artifact to diverge from the lock in the first place. Worth a separate issue.