Contents
Audio (text-to-speech) quality verdict
A calibrated assessment of the minisite's generated speech - the "listen to this page" narrations and the two-voice audio overview ("podcast"). All of it is synthesised on the box, nothing leaving the building. This page exists because getting local speech to sound human took real iteration, and that process is itself a useful result: it shows how you would actually approach voice for an on-prem system, and where the ceiling currently sits.
The process (how you actually approach this)
Voice quality cannot be judged from a spec sheet, only by ear. So we ran a small human-in-the-loop evaluation: pick a candidate engine, generate the same lines, listen, keep or reject, and record why. Three engines, in order:
| Engine | Size | Verdict by ear | Why |
|---|---|---|---|
| Piper (medium) | ~20M | rejected | Flat, monotone - "news reader" delivery, the male voice especially. Expressiveness knobs helped marginally; the model class was the limit. |
| Kokoro-82M | 82M | rejected | More natural than Piper, and post-processing (reverb/EQ/loudness) + speed and arrangement all helped - but still read as robotic. Post-processing cannot rescue a flat synthesiser; it just puts a flat voice in a nicer room. |
| Chatterbox (Resemble AI) | ~0.5B | adopted (for now) | Its emotion-exaggeration control gives genuinely expressive delivery. Good enough to feature. |
The pattern is the real lesson: quality tracks model scale here, and the fix for "robotic" was a bigger, more expressive model, not more knob-twiddling on a small one.
What is running now
The podcast uses Chatterbox on the box (CPU via torch), with the expression setting a human picked by ear. It is voiced locally - nothing uploaded. The "listen to this page" narrations remain Piper for now (a utilitarian read-aloud, where flat is acceptable).
The realistic ceiling: still not NotebookLM
Even Chatterbox does not match a polished cloud product such as Google NotebookLM, and that gap is worth stating plainly, because it is exactly the trade-off this whole report is about:
- NotebookLM is a cloud service. To get that broadcast-smooth, banter-rich result, your source material is uploaded and processed off-device - it leaves the building.
- Local TTS keeps everything on the box - private, free at the margin - in return for speech that is now good, but not yet studio-grade.
What a production system would add (deferred, on purpose)
We stopped at "good enough to feature", not "fully optimised", because past this point the work is a project of its own. If this became a production system, the next step is a proper voice-evaluation session: test several base voices, blind A/B them, script the dialogue in a deliberately conversational ("messy") style, tune per-speaker expression, and layer the arrangement more carefully. That is scoped as future work, not done here - and knowing where to draw that line is part of approaching a project like this realistically.
Hear the difference
The original Piper version is kept alongside the current one so you can hear what human testing rejected and what replaced it. Your ear is the only test that counts.
Bottom line
| Local (on-box) | Cloud (e.g. NotebookLM) | |
|---|---|---|
| Privacy | nothing leaves the building | content uploaded off-device |
| Cost | free at the margin | per-use / subscription |
| Quality | good, expressive, not studio-grade | broadcast-smooth |
| Best for | private narration, internal overviews | public, polish-first audio |
Use local TTS when the material is sensitive or the volume is high; reach for a cloud generator only when the audio itself is the product and the content is not sensitive.