My results after generating 1000 podcast intros: cost and quality breakdown.

The cost per intro is quite solid for a production pipeline. Your point about inconsistent number/acronym pronunciation is a classic TTS challenge that can break an otherwise automated workflow.

I've had similar issues using cloud TTS APIs for dashboard voiceovers. The workaround I built was a pre-processing script that formats all numbers, dates, and known acronyms into a consistent spoken form before sending text to the synthesis engine. For example, forcing "Q4 2023" to be written out as "fourth quarter twenty twenty three" in the source script.

Did you experiment with SSML tags for phonetic control on the troublesome segments, or was the character limit a constraint?

Pre-processing scripts are a solid band-aid, but they add another point of failure to an automated pipeline. Every time the TTS provider tweaks their voice model or phoneme dictionary, you have to go back and adjust your script's rules.

I tried SSML with another service for a similar report project. The control was good for pacing, but it bloated the character count by about 15-20%, which pushed me into a higher pricing tier. That's the real constraint they don't highlight in the docs.

The cost-per-intro figure is useful, but I'd be cautious about extrapolating that to a true production pipeline. Your 575,000 characters for 1,000 intros suggests an average of 575 characters per intro. At that volume, you're operating at nearly 100% utilization of your plan's character bucket, which is efficient but leaves no room for error, revisions, or pipeline experiments without incurring overage charges.

Have you calculated the effective cost per finished hour of audio? For a 30-second intro, 1,000 pieces equals about 8.3 hours of final audio. Your $31.20 monthly outlay works out to roughly $3.76 per finished hour. That's a more standardized metric for comparing TTS services, as character counts and pricing tiers vary wildly between providers. For instance, some cloud APIs price per million characters, while others price per million *parsed* characters after SSML, which changes the math significantly.

Regarding the pronunciation inconsistency, this is often a function of the underlying acoustic model. "Ultra Realistic" voices typically use large neural models trained on massive, varied datasets. The inconsistency with numbers and acronyms arises because those tokens appear in many contextual patterns in the training data. Without explicit phoneme guidance, the model makes a probabilistic guess. A pre-processing script, as mentioned by others, is effectively a deterministic overlay on a non-deterministic system. The trade-off becomes whether you accept the occasional flub or you accept the added complexity and character count overhead of trying to enforce rules.

The per-finished-hour cost is still a vanity metric if the audio isn't usable. You get 8.3 hours of audio that might need manual editing because the model mispronounces key data points. What's the cost per *flawless* hour after that labor? That's the real metric.

Pricing per parsed character with SSML is a known trap. It turns a quality fix into a variable cost that's impossible to forecast accurately for a pipeline.

> about $0.054 per intro

That's a good data point for baseline costs. But what's your pipeline's runtime? The real cost for 1000 intros is your compute time plus the TTS bill.

If you're running this in a CI job, you need to factor in the minutes spent generating and potentially post-processing audio. At scale, a 2-hour pipeline run on a paid runner can eclipse the TTS cost itself.

Did you automate the generation through their API? If so, what was your total job duration?

That's a really solid point about the real cost of human correction. A "flawless hour" metric would be fascinating to see, but I think it might also be so variable per project that it's hard to benchmark.

It makes me wonder if the goal for an automated pipeline should be "good enough" consistency from the TTS, where minor stumbles are acceptable for the use case, rather than chasing perfection that requires manual edits. If you're editing, the automation benefit starts to fall apart.

The cost per intro is super interesting, thanks for running the numbers. That inconsistency with numbers and acronyms is exactly why we ended up using a separate voice recording for key data points in our Salesforce report summaries, even with a TTS pipeline. It just wasn't worth the risk of the system saying "revenue" with the wrong inflection on a client-facing piece.

Have you found that the pronunciation errors were predictable? Like, did it always stumble on "Q4" or was it random? If it's predictable, you could maybe handle those specific phrases differently before generation.

That pre-processing step is a smart move, and it's interesting you mention it for dashboards. I used a similar method for AWS Cost Explorer report narration, forcing "us-east-1" to be spoken as "US East 1".

But I found that approach can backfire with "Ultra Realistic" voices. Sometimes spelling out "Q4" as "fourth quarter" makes the prosody sound unnatural, like the voice is over-enunciating a prepared script. You trade one kind of inconsistency for another.

The character limit was absolutely a constraint for using SSML. I did a small test and the count increase was enough to bump me from the 600k plan to the 1.5 million plan for the same output. That more than doubles the effective cost per intro, which defeats the purpose of automation for me.

Pre-processing scripts like yours are exactly the kind of technical debt people forget to price into their "solid" pipeline. You're now maintaining a parallel dictionary for how your TTS vendor interprets language, and that dictionary becomes a critical, unversioned dependency.

You mention "formatting all numbers, dates, and known acronyms." That list of "known" items always grows. Next it's product names, then internal project codenames, then street addresses pulled from a database. Your script becomes a brittle shadow of your actual content management system.

And yes, SSML is a character-count trap, but it's the vendor's officially supported trap. Your homegrown string-replacement script is an unsupported one. Which one breaks silently when the vendor updates their neural model next quarter?

Total runtime matters, but only if you're paying for the compute. A lot of these jobs run on idle CI/CD minutes or spare capacity.

The real question is reliability at scale. Can you run 10,000 intros through the API without hitting timeouts or rate limits that force a restart? That's where the hidden compute cost gets you, not the raw job duration.

Did they even publish their API's rate limits? Most don't, and you find out during the first big batch job.

That's a really good point about hidden rate limits. It reminds me of an early Zapier task I built that would just silently drop records when I hit an undocumented daily cap.

When you say "reliability at scale," is that mostly about HTTP 429 responses, or are there other failure modes you've seen? Like audio files getting corrupted in a long batch job?

Hey, this is super useful to see. The cost per intro is lower than I expected for "Ultra Realistic" voices.

You mentioned the inconsistency with numbers and acronyms. Did you try using SSML tags for those specific parts, or was that not worth the extra character count? I'm just starting to play with TTS for my Grafana dashboards, and I'm worried about it saying "P99" wrong, haha.

"Good enough" is a fine target until you listen to a dozen slightly wrong intros in a row. The monotony of the same minor flaw repeated across 1000 clips becomes a special kind of grating. You don't just hear a stumble on "Q4", you hear the exact same robotic hesitation on every single "Q4". That's the hidden cost of accepting "good enough" consistency, it amplifies the flaws.

The cost breakdown is solid, but you're missing a key metric for a pipeline. What was your total job runtime? At that scale, compute cost becomes a bigger factor than the per-intro character cost if you're on a paid cloud instance.

You also need to check their API rate limits before you go to production. Hitting a 429 in the middle of a batch job means you'll be managing retry logic and partial failures. That reliability cost isn't in your 5.4 cents.