Producing twenty-nine voiced locales offline
Can a full multi-language voice set for a children’s app be produced locally on one GPU, with no paid speech API and no per-character billing?
Started · Updated
An app for children under six is a voice-first product: the audience cannot read, so every prompt, number and reward has to be spoken. Localising it the usual way means a text-to-speech vendor, a per-character bill that scales with every content change, and a dependency that has to stay funded for the lifetime of the app.
We produced the entire package offline instead — two speakers across twenty-nine locales, plus a separate, gentler set of takes for two- and three-year-olds on the counting and colour lines, fifteen music tracks and eight sound effects. Every line has a manifest entry recording its text, file, the model that generated it and its QA result, and every music and sound file carries a per-file licence record.
What the automation could not do is judge whether a line sounds right to a child in a language nobody on the team speaks. That part stayed human, and the package ships with a listening checklist that says so explicitly rather than implying the QA was complete.
What we learned
Findings so far.
- 01
Format is a platform decision, not a preference. The brief asked for Opus; iOS routes Flutter audio through AVPlayer, which has no Opus or OGG decoder, so an Opus-only build is silent on iPhone. The package ships AAC-LC in .m4a as the default and keeps Opus as an Android-only alternative with identical file names.
- 02
A locale fallback chain has to be designed, not improvised. Exact locale, then base language, then English — written down once and honoured by the player.
- 03
Provenance is cheap at production time and expensive to reconstruct later. Recording the model, licence and QA result per file while generating it cost nothing; recovering that afterwards would have meant regenerating everything.
About Pivumo
This experiment came out of building Pivumo.