Every number here came from running it on this machine. Where something failed, the failure is recorded rather than the alternative quietly substituted.
pip install piper-tts
cd out/tts && python -m piper.download_voices en_US-lessac-medium
python -m piper -m en_US-lessac-medium -f line.wav -i line.txt| measured | |
|---|---|
| model | en_US-lessac-medium.onnx, 60.3 MB |
| load | 8.1s, once per process |
| synthesis | RTF 0.280 — 3.6x realtime on CPU, no GPU |
| output | 22.05 kHz mono 16-bit, mean −15.5 dB, no silence gaps |
| licence | MIT |
Three lines totalling 11.68s of speech synthesised in 3.26s. A 40-second walkthrough narrates in about eleven seconds, so this is comfortably fast enough to regenerate narration on every recut — which matters, because narration that is expensive to redo quietly stops being redone.
Load it ONCE and reuse the voice. The 8.1s is process startup and model load; measuring a single
python -m piper invocation gives 13s wall for 3.6s of audio and reads as 3.6x SLOWER than
realtime, which is the opposite of true.
from piper import PiperVoice
voice = PiperVoice.load("en_US-lessac-medium.onnx") # once
with wave.open(out, "wb") as w: voice.synthesize_wav(text, w)import kokoro segfaults. Exit 139, three runs out of three, before any synthesis call.
Worth recording precisely because I twice reported this wrongly. First as "segfaulted on
synthesis", then as "likely the espeak-ng phonemizer backend". Both were guesses that fit the
symptom. The phonemizer is fine — EspeakG2P returns correct phonemes — and what looked like a
silent crash in one earlier test was a UnicodeEncodeError on \u0259, the schwa, because the
Windows console codepage cannot print IPA. That is an encoding bug in printing, not in speech.
Two different failures wearing the same "no output" costume. The actual crash is at import, and no
amount of PYTHONUTF8=1 touches it.
Kokoro may be excellent elsewhere. On this machine it is unusable, and "82M parameters, Apache-2.0, 54 voices" is a specification rather than a result.
pip install useful-moonshine-onnx
python -c "import moonshine_onnx as m; print(m.transcribe('clip.wav','moonshine/tiny')[0])"Measured on 11.68s of speech across three lines, warm (first call downloads the model and took 100s — that number is a download, not a rate):
| model | speed | transcript |
|---|---|---|
moonshine/tiny |
0.97x realtime | 3/3 exact |
moonshine/base |
0.54x realtime | 3/3 exact |
tiny is roughly twice as fast as base and was no less accurate here, so it is the one to start
with. No torch — it runs on the same onnxruntime Piper uses, which is why it works on a machine
where Kokoro's import segfaults.
THE ACCURACY NUMBER IS WEAKER THAN IT LOOKS, and the weakness is in my test rather than in the model. The audio was generated by Piper, so it is unnaturally clean: one voice, no accent, no background, no crosstalk, no clipping. Exact transcription of synthetic speech does not establish real-world WER, and the published 6.34% figure for Parakeet comes from real benchmark audio which this is not. What these three runs establish is that it runs locally, needs no key, and does not mangle clean input — nothing about a recorded meeting.
Closed loop worth keeping: because Piper generated the audio, the exact text was known before transcribing it, so accuracy could be checked instead of eyeballed. Any future STT candidate can be compared the same way in about a minute.
0.97x realtime on a 32-thread CPU is unremarkable for something built for streaming, and worth saying plainly. It is fine for transcribing a 40-second walkthrough offline; it is not a live captioning engine at this setting.
NVIDIA Parakeet TDT 0.6B v3, ~3 GB, reported 6.34% WER. Not executed here. It needs NeMo and therefore torch, which is the stack Kokoro segfaults inside on this machine, so it is likely to need the same investigation before it produces a file. Search-grade, not a recommendation.