Turn Notes Into a Podcast with Two AI Voices

A notes-to-podcast workflow: reshape six lines of notes into a two-host script, assign two voices in Murmur Projects, generate, and export the episode.

Short answer: To turn notes into a podcast, rewrite the notes as a spoken dialogue with a name in front of every line, then render each name with a different voice. The writing step is yours: the app does not summarize notes or draft a script. What it does is take a finished two-host script, keep each speaker attached to a chosen voice, generate the lines locally on a Mac, and export the episode.

That division of labor matters. Most tools that advertise notes-to-podcast conversion are selling an AI writer plus a cloud voice. If you already know your subject, the writing is the part you should control. The slow, mechanical part is turning a good script into clean audio with consistent voices, and that is the part this workflow removes.

Turn notes into a script, not a summary

Notes are compressed for your eyes. They skip transitions, assume context, and lean on fragments. A listener has none of that context and cannot reread a sentence. Before any voice generation, convert each note into something a person could say out loud to someone else.

• Expand every fragment into a complete sentence with a subject and a verb.
• Give each note one job: a claim, a question, an example, or a transition. Split notes that try to do two jobs.
• Write numbers, dates, and abbreviations the way they should be spoken. If a listener would hear it wrong, spell it out.
• Add the question a curious listener would ask. This is what the second host is for.
• Delete anything you cannot defend out loud. A note that only works as a bullet is not ready for audio.

Keep the note file open beside the script while you work. You are not throwing the notes away, you are expanding them. The notes remain the fact check and the outline; the dialogue is the performance.

A worked example: six note lines become twelve spoken turns

Here is a complete before-and-after from a fictional short episode about pre-ground coffee. The notes are six lines. The script is twelve turns, alternating between a Host and a Guest.

Notes: pre-ground coffee

• Pre-ground coffee goes stale because of surface area
• Grind consistency matters more than brew time
• Burr grinder beats blade grinder for repeatability
• Listener question: is a cheap burr grinder enough?
• Test: same beans, two grind sizes, taste side by side
• Close: one change to try this week

Notice what the notes do not contain: a greeting, a reason to keep listening, a definition of surface area, or a usable answer for the listener with the grinder question. The rewrite supplies those in the smallest number of turns that still sounds like a conversation.

Host: Welcome back. Today we're talking about pre-ground coffee, and why the bag you bought last month tastes flat.
Guest: The short version is surface area. Grinding exposes more of the bean to air, so the aromatics leave faster.
Host: So the grinder matters more than the brewer?
Guest: For most people, yes. A consistent grind changes how water moves through the bed, and that changes what you taste.
Host: Our notes also say grind size beats brew time. Is that fair?
Guest: Mostly. If the grind is uneven, no timer will save the cup. Fix the grind first, then adjust time.
Host: A listener asked whether a cheap burr grinder is enough.
Guest: A burr grinder with a stable setting is a better start than a blade grinder. You do not need the most expensive one to hear a difference.
Host: What is one change to try this week?
Guest: Grind one dose coarse and one fine, brew both, and taste them side by side. Keep the one you would drink again.
Host: That is the whole episode. Try the two-grind test and tell us which cup won.
Guest: And use beans you already like, so the only variable is the grind.

Each note became a pair: the Host states or asks, the Guest answers. That is not padding. The second turn forces the script to explain the claim instead of asserting it, which is exactly what a listener needs. Six lines of notes became a dialogue of about 190 words, which is roughly 75 to 90 seconds of speech depending on pace.

Why a second host changes the writing

A second voice gives the script permission to ask the obvious question, define a term, and signal a new section without saying "section two." It also creates a natural place for the listener's objection. When the Host asks whether a cheap grinder is enough, the listener hears their own question in the show.

The tradeoff is real. Two voices are harder to keep consistent across episodes, and a scripted exchange can sound stiff if every answer is the same length. A solo read is the better choice for dense reference material, a personal essay, or anything where a second character would be theater. If the notes are mostly a list of facts, one narrator is honest. If the notes contain a question you expect listeners to have, a second host earns its place.

Choose a format before you assign voices

Pick the format before you write a single line. Changing format halfway through means rewriting the script and reassigning speakers, which is more work than deciding first. For most notes-to-podcast projects, the two-host explainer is the fastest structure to write and the easiest to follow.

Set up the two voices in Projects

Murmur is a local voice studio for Apple Silicon and Intel Macs running macOS 15 or later. Projects is its multi-speaker workspace, and it is the part that matters here: a project holds a shared cast, one or more scripts, and a timeline. The steps below follow the current app.

1. Open Projects and, under Start from template, pick the Podcast card. The template starts an Untitled Podcast with sample Cold open, Main interview, and Outro scripts and Host and Guest speakers, so replace the sample dialogue with yours.
2. Add two speakers in the Speakers panel, for example Host and Guest. Each speaker gets a display name and a color.
3. Assign a voice to each speaker. Use a preset voice from the selected model, or a saved reference profile if the model supports cloning. Both speakers use the project's model, so pick one model that offers two voices you like.
4. Paste the dialogue into the script editor. Type a forward slash in the script to insert a speaker pill, then choose the speaker, or paste lines that start with Host: and Guest: and Murmur creates the speakers for you. Every line should begin with its speaker.
5. Check that no speaker is left without a voice. Generation is blocked while a used speaker has no assignment.
6. Choose Generate Script. Listen through, then select a single clip and use Regenerate Block for a line that needs another take instead of regenerating the whole episode.
7. Arrange the generated clips on the timeline, add markers for chapter points, and export when the mix is right.

Projects is a Pro feature. The free plan covers Kokoro and scripts up to 1,500 characters, which is enough to test a voice but not to produce an episode. The app can start a one-click 3-day Pro trial, and the full license is $49 one-time with a 7-day refund policy. If you only need a single narrator for short clips, the free plan may be all you need.

One honest limitation: the app does not write, summarize, or restructure your notes. If you want the tool to invent the dialogue, this is the wrong workflow. Bring a script you are willing to stand behind. The app's job starts when the writing stops.

Keep the two voices distinguishable

Two similar voices are worse than one good voice. The listener loses track of who is speaking and the conversation turns into a blur. Audition both voices on the same sentence before you commit, and listen on a laptop speaker rather than headphones, because that is how a lot of people will hear the show.

• Choose voices that differ in pitch, pace, or texture, not just in name.
• Keep the Host voice stable across episodes so the show has a recognizable sound.
• Write shorter turns for the guest and slightly longer setup lines for the host. Equal-length turns sound mechanical.
• Test names, product names, and numbers in both voices. A pronunciation problem in one voice is easy to miss when you only audition the other.
• Do not use a cloned voice unless you own it or have written permission from the person. A familiar voice also carries expectations the script may not meet.

If the two voices still sound alike after auditioning, change the model rather than stacking effects on the export. Pitch shifting a finished voice makes it sound processed. A different preset or a different model family is the cleaner fix.

Check the script before you generate

Read the dialogue out loud once, all the way through. This catches most problems before they become audio: a sentence that cannot be said in one breath, a name with two possible pronunciations, a number that reads differently as a figure than as a word. Fix the script, not the take, when the problem is in the writing.

• Write out ambiguous abbreviations the first time they appear.
• Replace symbols with words: say percent, not the percent sign, and say dollars, not a dollar sign.
• Check homographs and names in context, since the voice has no way to ask which reading you meant.
• Keep most turns under about three sentences. Long turns are harder to regenerate cleanly and harder to follow.
• State plainly when a voice is synthetic if your audience or platform expects disclosure. Rules differ by show and by network.
• Leave a note in the script for anything you plan to add later, such as music or a sponsor read, so the gap is intentional.

The podcast script example shows a different structure for a solo episode, and the multi-voice podcast workflow covers sponsor reads and section-by-section revision. Both are useful comparisons if your notes do not naturally split into a conversation.

Export the episode and the transcript

The app exports the timeline mix as WAV or M4A. Use WAV when the episode will be edited further, normalized, or mixed with music. Use M4A when you want a smaller delivery file, and note that timeline markers become chapter markers in M4A. The export sheet can also write separate clip files, a text transcript, and a CSV of marker times.

The transcript is not an optional extra. The W3C's media guidance states that prerecorded audio-only content needs a transcript to meet WCAG Level A, and lists identifying speakers as an optional extra. Apple Podcasts generates transcripts automatically after publication and also accepts a provider-supplied VTT file, which can identify every speaker with each line. Murmur's own transcript export is plain text, so you would convert it to VTT yourself. If you export a plain text transcript from the app, keep it as the source for the published version and check names and numbers by hand.

The WAV, M4A, and MP3 export guide explains which file to keep as a master and which to send to a host. If your notes are study material rather than a show, the study notes to audio workflow is a closer fit than a two-host format.

A short pre-flight checklist

1. The script has a speaker label on every line and no unlabeled paragraphs.
2. Both speakers have a voice, and the two voices are clearly different on a laptop speaker.
3. Names, numbers, and abbreviations have been read aloud once in each voice.
4. Every note from the source file appears in the dialogue or was deliberately cut.
5. The opening line gives a reason to keep listening, and the closing line gives one action.
6. The exported file plays from start to finish, and the transcript matches the final audio.

That checklist takes a few minutes and prevents the most common failure: a polished voice track that says the wrong thing. The Projects workspace keeps the script, cast, and timeline together, so a correction is a block regeneration rather than a rebuild.

Frequently asked questions

Can this workflow turn my notes into a podcast automatically?

No. Murmur does not summarize notes or write a script. You or an assistant you choose produce the two-host dialogue, and the app renders it with the voices you assign. Its value is the multi-speaker project, local generation, and export, not the writing.

How long should a notes-based episode be?

There is no correct length. A short explainer may need three minutes, while a teaching episode may need twenty. Let the notes decide: if a section does not change what the listener knows or does, cut it. Time the finished audio rather than estimating from the word count.

Do I need two different models for two voices?

No. A project uses one model, and each speaker is assigned a voice that model supports. Kokoro offers preset voices, and cloning-capable models can use saved reference profiles. Choose the model first, then confirm it has two voices you can tell apart.

Can I fix one bad line without regenerating the whole episode?

Yes. Generated audio sits on the timeline as clips. Select the clip for the line you want to change, edit the script text if needed, and use Regenerate Block. The rest of the episode stays as it was.

Should I tell listeners the voices are synthetic?

Disclosure rules vary by platform, sponsor, and audience, so check the requirements that apply to your show. A short line in the episode or show notes is usually enough. Never clone a voice without owning it or having written permission.

Sources

• W3C WAI: Transcripts
• Apple Podcasts for Creators: Transcripts on Apple Podcasts

Try Murmur - $49 one-time. No subscriptions, no cloud, no per-character fees.

Originally published at murmurtts.com