Pick the right pattern for putting a long audio recording into context for a text model

An hour of audio is roughly 9,000 words once transcribed, or about 12,000 tokens. A long meeting or interview can easily run two or three hours. That is way more than you want sitting in a context window for a single question, and even if the budget allows it, the model will struggle to find the relevant moment in a flat transcript. The right pattern is **transcribe, segment, retrieve, assemble**. **Transcribe** with a quality ASR system: Whisper-large-v3, AssemblyAI, Deepgram Nova-3. Output text with timestamps and ideally speaker labels. **Segment** by speaker turn or by short time windows. A typical segment is one speaker's utterance lasting 5-30 seconds. Store each segment with its timestamp range and speaker id. **Retrieve** the segments relevant to the current question via vector search over segment embeddings (often combined with keyword search for proper nouns and timestamps). **Assemble** the retrieved segments into the prompt with their timestamps and speaker labels intact, place them near the user's question at the bottom of the prompt, and ask the model to answer with citations to specific timestamps. The wrong options each fail differently. Dumping the whole transcript at the top wastes tokens and triggers lost-in-the-middle on long audio. Sending raw audio bytes does not work for text models (use a multimodal model if that is the goal, but the question is about text models). One-paragraph summaries discard everything and only work for the most generic questions.

**Transcribe to text, segment by speaker turn with timestamps, retrieve only the relevant segments, place them with the question at the bottom.** This pattern works because it respects three context-engineering constraints simultaneously. **Token budget**: only the relevant minutes hit the prompt, not the full recording. **Lost-in-the-middle**: the retrieved segments and the question sit in the privileged bottom of the prompt, not buried in a middle full of unrelated content. **Provenance**: timestamps and speaker labels let the model cite specific moments, which is critical for both correctness and downstream UX ('jump to 0:47:12'). The alternatives each break one of these. Dumping the full transcript at the top burns the token budget and puts the relevant moments in the middle trough. Sending raw audio bytes assumes the model can process audio, most text models cannot, and even multimodal models that accept audio (Gemini, GPT-4o native audio) often perform worse on long audio than on transcribed text retrieval. Summarizing the whole recording and discarding the rest loses the granularity the question needs. The segmentation choice matters. Pure time-window segmentation (every 30 seconds) is simplest but cuts across natural speech boundaries. Speaker-turn segmentation is better for dialogue (interviews, meetings). Topic-shift segmentation (using an LLM to detect topic changes) is best for monologues like lectures. Most production pipelines use speaker turns plus a maximum length cap (a 5-minute monologue gets split at sentence boundaries). The retrieval layer should index segment summaries or full segment text, often both. Hybrid retrieval (dense plus BM25) is helpful because audio transcripts contain unusual proper nouns and timestamps that exact-match search handles better than embeddings.