Daniel sent us this one, and it's genuinely meta even by our standards. He's asking about a podcast feature where listeners could swap out our voices — pick their own preferred voice for me and Herman — essentially decoupling the narration from the voices we've been using. He mentions that our voices are TTS clones generated with Chatterbox, that he narrated the original samples himself, and that he's aware not everyone loves how a sloth and a donkey sound. The core question is whether something like this is actually feasible, and if any tools already exist to make it happen.
Before we dive into the technical side — quick production note — today's episode script is being written by DeepSeek V four Pro.
Hope it captures my wry charm.
I'm sure it'll try. But this idea Daniel's proposing — it's interesting because he's not talking about just offering a different voice pack. He's describing something more fundamental. Dynamic voice replacement at the listener level.
The way he framed it, it's not us re-recording episodes with different voices. It's the end user saying, I want Herman to sound like a British woman in her forties today, and I want Corn to sound like a baritone from Texas. And the episode just renders that way for them.
Which, I have to say, is both more ambitious and more practical than it sounds. Let me start with the practical part first, because this connects directly to how our show is actually built.
Our production pipeline — Daniel's described pieces of this before — it's fundamentally a script with character markings. Corn colon, Herman colon, Hilbert colon. That text gets fed into a TTS engine, and the engine renders audio using cached voice embeddings. The key insight here is that the script and the voices are already separate. They're not baked together until the final rendering step.
In principle, you could just swap the embeddings.
The script doesn't know or care what voice is reading it. It's just marked-up dialogue. If you had a system where, instead of serving pre-rendered MP3 files, you served the marked-up script plus a voice selection interface, the rendering could happen on the fly — or even on the user's device.
This is where Chatterbox specifically matters, because Daniel mentioned that's what we use.
Chatterbox is a neural TTS system that uses voice cloning. The way it works — and I looked into this — is you provide a short sample of someone's voice, typically between three and ten seconds of clean audio, and the model extracts what's called a speaker embedding. That embedding is basically a mathematical fingerprint of the voice — pitch contours, timbre, cadence, all compressed into a vector. Once you have that embedding cached, you can generate speech from any text input in that voice.
The embedding is the voice, in a sense. Not the audio file, but this compressed representation.
And Chatterbox is designed to be efficient about this. The embeddings are small — we're talking kilobytes, not megabytes. The heavy lifting is the neural network that converts text plus embedding into audio waveforms. But that network is the same regardless of whose voice you're using.
Which means — and correct me if I'm getting this wrong — if Daniel wanted to offer listeners a choice of voices, he wouldn't need to store separate audio files for every voice option. He'd just need to store different embeddings and run the same text through the same model.
The marginal cost of adding a new voice is tiny. You record or obtain a short sample, generate the embedding, store it. The rendering cost is the same per minute of audio regardless of which embedding you use.
The economics of this actually work. That's the first hurdle cleared. But there's a bigger question lurking here — where do the alternative voices come from?
This is where it gets interesting. Daniel's idea of letting users bring their own voices — B-Y-O-V, if you will — opens up several possibilities. The simplest version is what I'd call the voice marketplace approach. The podcast offers a selection of pre-approved voices. Maybe ten, maybe fifty. Professional voice clones that have been licensed and quality-checked. You pick from a dropdown, and the episode renders with your choice.
That's the safe version. It avoids a lot of problems. But Daniel specifically said users could choose their preferred voice, implying more freedom than a curated list.
Right, and the more radical version is exactly what he described. A user uploads a short audio sample — their own voice, their spouse's voice, whoever they want, assuming consent — and the system generates a custom embedding on the fly. Then every episode they listen to uses that embedding for Herman, or for me, or for both of us.
The consent point is not trivial. If someone wants to hear this podcast narrated by their ex-partner's voice, that gets ethically thorny fast.
It does, and voice cloning ethics is a whole separate conversation. But let's assume for now we're talking about voices people have legitimate access to. The technical question is whether on-the-fly embedding generation is feasible. And the answer is yes, with caveats.
What are the caveats?
The biggest one is quality. Chatterbox and similar systems — ElevenLabs, Resemble, Play dot H T — they all do voice cloning, but the quality of the clone depends heavily on the input sample. You need clean audio, no background noise, consistent speaking volume, neutral emotional tone. If someone uploads a clip recorded on their phone in a coffee shop, the resulting voice clone is going to sound terrible.
You'd need some kind of quality gate. The system has to evaluate whether the sample is usable before generating the embedding.
That evaluation itself is a solvable problem. There are audio quality assessment models that can check for noise floor, clipping, reverb, bandwidth. You could reject samples that don't meet a threshold and tell the user to try again in a quieter environment.
What about the actual rendering? If a thousand people all choose different voices, does Daniel's server have to render a thousand separate audio files?
This is where the architecture gets interesting. There are basically two approaches. One is server-side rendering, where the podcast host generates a unique audio file for each voice combination and caches it. If you have ten voice options for two hosts, that's a hundred combinations. If you allow custom uploads, you can't pre-cache everything, so you render on demand and cache popular combinations.
The other approach?
Client-side rendering. The user's podcast app receives the marked-up script plus the voice embeddings, and the actual TTS synthesis happens on the user's phone. This is the holy grail because it eliminates server costs entirely for the voice rendering. But it requires the podcast app to have a TTS engine built in, which most don't.
But we're seeing moves in that direction. I saw that Google's Gemini assistant is now being integrated into millions of vehicles — the whole trend is toward on-device AI inference. Running a TTS model locally on a phone is getting more feasible every year.
Apple's Neural Engine, Qualcomm's Hexagon processor, Google's Tensor chips — they're all designed for exactly this kind of on-device machine learning workload. A lightweight TTS model like Chatterbox could realistically run on a modern smartphone without killing the battery. The model file might be a few hundred megabytes, and inference latency could be low enough for real-time streaming.
The long-term vision is: you open your podcast app, you go to settings, you upload a ten-second voice clip for Herman and a ten-second clip for Corn, and from that point forward, every episode of My Weird Prompts renders in those voices, on your device, as you stream it.
The script is still the same. The jokes are the same. The tangents about archery and leaf medicine are the same. But the sonic experience is personalized.
Let me push on something. You said the quality depends on the input sample. But there's another quality issue. Our voices — the ones Daniel created — they're not just any voices. They have character. My voice is slow and deliberate. Yours is energetic and slightly nasal. These aren't accidents. They're performance choices that Daniel made when he narrated the original samples.
That's an excellent point. A voice clone doesn't just capture the acoustic properties of the source audio. It captures the speaking style — the pace, the pitch variation, the emotional range. If someone uploads a monotone reading of a grocery list as their sample, the resulting clone is going to narrate our podcast in a monotone. All the comedic timing, the emphasis, the personality — that's in the performance, not just the voice.
Even if the technical pipeline works perfectly, the result might be flat and lifeless if the source performance isn't good.
Unless you separate style from identity. Some of the newer TTS systems can do this. You can have a style embedding that captures how something is said — the prosody, the rhythm, the emotional contour — and a separate speaker embedding that captures who is saying it. In theory, you could use Daniel's original performance for the style and the user's uploaded voice for the identity, and merge them.
That sounds like it's still in the research lab, not in production.
It's emerging. ElevenLabs has something called voice design where you can adjust characteristics like stability and clarity. Resemble has emotion control. But fully decoupled style and identity transfer? That's bleeding edge. You'd get artifacts. The voice might sound like the right person but with slightly robotic intonation, or the emotional expression might not quite land.
For now, if Daniel wanted to build this, he'd probably be better off with the curated voice library approach. Commission a set of voice actors to record high-quality samples with good performance, generate clean embeddings, and offer those as options.
Honestly, that alone would be a innovative podcast feature. I don't know of any major podcast that offers this. Some audiobook platforms let you choose between narrators, but that's completely different — those are separate full recordings. This would be one script, multiple voice renderings.
Are there any tools that already make this possible? Daniel asked that directly.
Nothing off-the-shelf that does exactly this for podcasts. But the component pieces exist. For the TTS side, you've got Chatterbox, which we use. ElevenLabs has an API that supports voice cloning and real-time streaming. Play dot H T has a similar API. For the script-to-audio pipeline, you'd need something custom, but it's not wildly complex. The script format we use is basically just structured text. You'd parse it, send each character's lines to the appropriate voice model, stitch the audio segments together with appropriate pauses.
The stitching is where it could get janky. If the pauses between lines aren't right, the conversation won't feel natural.
That's actually one of the harder problems. Good podcast dialogue has rhythm. I speak, then you respond, sometimes with a slight overlap, sometimes with a beat of silence for comic timing. If you're rendering each line independently and concatenating them, you lose that natural flow. You'd need the rendering system to be aware of the conversational dynamics.
Could you render the whole episode as one continuous generation, alternating between the two voice models?
That's an interesting approach. Instead of generating each line separately, you'd feed the entire script to the TTS system with markers indicating which voice to use for which segment. Some multi-speaker TTS models can handle this natively. They generate a single coherent audio stream with speaker transitions built in. The pacing would be more natural because the model can account for the flow across speaker boundaries.
That would require the model to have both voice embeddings loaded simultaneously and switch between them seamlessly.
Right, and that's more demanding. Most TTS APIs are designed for single-speaker generation. Multi-speaker dialogue synthesis is a niche use case. But it's not unsolvable. Microsoft has done research on this. Nvidia has as well. The technology exists; it's just not packaged as a consumer product.
Let's talk about the user experience for a minute. Daniel's idea implies that listeners would actively choose to change the voices. But most podcast listeners are passive. They hit play and they listen. How many people would actually go into settings and configure custom voices?
That's the adoption question, and it's real. Most people don't change default settings on anything. The percentage of users who would engage with a voice customization feature is probably small — maybe five to ten percent, if that.
Those five to ten percent might be the most engaged listeners. The ones who care enough to customize are the ones who are going to tell their friends about the podcast.
There's an accessibility angle here that I think is worth highlighting. Some listeners might have difficulty with certain voice types — maybe my energetic donkey voice is hard for them to process, or your slow sloth delivery doesn't work for their listening environment. Giving them the option to choose voices that work better for their needs isn't just a novelty feature. It's an accessibility feature.
That's a good point. And it reframes the whole idea. It's not just about personal preference. It's about making the podcast more accessible to people with auditory processing differences, or people who listen in noisy environments where certain frequency ranges get lost.
Or people who aren't native English speakers and find certain accents easier to parse. An American listener might prefer American-accented voices. A British listener might find British voices more natural. You could offer accent variations without changing the content at all.
There's actually a strong case for this beyond the novelty factor. But let me play devil's advocate for a moment. If listeners can swap out our voices for anyone else's, does that undermine the identity of the show? Part of what makes My Weird Prompts distinctive is that it's a sloth and a donkey talking. If I sound like a generic male voice and you sound like a generic female voice, are we still Corn and Herman?
That's the philosophical question hiding inside the technical one. And I think the answer depends on what you think the show is. If the show is fundamentally the voices — the specific sonic character of a slow sloth and a nerdy donkey — then changing the voices changes the show. But if the show is fundamentally the ideas, the chemistry, the writing, the relationship between two brothers who tease each other and build on each other's thoughts — then the voices are just a delivery mechanism.
I'd argue it's both. The voices aren't incidental. They're part of the humor. The fact that I'm a sloth who claims to have invented pizza is funnier when I sound like a slow, deliberate sloth. If I sounded like a caffeinated game show host, the joke wouldn't land the same way.
But here's the counterpoint. Daniel's original voice clones — the ones we use now — they're already a creative choice. He could have made us sound completely different. He chose the sloth voice and the donkey voice because they fit the characters he imagined. But a listener who hears those voices and finds them grating — and Daniel acknowledged that not everyone is charmed by them — that listener might miss the content entirely because they can't get past the sound.
You're saying the voice customization could actually expand the audience by removing a barrier.
And Daniel could still make the default voices the canonical Corn and Herman experience. The custom voices would be an option, not a replacement. Most listeners would never touch the setting, and they'd get the show exactly as Daniel intended. But the listener who would otherwise unsubscribe because my voice annoys them — they could swap me out and stick around.
That's a compelling framing. The default remains authoritative, but the customization reduces churn.
And this connects to a broader trend in media. We're moving toward what people call adaptive content — media that reshapes itself to the consumer's preferences and context. Spotify already does this with personalized playlists. YouTube adjusts video quality based on your connection speed. Netflix lets you choose subtitle styles. Voice-customizable podcasts are a logical next step.
It's also worth noting that this isn't entirely unprecedented in audio. Some GPS apps let you choose celebrity voices for navigation. Amazon's Polly TTS service offers dozens of voices in multiple languages. The puzzle pieces are all there. Nobody's quite put them together for podcasts yet.
Part of the reason is that most podcasts are distributed as static MP3 files via RSS feeds. The infrastructure assumes one audio file per episode, generated once and served identically to everyone. What Daniel's describing would require dynamic audio generation. That breaks the standard podcast distribution model.
You'd need either a custom podcast app that does the rendering, or a web-based player that generates the audio on the server side.
The custom app approach is cleaner but has a massive adoption problem. Convincing people to download a new podcast app just for one show is a hard sell. The web player approach is more accessible — anyone with a browser can use it — but it means people can't listen in their usual podcast app, which is where most listening happens.
There's a third option. You generate multiple pre-rendered versions of each episode with different voice combinations and serve them as separate podcast feeds. So there's the "Classic Corn and Herman" feed, the "British Narration" feed, the "American Narration" feed, and so on.
That's the brute force approach. It works technically — each feed is just a standard RSS feed with MP3 files, fully compatible with every podcast app. The downside is storage and rendering cost. If you offer five voice options for each of two hosts, that's twenty-five versions of every episode. For a weekly hour-long show, the storage adds up, and the rendering time multiplies.
Storage is cheap, and rendering is a one-time cost per episode. If the audience is big enough to justify it, this might actually be the most pragmatic approach right now.
I think you're right. And it avoids the complexity of client-side rendering or custom apps. Daniel could set up a pipeline where, after the script is finalized, it gets rendered through multiple voice configurations automatically. Each configuration produces an MP3 that goes into its own RSS feed. Listeners subscribe to the feed that matches their voice preference.
The downside is that it's not truly customizable. You're choosing from a menu, not bringing your own voice. But it's achievable today with existing tools.
Honestly, I think that's the right place to start. Version one is a curated voice library. You pick from maybe six to ten voice options for each host, giving you thirty-six to a hundred combinations. That's manageable. You learn what people actually choose. You gather data on whether the feature gets used. Then version two, if there's demand, could be the full bring-your-own-voice system with on-device rendering.
Let me ask a practical question. If Daniel wanted to build the curated version today, what would the actual workflow look like?
Step one is generating the voice embeddings. He'd need to find voice actors — or use his own voice with different stylistic treatments — and record clean samples. Each sample needs to be maybe thirty seconds of natural speech. Run those through Chatterbox or ElevenLabs to generate the embeddings. Store the embeddings in a database keyed by voice name.
Step two is modifying the rendering pipeline. Right now, I assume Daniel's pipeline takes the marked-up script and renders it with the two canonical embeddings — Corn's embedding and my embedding. The modified pipeline would accept voice selection parameters and swap in the chosen embeddings. Everything else stays the same.
Step three is distribution. Multiple RSS feeds, or a web player with a voice selector, or both.
The multi-feed approach is probably easiest to implement. Each feed is just a standard podcast RSS feed. The only difference is which set of embeddings was used during rendering. Podcast apps don't need to know anything about the voice customization. They just see a normal podcast with normal audio files.
There's a discoverability problem, though. If someone searches for My Weird Prompts in their podcast app, which feed do they find? You'd need a landing page that explains the options and directs people to the right feed.
That landing page could include audio samples so people can preview the voice options before subscribing. Click to hear a thirty-second clip of me sounding like a British woman, or you sounding like a deep-voiced American man, or whatever the options are.
I'm actually coming around to this. The curated approach solves the quality problem — all the voice samples are professionally recorded, so the performance is good. It solves the distribution problem — standard RSS feeds work everywhere. And it solves the adoption problem — people don't need to learn a new interface; they just pick a feed once and forget about it.
The main limitation is that it doesn't fulfill the full vision Daniel described. Users can't truly bring their own voices. They're choosing from a menu. But as a first step, it's solid.
The full vision — the bring-your-own-voice version — becomes more feasible as on-device AI improves. I could imagine a future version of Apple Podcasts or Spotify that has a built-in voice customization setting. You record a sample in the app, it generates an embedding locally on your phone, and from then on, any podcast that opts into the feature can be rendered in your preferred voice.
That would require podcast creators to distribute their content as marked-up scripts plus metadata, rather than as finished audio. It's a fundamental shift in what a podcast is. Instead of being an audio file, it becomes a script plus production instructions that get rendered at the point of consumption.
Which is, when you think about it, what a podcast always was. The audio file was just the most practical way to distribute the content. But if the technology exists to distribute the script and render it locally with personalized parameters, the audio file becomes an unnecessary intermediate step.
There's a parallel here with video games. Early video games distributed pre-rendered cutscenes as video files. Modern games render cutscenes in real time using the game engine, which means the cutscenes can reflect your character's current appearance, your chosen language, your graphics settings. The content is the same, but the presentation adapts to the player.
Nobody would go back to pre-rendered cutscenes now that they've experienced the adaptive version. The question is whether podcasts follow the same trajectory.
I think they will, but slowly. The podcast ecosystem is conservative. RSS feeds have been the standard for twenty years. Change happens at the edges — new apps, new platforms — rather than in the core infrastructure. Voice customization will probably show up first in a proprietary platform like Spotify, which can control the entire stack from distribution to playback.
Spotify already has the infrastructure. They acquired Sonantic, a voice AI company, a few years back. They've been experimenting with AI-powered features. Adding voice customization for podcasts would be a natural extension.
Apple has been investing heavily in on-device machine learning. Their recent chips have dedicated neural processing units that could handle TTS inference efficiently. If Apple decided to make voice-customizable podcasts a feature of the Podcasts app, it would become mainstream overnight.
Daniel's idea isn't just feasible — it's probably inevitable. The question is timing and who builds it first.
Whether an independent podcaster like Daniel can get there before the big platforms do. The curated voice library approach is something he could build now with existing tools. It wouldn't require platform-level changes. It's just a rendering pipeline modification plus multiple RSS feeds.
The cost would be primarily in rendering time and storage. If each episode takes, say, ten minutes to render per voice combination, and you have twenty-five combinations, that's about four hours of rendering per episode. Doable with cloud computing, and the cost per episode would be a few dollars at most.
You only render each combination once, when the episode is published. After that, it's just serving static files. The ongoing cost is storage, which is pennies per gigabyte.
For a few hundred dollars a year, Daniel could offer a innovative feature that almost no other podcast has. That seems like a worthwhile experiment.
I'd go further. I think this is one of those ideas where, five years from now, people will look back and wonder why all podcasts didn't do it sooner. The technology is ready. The user demand is latent but real — especially for accessibility and accent preferences. The economics work. It's just that nobody's put the pieces together yet.
Daniel, being Daniel, is the kind of person who might actually do it. He built a home inventory system with NFC tags and barcodes before settling on markers. The man likes to experiment with infrastructure.
And this project is right at the intersection of his interests — AI, automation, podcast production, and making things more customizable for users. It's a very Daniel prompt.
Let me raise one more concern, and then we should start wrapping up. If we go down this road — if listeners can make me sound like anyone — does that create a weird parasocial dynamic? People form relationships with voices. If someone chooses to hear me as their own voice, or their partner's voice, does that blur the line between podcast host and personal companion in an uncomfortable way?
That's a thoughtful concern. And I think the answer is that the line is already blurring. People already form parasocial relationships with podcast hosts. They listen to us for hours every week. They know our personalities, our quirks, our running jokes. Changing the voice doesn't change the relationship — it just changes the sensory experience of it. If anything, hearing a familiar voice might make the content feel more intimate, but the content itself is still us.
I suppose the alternative voices are still saying the same words. It's not like the AI is generating new dialogue. The script is fixed. The personality is in the writing.
And that's an important distinction. This isn't an AI-generated podcast where the content is synthetic. This is a human-written script — Daniel's prompts, our discussion, our jokes — delivered through a synthetic voice. The voice is a instrument, not the composer.
The voice is the instrument. And Daniel's idea is essentially letting the listener choose which instrument plays the same composition.
Which, by the way, has a long history in music. Orchestral pieces get performed by different orchestras. Jazz standards get interpreted by different musicians. The composition is the constant. The performance varies. Nobody thinks it's weird that Miles Davis and John Coltrane both played Autumn Leaves.
I'm not sure our podcast is quite at the level of Autumn Leaves, but I take your point.
The principle holds. Content and delivery are separable. And in an age where AI makes delivery infinitely customizable, separating them is the logical thing to do.
So to bring this back to Daniel's specific questions. Is the idea feasible? Are there tools that make it possible? The component pieces exist — Chatterbox, ElevenLabs, Play dot H T for TTS, plus standard podcast hosting infrastructure for distribution. Nothing off-the-shelf does exactly what he's describing, but the integration work isn't prohibitively complex. The curated voice library approach is achievable today. The full bring-your-own-voice approach requires either a custom podcast app or platform-level support, which makes it harder but not impossible.
I'd add that the curated approach is probably the right first step regardless. It solves the quality control problem, it works with existing podcast apps, and it lets Daniel test whether listeners actually want the feature before investing in more complex infrastructure.
One thing we haven't mentioned is that this feature could also be a differentiator for the show. How many podcasts let you choose your narrator's voice? If My Weird Prompts offered this, it would generate press coverage, word of mouth, and probably a bump in listenership just from the novelty.
The "world's first voice-customizable podcast" angle. It's a good headline.
Daniel works in tech communications. He knows how to pitch a story like that.
He absolutely does. I could see the TechCrunch piece now. Something about how an independent podcaster in Jerusalem is pioneering personalized audio experiences while the big platforms are still figuring out their strategy.
Alright, I think we've covered the ground. Let's do Hilbert's fact and then wrap.
Now: Hilbert's daily fun fact.
Hilbert: The Andean condor can fly for over one hundred miles without flapping its wings even once, using only thermal air currents to stay aloft.
That's impressive.
One hundred miles without flapping. I'm trying to imagine the patience required for that.
Sounds like my kind of bird.
This has been My Weird Prompts. Thanks to our producer, Hilbert Flumingtop, and to Daniel for a prompt that made us think about what a podcast even is. If you enjoyed this episode, leave us a review wherever you listen — it helps other people find the show.
Until next time.
