A Spring Break Commute, Five Dollars, and the State of Multilingual Text-to-Speech
Most people’s mental model of AI stops at the chat window. Type a question, get an answer, move on. That framing made sense in 2023 when a…
A Spring Break Commute, Five Dollars, and the State of Multilingual Text-to-Speech



Most people’s mental model of AI stops at the chat window. Type a question, get an answer, move on. That framing made sense in 2023 when a chatbot was the most visible thing these models could do, but it misses what is actually on the table now: composable APIs covering language, translation, speech, vision, and audio generation that a single developer can wire together over a weekend for a cost that rounds to nothing. Most people have not looked past the chat window to see any of it.
Problem classes that once required a localization team, a recording studio, or a dedicated engineering org now fit inside a personal project. Smaller teams can take on harder problems than they could two years ago, not incrementally harder but categorically harder. Most are not doing this yet, because the gap between “I can use ChatGPT” and “I can build a multilingual audio pipeline” still feels wider than it is. This is a concrete example of crossing it.
Spring break changed what I thought the app was for.
I built the Metro DC app to track commutes, live train arrivals, neighborhood context, the stuff a daily rider needs. I wrote about it here a few months ago: 7,400 lines across 40 commits, built entirely on an iPhone during actual rides, including a section that examined how AI-generated neighborhood summaries reproduced bias in ways that only became visible because I was physically riding through the neighborhoods in sequence.
Then spring break happened. I got on the Metro mid-morning and the train felt different. The usual crowd, workers with laptops, people with coffee, the quiet efficiency of a city on schedule, had been replaced by families with maps, international visitors reading station signs carefully, people who had never ridden this system and were trying to figure it out in real time. Those same stations I had ridden hundreds of times stood, for these people, at the front door of a city they had traveled to experience.
No usage dashboard would have surfaced that shift. The commute logs, the station taps, the engagement curves, none of it would have shown me that the person using the Smithsonian stop on a Tuesday in April brought a completely different set of needs from the person using it on a Tuesday in February. I had to be on the train.
The app I had built did not serve those people. It served the commuter I was. Neighborhood summaries optimized for someone who already knows the city bear no resemblance to a guided experience for someone who arrived that morning from Lisbon or Seoul or Beijing and wants to know what is worth seeing, how to get there, and what they are looking at when they arrive.
That realization pointed at a specific answer: narrated guided tours of DC sights fully accessible by Metro, delivered in the visitor’s own language. The app already knew the stations and the neighborhoods and could generate the content. The missing piece was turning that text into audio across multiple languages.
What I did not fully register until I started pricing the work: a single developer, spending less than five dollars, can now generate both the translated text and natural-sounding narration across multiple languages. Not rough synthetic audio. Not machine-translated copy that reads like a terms-of-service document. Text that reads like a person wrote it and audio that sounds like a person recorded it, at a cost that would not cover a coffee in the city those tourists are trying to explore.
What the old approach looked like
Concatenative synthesis dominated through most of the 2000s and into the 2010s. The basic idea: record a human speaker producing thousands of phonemes and diphones, catalog them into a database, then stitch them together at runtime to produce arbitrary text. Festival Text-To-Speech (TTS) worked this way. Early Nuance systems worked this way. The results functioned the way a bad photocopy functions, the information present but something fundamentally off about the texture.
The multilingual problem in this world multiplied rather than scaled. Each language demanded separate recording sessions, a different trained speaker, its own phoneme inventory, and prosody rules built from scratch. A company wanting decent English, Spanish, and French TTS had to build three essentially separate systems, license three sets of voice talent, maintain three pipelines. German and Japanese required entirely different approaches to word segmentation and phoneme mapping. The cost did not scale; it compounded.
Formant synthesis, the other major approach, performed worse. eSpeak, still actively developed, uses this method and supports over 100 languages today, impressive until you hear it. The voice passes as speech, but nobody would mistake it for a person. Multilingual breadth came at the cost of sounding like a 1980s telephone Interactive Voice Recording (IVR), otherwise known as “Press 1 for X, Press 2 for Y”, in every language it supported.
WaveNet and what changed structurally
DeepMind published WaveNet in 2016, not just improving TTS quality but changing what the field thought was achievable. Rather than assembling speech from stored phoneme fragments, WaveNet modeled audio waveforms directly using a deep convolutional neural network trained on raw audio data. Google integrated it into Cloud TTS around 2018.
Transfer learning changed the economics of multilingual support. Neural TTS models share learned representations across languages, a model trained on large amounts of English audio picking up something about prosody, rhythm, and acoustic modeling that transfers, partially, to other languages. You still need training data in the target language, but the architecture does not start from scratch. That bendable cost curve made the current landscape possible.
What Google Cloud TTS actually offers (04/2026)
The current lineup runs five tiers: Standard, WaveNet, Neural2, Studio, and Chirp.
Standard is the legacy tier, cheapest at around $4 per million characters, widest language coverage, noticeably weaker quality. Fine for system alerts. Not competitive for anything a person is meant to enjoy listening to.
WaveNet delivered the first neural generation, quality meaningfully better than Standard, priced around $16 per million characters. These held the quality crown for a few years before Neural2 shipped.
Neural2 is the practical default for most production use today, trained on a different architecture from WaveNet, producing more natural intonation and rhythm at similar pricing. The difference is audible. For most production use cases, Neural2 is the right starting point.
Studio targets content creation rather than dynamic generation, priced around $160 per million characters, voices genuinely hard to distinguish from a recorded professional. For a high-volume real-time pipeline that price creates problems. For producing a catalog of neighborhood audio tours cached and served on demand, the math gets more interesting.
Chirp is Google’s newest architecture, built on a large audio language model trained across multiple languages simultaneously, multilingual support built into the training architecture from the start rather than added as a feature afterward. Chirp handles code-switching, mixing languages within a single audio segment, more naturally than any earlier tier, the model carrying both languages in the same learned space rather than context-switching between separate modules. For an app serving an international audience that mixes English with their native language within a single prompt, this distinction matters.
SSML (Speech Synthesis Markup Language) is what makes multilingual output programmable. You tag individual segments with their language, control rate and pitch, insert pauses, handle proper nouns. A neighborhood name like “Anacostia” requires different phoneme handling depending on whether it appears mid-sentence in an English narration or mid-sentence in a Spanish one. Here is what that actually looks like in the pipeline:
<speak>
Welcome to <phoneme alphabet="ipa" ph="ˌænəˈkɑːstiə">Anacostia</phoneme>,
one of DC's oldest neighborhoods, named for the Nacotchtank people
who lived along this river for thousands of years.
</speak>
<speak>
<lang xml:lang="es-US">
Bienvenidos a <phoneme alphabet="ipa" ph="ˌænəˈkɑːstiə">Anacostia</phoneme>,
uno de los barrios más antiguos de DC, con una historia que se remonta
al pueblo Nacotchtank.
</lang>
</speak>
Both go to the same endpoint. Chirp handles the phoneme context differently for each without requiring two separate API integrations or two separate voice configurations.
ElevenLabs and Azure in the same evaluation
ElevenLabs produces some of the most natural-sounding speech available. Voice cloning, training a custom voice from a short audio sample, is their differentiating feature and it works. For the Metro DC tour use case, a consistent narrator voice across all stations matters. ElevenLabs handles that well. Language breadth is the limitation; their coverage runs narrower than Google’s, and the free tier restricts serious evaluation. For applications where voice identity and realism dominate and language count stays modest, ElevenLabs is the stronger option. For a pipeline that needs to handle whatever language a user arrives with, Google scales more cleanly.
Azure Cognitive Services TTS runs quality-competitive with Neural2, covers a broad language set, and prices similarly. If the rest of your infrastructure already lives in Azure the integration is simpler. I ran it alongside Google and found quality roughly equivalent across the languages I was prioritizing; tooling fit drove the decision, not output quality.
What this unlocks beyond the app
The deeper pattern here has less to do with TTS than with where product decisions come from when you are both the builder and the user. The bias observation from my last article, AI-generated summaries reproducing coded language for lower-income stations, only surfaced because I was riding through those neighborhoods in sequence. This feature started from sitting on a car full of tourists during spring break. Both came from being on the train, not from a planning document. Product managers talk about eating your own dog food as if the lesson is catching bugs before users do. The actual lesson is that you keep running into users you never planned for.
The Metro DC tour was the forcing function, but the same architecture applies anywhere you generate structured text with a language model and want that output to reach a user through audio rather than a screen.
Documentation narration is one case. Codebases increasingly carry AI-generated summaries at the module and function level, and piping those through a TTS pipeline produces audio walkthroughs, usable during commutes, accessible for users with visual impairments, available in the developer’s native language, using the same three-step pipeline: translate, select tier, synthesize. Accessibility pipelines work the same way. Most web applications generate substantial dynamic text, dashboards, alerts, status updates, generated reports, content that screen readers handle inconsistently and multilingual users consume in translation. A TTS layer sitting between text generation and the user, selecting voice and language dynamically based on user profile, turns an afterthought into a first-class feature.
Content localization is where the economics flip most visibly. Before neural TTS, localizing audio content meant booking studio time in each target language, coordinating voice talent across time zones, iterating on pronunciations manually. A small production for three languages could run into thousands of dollars and weeks of calendar time. A full guided audio tour of a DC neighborhood runs roughly 3,000 to 5,000 characters of narration text. At Neural2 pricing, generating that tour in five languages costs under a dollar in TTS API calls. Pair that with an LLM translation pass and a single developer produces a multilingual tour catalog for less than five dollars total. That is not a cost reduction. It is a category change.
What working with these APIs teaches you
A pattern runs through the TTS tier structure that shows up across the current generation of AI services: tiered quality with tiered pricing, where the differences are not cosmetic but architectural. The model producing Studio output is not running the same architecture as Standard; it trained on different data at different cost to produce a different result. The right engineering decision is to route by purpose, not to pick one tier and apply it everywhere.
function selectVoiceConfig(language, useCase) {
// Cached tour content — generated once, served many times
// Studio cost amortizes across streams
if (useCase === 'cached-tour') {
return { model: 'studio', languageCode: language };
} // Code-switching or non-English primary - Chirp handles natively
if (language !== 'en-US') {
return { model: 'chirp', languageCode: language };
}
// Real-time English - Neural2 balances quality and cost
return { model: 'neural2', languageCode: language };
}
The same routing logic applies to LLM tier decisions, Opus versus Sonnet, GPT-4o versus GPT-4o-mini. Working through it in TTS first, where the quality difference is immediately audible rather than abstract, builds the instinct faster.
SSML also anticipates something about where prompt engineering is heading. Annotating content with rendering instructions, independent of the content itself, is the same pattern as structured prompts with XML tags for LLM output control. Getting comfortable with SSML builds the muscle for structured prompt design faster than reading about it.
Where I landed
The full pipeline for a tour stop runs three steps: translate the English source content using an LLM, wrap the output in SSML for pronunciation handling, synthesize with the appropriate voice tier. In practice it looks like this:
async function generateTourStop(content, targetLanguage) {
// Step 1: translate with Claude, preserving place names
const translated = await translateContent(content, targetLanguage);
// Step 2: wrap in SSML for phoneme control
const ssml = buildSSML(translated, targetLanguage);
// Step 3: synthesize - tier selected by language and use case
const voiceConfig = selectVoiceConfig(targetLanguage, 'cached-tour');
return await synthesize(ssml, voiceConfig);
}
async function translateContent(content, targetLanguage) {
const response = await anthropic.messages.create({
model: 'claude-sonnet-4-6',
max_tokens: 1024,
messages: [{
role: 'user',
content: `Translate the following DC neighborhood tour narration to ${targetLanguage}.
Preserve proper nouns, place names, and Metro station names exactly.
Keep the tone conversational and suited for audio delivery.
${content}`
}]
});
return response.content[0].text;
}
async function synthesize(ssml, voiceConfig) {
const [response] = await ttsClient.synthesizeSpeech({
input: { ssml },
voice: {
languageCode: voiceConfig.languageCode,
name: VOICE_MAP[voiceConfig.model][voiceConfig.languageCode],
},
audioConfig: {
audioEncoding: 'MP3',
speakingRate: 0.95, // slight slowdown for non-native listeners
},
});
return response.audioContent;
}
Running this against five languages for a single station comes back in a few seconds and costs fractions of a cent. The free tier handled all of the prototyping. The full cached tour catalog, once the content set stabilizes, routes to Studio.
The thing that surprised me most through this evaluation was not the ceiling of what neural TTS can produce. It was how clearly the old approach failed, visible only in contrast. Running eSpeak or first-generation concatenative voices after spending real time with Neural2 and Chirp sounds like output from a different industry. The gap runs deeper than incremental improvement on a shared architecture. The foundation changed.
Multilingual TTS is not solved. The quality gap between high-resource languages like English and Spanish and lower-resource languages like Swahili or Nepali remains real, because neural models require training data and training data is not distributed evenly across the world’s languages. But for the languages that matter to the DC Metro’s actual ridership, Spanish, French, Mandarin, Korean, and Portuguese, the quality available today, programmatically, at the price points that exist today, is high enough to build real features on. In 2020, none of this was available at a price point that made sense for a small team, let alone a single person.
By Joshua McDonald on April 16, 2026.
Exported from Medium on August 26, 2026.
Reader discussion