Labelling Speakers in Captions for a Video Podcast

A video podcast with three people at one table is the hardest thing I caption, and it is not because of the words. The words are easy, a transcription tool gets most of them right. The trouble is that a viewer watching with the sound off sees a line of text at the bottom of the screen and has no idea which of the three faces said it. If the camera is on a wide shot, they guess. If the edit has cut to the listener for a reaction, which good podcast editors do all the time, they guess wrong.

I produce interview shows, and for a long time I treated captions as the last export before upload. Then a deaf listener wrote to say she had followed an entire episode believing my guest held an opinion that was actually mine. She was not careless. My captions gave her no way to tell us apart. That email changed how I build every caption file now, and the method is simple enough to set up in an afternoon.

Why speaker changes get lost in auto captions

Automatic captions on YouTube, and the transcript panels inside most editing applications, are built around one voice. They split text by timing and line length, not by who is talking. When two people overlap, or when one person answers in two words before the other continues, the tool usually merges both into a single caption block. The result reads like one person arguing with themselves.

Some tools now offer speaker detection, often called diarization. It helps, but in my experience it is the least reliable part of the whole transcript. It tends to confuse voices of similar pitch, and it gets thrown by laughter, a cough, or a guest leaning away from the microphone. On a two person show with very different voices it might be right most of the time. With three hosts of similar age and accent, I check every label by hand and I still find mistakes on a second pass.

There is also a timing trap. Podcast editors cut out pauses, so speaker changes in the final video happen faster than they did in the room. A caption that was correctly attributed in the raw recording can end up straddling a cut, half on one face and half on another.

The three ways to show who is talking

Broadcast subtitlers have used a handful of conventions for decades. They are not equally good for a podcast, and the one most people reach for first is not the one I would pick.

Name labels in brackets

This means writing the speaker's name at the start of a caption whenever the speaker changes, for example [MAYA] or MAYA:. It is the most explicit option and the one accessibility guidance tends to recommend when the speaker is off screen or not obvious. The cost is space. A name eats eight or ten characters of a line that is usually capped somewhere around 32 to 42 characters, so captions split more often.

Leading dashes for two speakers in one caption

Film subtitles often put two short lines in one block, each starting with a hyphen, to show a quick exchange. It works well in drama where faces are on screen. In a podcast it falls apart when the edit cuts to a reaction shot, because the viewer cannot match the hyphen to anyone. I use it only for fast back and forth, such as "Really?" followed by "Really."

Colour coding

Assigning each host a caption colour sounds tidy, and the UK broadcast tradition used it heavily. On online platforms it is fragile. Many players ignore colour in uploaded files, viewers can override styling in their own caption settings, and colour alone fails anyone who cannot distinguish the shades you picked. Treat it as decoration on top of names, never as the only signal.

Name every change, not just the off screen ones

The common advice says to label a speaker only when they are off camera. I followed that for about a year and stopped. In a multicam podcast edit, nobody decides in advance which shots are on camera. The editor cuts to a reaction, the guest keeps talking, and suddenly a caption that needed a label does not have one. Checking every cut against every caption to apply the rule correctly takes longer than labelling every change.

So my rule now is blunt: whenever the speaker changes, the next caption starts with that person's name in capitals and a colon. Within one person's turn, no repeats. Viewers stop noticing the labels after a minute or two, much the way readers stop noticing quotation marks.

If a viewer has to look at faces to work out who said a line, the caption has only done half its job.

Keep the names short. Use first names, or the name the hosts call each other on air. If two hosts share a first name, pick initials or surnames once and keep them for every episode, because regular viewers learn them.

A workflow that fits a weekly show

Here is the order I work in for a 50 minute episode with two hosts and one guest. It adds roughly 20 to 30 minutes to my caption pass, and most of that is the first step.

Export the transcript from the locked edit, not the raw recording, so every timestamp matches the cuts the viewer will see.
Run speaker detection if your tool has it, then rename the generic labels such as Speaker 1 and Speaker 2 to real names straight away. Leaving them generic invites mistakes later.
Play the episode at normal speed with the waveform visible and fix every label at a speaker change. Most errors cluster around laughter and interruptions.
Split any caption block that contains two speakers, unless it is a very short exchange you want to keep together.
Add the name label to the first caption after each change, then reread the line lengths, because labels push some lines over your limit.
Export to SRT or WebVTT and watch the first five minutes on a phone with sound muted. That is how a large share of your caption readers watch.

Two details save time. First, keep a text file per show listing the exact label for each regular voice, so the spelling never drifts between episodes. Second, if your editing app lets you save a transcript with speaker names, keep it with the project. Our captions section has more on what to keep, and the piece on caption file formats that survive re-uploads explains why SRT is safer than relying on styling.

Where burned-in text makes this worse

Short clips for social platforms usually get captions burned into the picture, often with large animated words. Those styles show one or two words at a time and almost never carry names. For a single speaker clip that is fine. For a clip with two voices, it removes the viewer's only clue. If you must burn in text on a conversation clip, add a small lower third with the name each time the speaker changes, or choose a clip where one person talks for the whole minute. I covered other reasons to avoid the habit in why burned-in subtitles are usually the wrong choice.

I do not have a perfect answer for overlapping speech. When three people laugh and talk at once, I caption the most important line, label it, and add [crosstalk] rather than trying to fit everything. Broadcasters handle it the same way, and I have yet to hear from a viewer who wished I had squeezed in more.

Something to try on your next episode

Take your most recent episode, open the caption file, and search for every point where the speaker changes in the first ten minutes. Count how many of those captions carry a name. On my own back catalogue the answer was almost none. Fix those ten minutes, upload the corrected file, and then watch the same stretch with the sound off. You will see straight away whether a stranger could follow who said what.