Turning Articles into Audio with the Gemini 3.1 Flash TTS Preview: Splitting Long Text, Stitching It Back, and What It Actually Costs

Keep a single narrator steady to the end

Unlike a multi-speaker podcast, article narration needs one person reading at one temperature all the way through. The moment you split into chunks, each chunk is an independent synthesis, so without care the timbre and pace drift bit by bit.

Pin the style instruction across every chunk

I state the voice and reading style in the prompt and pass the exact same wording to every chunk. Not varying the instruction per chunk is the shortest path to a steady read.

from google import genai
from google.genai import types
 
client = genai.Client(api_key="YOUR_GEMINI_API_KEY")
 
# Shared style instruction — do not change it mid-article
STYLE = (
    "Read as a calm, neutral narrator for an explanatory article. "
    "Slightly slow pace, restrained emotion, polite endings, "
    "and clear pronunciation of technical terms."
)
 
def synthesize(chunk_text: str) -> bytes:
    res = client.models.generate_content(
        model="gemini-3.1-flash-preview-tts",
        contents=f"{STYLE}\n\nBody: {chunk_text}",
        config=types.GenerateContentConfig(
            response_modalities=["AUDIO"],
            speech_config=types.SpeechConfig(
                voice_config=types.VoiceConfig(
                    prebuilt_voice_config=types.PrebuiltVoiceConfig(
                        voice_name="Charon",  # pick once, keep it for every article
                    )
                )
            ),
        ),
    )
    return res.candidates[0].content.parts[0].inline_data.data  # 24kHz PCM

My recommendation is to fix voice_name for the whole channel rather than per article. Listeners learn "this voice equals this outlet," so a changing voice reads as a different thing. On one of the Dolice Labs healing apps, a review once flagged the narration as off after I swapped voices mid-stream — voice consistency mattered more than I expected.

Normalize numbers and acronyms before synthesis

TTS struggles with context-dependent readings. Whether "3.1" should be "three point one" or something else drifts when left to the model. I pass text through a small substitution dictionary before synthesis to pin the readings I want.

READ_DICT = {
    "TTS": "T T S",
    "PCM": "P C M",
    "API": "A P I",
}
 
def normalize_reading(text: str) -> str:
    for k, v in READ_DICT.items():
        text = text.replace(k, v)
    return text

The dictionary is something you grow per channel; there is no need to be perfect from day one. Add one word at a time whenever your ear catches a stumble, and within a few weeks almost nothing trips it.

Estimate the per-article cost in real money

This is the heart of the economics. TTS billing scales with characters (or audio seconds), so once you know an article's character count, the unit cost is quite predictable.

Pricing can change, so always replace the assumptions with the current rate card. To show the method, I use $1.00 per one million input characters and treat the body plus the style instruction as the billable text. A 4,000-character article is roughly 4,300 billable characters once the style line is added.

The number is so small it makes you double-check the decimal point, and that is exactly why I felt the preview moved the break-even line. Even if an expressive model cost 10x this, that is about $1.30 a month. With a 20% allowance for re-records you can still hold the cadence, which means audio fits into a daily publishing flow.

One caveat: a longer style instruction is billed on every chunk too. I keep the style line under about 60 characters and shared, so the overhead stays small. Write a 200-character instruction and a 4,000-character article with 20 chunks carries 4,000 extra billed characters of instructions — a quiet but real tax.

Three places it tends to break: finish_reason, sample rate, seams

Once it runs in production, quality drops in the same predictable spots. Pre-empt them.

Always check finish_reason

A long chunk or awkward symbols can stop synthesis early and return audio with the tail missing. Confirm finish_reason is a clean stop, and if not, re-split shorter and retry — that prevents shipping a clipped file.

def synthesize_safe(chunk_text: str, depth: int = 0) -> bytes:
    res = client.models.generate_content(
        model="gemini-3.1-flash-preview-tts",
        contents=f"{STYLE}\n\nBody: {chunk_text}",
        config=types.GenerateContentConfig(response_modalities=["AUDIO"]),
    )
    cand = res.candidates[0]
    if str(cand.finish_reason) not in ("FinishReason.STOP", "STOP"):
        if depth < 1 and len(chunk_text) > 80:  # split in half once and retry
            mid = len(chunk_text) // 2
            return synthesize_safe(chunk_text[:mid]) + synthesize_safe(chunk_text[mid:])
        raise RuntimeError(f"TTS abnormal end: {cand.finish_reason}")
    return cand.content.parts[0].inline_data.data

Do not mistake the sample rate

If you assume 24kHz PCM is 44.1kHz when you write the WAV header, the voice plays high and fast. This is a classic trap that shows up with Live API audio too, and the first time it bit me I lost real time finding the cause. Lock the output at 24kHz and use the same value through joining and conversion.

Keep the seam silence even

If chunks end with different amounts of trailing reverb, a flat 0.25s of silence still won't sound aligned. If it bothers you, trim the tiny trailing silence per chunk before adding fixed silence. By ear, as long as I split on the period, trailing trims were not even necessary.

Getting it onto the channel

Finally, convert the joined PCM into a distributable format. Most platforms accept MP3, so wrap it as WAV and convert.

import wave, subprocess
 
def pcm_to_wav(pcm: bytes, path: str):
    with wave.open(path, "wb") as w:
        w.setnchannels(1)      # mono
        w.setsampwidth(2)      # 16-bit
        w.setframerate(24000)  # fixed 24kHz
        w.writeframes(pcm)
 
def wav_to_mp3(wav_path: str, mp3_path: str):
    subprocess.run(
        ["ffmpeg", "-y", "-i", wav_path, "-b:a", "128k", mp3_path],
        check=True,
    )

With that in place, an article's Markdown goes in and one distribution-ready MP3 comes out. As an indie developer I wire this into the publish hook, so once the body is final the audio is generated automatically. The Dolice Labs membership runs on Stripe, but I keep audio on the free path — another doorway for the same article to reach readers.

It is an unglamorous mechanism, but adding one thin way to spread your writing into another channel quietly widens its reach. Start by running a single article through split_for_tts and producing that fraction-of-a-cent narration. That one file is what turns audio from "something I'll do someday" into part of today's publishing flow.