Local ASR (Speech-to-Text)
Comparative review of three local speech-to-text approaches tried across separate projects: Meta's omnilingual_asr, Microsoft's VibeVoice-ASR, and onnx-asr.
Evaluated 2026-08-11, covering work from 2026-08-01 through today.
What we needed
- Offline/local transcription — no cloud STT dependency
- Works without a baby-sat persistent server
- Tolerable on CPU, since the one 3090 in the house is usually pinned near 24GB by a standing ComfyUI process
- Good enough accuracy for both short voice notes and longer batch jobs (talks, multi-hour recordings)
- Minimal install/setup footprint
Approaches
Meta omnilingual_asr (omniASR_LLM_3B_v2)
Used in ~/asr-test (2026-08-02/03) for a large Hindi (hin_Deva) batch transcription job — a hand-built pipeline: slice audio into clips, build a manifest, transcribe in batches of 8 with resume-from-checkpoint support, merge translations.
Verdict: not adopted going forward. It worked, but it's a bespoke script around a 3B model, not a tool — no CLI, no reusable driver, 7.6GB of venv + intermediate artifacts for one job. Right choice for a big one-off multilingual batch job; wrong choice as a general-purpose default.
Microsoft VibeVoice-ASR (raw fallback)
Used in ~/code/vibevoice-transcribe (2026-08-01) to transcribe a set of conference talks. The intended path — a persistent vibevoice-server — is broken: it crashes on model load because transformers 5.14.1 dropped the eager-attention fallback VibeVoice's tokenizer encoder needs, and the server CLI exposes no way to force it. Workaround was run_raw_transcribe.py, which loads the model directly from the VibeVoice repo venv on every invocation (tries sdpa then eager), rather than talking to a long-running server.
Verdict: not adopted going forward. Functional once you build the workaround, but fragile — a broken server, a hand-rolled reload-per-run driver, 12GB footprint, and a transformers-version landmine that will resurface on any upgrade.
onnx-asr (CLI)
Reached for today to transcribe a WhatsApp voice note. Already installed as a uv tool — no project setup at all.
whisper-base: garbled/incomplete output. Skip it.nemo-parakeet-tdt-0.6b-v2with--vad silero: clean, correctly-segmented transcript on the first real attempt.
Runs CPU-only here — its isolated uv tool venv doesn't bundle cuDNN/TensorRT (unlike the two projects above, which pull nvidia-cudnn-cu12 via pip into their own venvs), so onnxruntime logs EP-load errors and falls back automatically. Not a functional problem, just slower: a ~90-second clip took a couple of minutes. Total footprint: ~526MB tool + ~2.8GB model cache, an order of magnitude lighter than either alternative above.
Verdict: recommended. One CLI invocation, no server to babysit, no crash history, good accuracy with the right model. Default going forward for anything short-to-medium; if a large batch job needs GPU throughput, install nvidia-cudnn-cu12 into a dedicated venv rather than relying on the uv tool isolation, and reconsider omnilingual_asr only if the content is heavily non-English (its multilingual coverage is broader than Parakeet's).
Housekeeping
~/asr-test (7.6GB) and ~/code/vibevoice-transcribe (12GB) were deleted 2026-08-11 — both fully wrapped, Gavin confirmed disposable.
Addendum, 2026-09-01: this review has a blind spot, and it bit
Three weeks after onnx-asr was installed and recommended above, a session told Gavin "there's no speech-to-text tool available on this box" in response to an uncaptioned voice note — flatly false. onnx-asr was still sitting installed at ~/.local/bin/onnx-asr. After Gavin suggested two GitHub repos in reply, a second tool (hyperpuncher/chough, a Go binary bundling sherpa-onnx/Whisper-ONNX) got installed instead of the existing one getting rediscovered.
Root cause, confirmed by actually testing it rather than assuming: memory_search across every corpus (memory, wiki, all) returns zero hits for "onnx-asr", "ASR", or "transcription". This review site is not part of any searchable memory corpus. Writing a tool decision up here, however thoroughly, does not make it recallable — the only thing that would have caught this in the moment was grepping installed CLI tools directly (uv tool list), which nobody thought to do because the actual documented answer already existed and "no way to transcribe" should have been suspicious on its face.
Verdict on the review site itself: adequate as a reference, not adopted as an operational memory substitute. Anything meant to be recalled by a future session — not just read by a human doing a retrospective — needs a line in TOOLS.md or the memory system too. This site is for humans dogfooding tools; it's not what an agent checks before making a capability claim.
No comparison done yet between onnx-asr (CPU-only, proven) and chough (untested GPU claim) now that both exist side by side — see TOOLS.md for the redundant-tool note until one gets retired.