The Short Answer
If search returns the right episode and you still have to scrub to find the moment, the retrieval unit is the episode, not the moment. An episode-level index compares your question against one transcript, or worse, only a title and description, so the best it can ever hand back is a whole file. Fixing this is not a better transcription model. It is indexing the transcript at the segment level, with a start and end timestamp on every piece, so the thing that matches your question is the thing you actually wanted: the forty seconds where it was said.
Why episode-level search strands you inside the file
An hour of audio has one transcript if you index it as one document. Every question you ask gets compared against that one block of text, so the system can only ever tell you which FILE is closest to your question, never which MINUTE. You get the right episode, correctly, and then the actual work, listening at 2x speed until you hear the thing, still belongs to you.
It gets worse when the index is thinner than a full transcript. A lot of podcast search is built on title, description and show notes alone, because that is what the RSS feed hands you for free and a full transcript costs money to generate. That index can genuinely tell episode 47 from episode 12, but it has no idea what happens at minute 34 of either one, because nothing at that resolution was ever compared.
Tell whether you are indexing episodes or moments
Two checks settle it in under a minute.
| Check | What you do | What it means |
| 1. Look at what came back | Print the actual matched text, not the episode title | If it is a title and description, you are searching metadata, not audio |
| 2. Look for a timestamp | Check whether the result carries a start and end time | If the only timestamp is the episode's publish date, the unit is the whole file |
Fixing it: index at the segment level
A transcript is not naturally one document. Automatic speech recognition already produces it in pieces: sentences, or utterances bounded by pauses and speaker turns. Indexing THOSE pieces, each with its own start and end time, is what turns "which episode mentions this" into "which forty seconds said it."
The retrieval unit change is the whole fix. Nothing about the audio, the ASR model, or the search algorithm has to be better; the thing being compared against your question just has to be a few seconds of speech instead of an hour of it.
How this looks on Mixpeek
# 1. bucket: land every episode
POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"audio","type":"audio","data":"https://your-storage/episodes/ep-214.mp3"}]}
# 2. collection: transcription and segmentation run on arrival
POST /v1/collections
{"collection_name":"episodes",
"source":{"type":"bucket","bucket_ids":["{bucket_identifier}"]},
"feature_extractor":{"feature_extractor_name":"multimodal_extractor","version":"v1"}}
# 3. retriever: search what was said, not what the episode is about
POST /v1/retrievers/{retriever_id}/execute
{"inputs":{"query":"the part where they talk about switching from Postgres to a vector database"}}multimodal_extractor@v1 transcribes the audio and indexes it at the segment level rather than as one block per file, so each result the retriever returns carries the start and end time of the moment that matched, not just the episode it came from. That is the difference between a result you can click and a result you still have to search inside.When segment-level still is not precise enough
Segment-level timing is bounded by wherever ASR happened to place a sentence boundary, which is usually close enough to jump to and start listening. It is not word-accurate. If you need to cite the exact half-second a specific word was spoken, for captioning, for a legal transcript, or for an agent that has to quote verbatim with a defensible timestamp, that is a second pass called forced alignment, and it is a different technique with its own tradeoffs. Forced alignment for AI agents covers word-level timestamps, diarization, and why word-level is not always the right unit either.
Frequently Asked Questions
Will a better transcription model fix this?
No, and it is the most common wasted upgrade. A more accurate transcript is still one thing to compare your question against if it is indexed as a single document. The problem is the retrieval unit, not the transcript's accuracy. A perfect transcript indexed as one block still only ever returns the episode.
Do I need speaker labels to search "what did the guest say about X"?
Not to find the moment, but it helps once you are there. Segment-level search finds the span where a topic was discussed regardless of who said it. Diarization, attaching a speaker label to each segment, lets you filter to "only what the guest said" rather than the host's question that prompted it. It is a separate step from segmentation and worth adding once moment-level search already works.
How is this different from full-text search on the transcript?
Full-text search matches literal words. "Switching from Postgres to a vector database" only matches if someone said close to those words. Semantic search over the same segments matches the topic even when the guest phrased it completely differently, which is most of the time in a real conversation. The segment-level indexing fix applies to both; semantic search is what makes the moment findable when you do not know the exact phrase.
Two episodes both mention the topic. How do I know which one has what I need?
The retriever returns ranked segments with scores, and each carries its own episode and timestamp, so you get both candidates back as separate, comparable results rather than one ambiguous file match. Reading the actual matched text (the first check above) is what tells you which segment is the one you meant, faster than opening either episode.
Does indexing at the segment level cost more than indexing by episode?
Transcription is billed once per file regardless of how the output is chunked afterward, so segmenting an hour-long episode into fifty spans does not multiply the transcription cost. It does create more indexed units, which is the tradeoff every segment-level index makes: more precise retrieval, more rows to store.