Load the diarization waveform with soundfile instead of torchaudio

[happyarts]

What

The pyannote worker loads the audio for diarization with torchaudio.load and passes it to the pipeline as an in-memory waveform dict. This PR replaces that one call with soundfile — the file at this point is always noScribe's own converted 16 kHz mono PCM WAV, so no decoding backend is needed at all.

Since the worker now imports soundfile directly, it is added to the two Windows requirements files; Linux and macOS already list it explicitly.

Why

• torchaudio.load is deprecated: starting with torchaudio 2.9 it delegates to torchcodec, and torchcodec is hard-paired to both the installed torch version and the system FFmpeg major (e.g. torchcodec 0.7 supports FFmpeg 4–7 only, so it fails to load against current Homebrew FFmpeg 8 and prints a scary-looking warning at startup).
• After this change, noScribe's own code no longer uses torchaudio anywhere — the torch/torchaudio/torchcodec version pairings become pyannote's internal concern only, which makes future dependency upgrades much less entangled.

Scope note

The torchaudio/torchcodec requirement pins are deliberately left untouched here: pyannote.audio declares both as hard dependencies, so they stay installed either way. This PR only removes noScribe's direct use, which is what makes a later pin bump (or dropping the explicit pins) a self-contained follow-up.

Proof

• New test tests/test_pyannote_waveform_load.py: the soundfile-loaded tensor is bit-for-bit identical (torch.equal, not just allclose) to what torchaudio.load returns for the WAV format noScribe produces.
• Verified with a full diarization run on real audio: identical segments and speakers, same speed. The loader is zero-copy for mono (no extra waveform-sized allocation in the worker).

No behavior change intended; the waveform reaching pyannote is byte-identical to before.

🤖 Generated with Claude Code

[happyarts]

Kurzer Kontext zu diesem PR: torchaudio.load ist ab torchaudio 2.9 deprecated (wandert zu torchcodec). Der Diarisierungs-Worker lädt hier nur noScribes eigene konvertierte WAV (16 kHz mono PCM16), dafür reicht soundfile — das ist bereits eine Abhängigkeit unter Linux/macOS und wurde jetzt auch in die Windows-Requirements aufgenommen.

Der neue Loader ist bit-identisch zu torchaudio.load (per torch.equal getestet, Test liegt bei) und zero-copy für Mono. Läuft unverändert auf dem aktuellen wie auf neueren torch-Ständen und ist unabhängig von #327 — beliebige Merge-Reihenfolge.

[kaixxx]

@happyarts Thank you, that looks interesting. However, I will be away on holidays for a few weeks. I will take a look after my return by the end of August, ok?
Best
Kai

[happyarts]

Klar, selbstverständlich. Genieße deinen Urlaub. Ich denke, da kommen noch ein paar Sachen von mir. Der große Brocken, die Integration von Voxtral kommt erst noch - den Teste ich noch ausführlich. Das wird spannend, weil auf Mac 10x so schnell und bessere Qualität als Whisper.

[kaixxx]

Der große Brocken, die Integration von Voxtral kommt erst noch

Nun, da bin ich gespannt. Allerdings wäre es gut, vor solchen großen Änderungen die Architektur gemeinsam zu besprechen. Die eigentliche Transkription ist ja jetzt schon im "transcription_worker" gekapselt. Ich könnte mir vorstellen, hier einen alternativen voxtral worker zu erstellen, mit identischer Kommunikationsschnittstelle. So ließe sich das Transkriptionsbackend leicht wechseln.
Ungünstig fände ich jedoch, wenn die Logik der Kombination von den PyAnnote-Segmenten und den transkribierten Textsegmenten im Hautprogramm stark angepasst werden müsste. Darin stecken die eigentliche Intelligenz von noScribe (wenn es die gibt) und viele Stunden Test und Tweaks, etwa um die Erkennung von Pausen und überlappender Sprache zu optimieren.

[happyarts]

Hi Kai, selbstverständlich, ein neues Modul sollte in die Architektur passen. Die Voxtral-Geschichte war eigentlich eine schnelle Idee, ist dann aber doch größer und komplexer geworden als gedacht. Ich habe ein paar handoptimierte Modellgewichts-Varianten gebaut und auf HF hochgeladen (alle getestet), die Erkennung von Wortwiederholungen und das saubere Lösen derselben ist echt tricky, ich (genauer: die KI für mich) habe einen Bug im torchaudio gefunden und ich tune das Modul gerade noch in einigen Kleinigkeiten.

Damit das sauber ist halte ich den Voxtral-Teil ja zurück, bis die kleinen PRs durch sind. Du kannst schon schauen: https://github.com/happyarts/noScribe/tree/feature/voxtral-engine und gern Wünsche / Vorschläge / Ideen äußern.

Zur Beruhigung vorab: Die Integration folgt exakt dem Muster, das du beschreibst. Es gibt einen eigenen voxtral_mp_worker als Subprozess, der das Message-Protokoll des whisper_mp_worker 1:1 spiegelt (log/progress/segment/result) — im Hauptprogramm wählt die Engine-Auswahl nur den Entrypoint, beide laufen durch denselben on_segment-Pfad. Die Kombinationslogik mit den PyAnnote-Segmenten (Pausen, überlappende Sprache etc.) bleibt unangetastet; die Engine liefert lediglich Segmente mit Wort-Timestamps in demselben Format.

Markus

[kaixxx]

Alles klar, das hört sich interessant an. Dann schauen wir mal.