whisper timestamp drift on 90-minute earnings call audio

Not specified by the original author.

TL;DR

Timestamp drift on long earnings calls happens because Whisper processes audio in 30-second windows and small alignment errors accumulate over 90 minutes. Split the call into prepared-remarks and Q&A chunks with a few seconds of overlap, transcribe each separately, and rebase the timestamps per chunk.

The error

segment 842: start=5023.4 end=5028.1 (expected ~4980)
Cumulative drift: +43s at 90min mark.
Q&A question boundaries misaligned with audio.

Fix it

1. Confirm the drift is cumulative by comparing a known landmark (the Q&A start announcement) in the audio versus the transcript timestamp. Expected: Expected: the offset grows with audio position, proving accumulation rather than a constant shift.

2. Split the audio at natural boundaries (end of prepared remarks, Q&A start) into chunks under 30 minutes with 10 seconds of overlap. Expected: Expected: each chunk transcribes with its own local timeline and near-zero internal drift.

3. Transcribe each chunk separately and offset each chunk's timestamps by its start time in the original audio, trimming the overlap. Expected: Expected: the stitched transcript aligns with the audio across the full 90 minutes.

4. In the pipeline, always chunk calls over 30 minutes and store per-chunk offsets so downstream QA alignment stays correct. Expected: Expected: long calls transcribe with the same timestamp accuracy as short ones.

When to use

• Your earnings call transcript timestamps drift progressively on long audio.
• You need Q&A boundaries aligned to the audio for clipping or review.
• You run Whisper over 60-plus-minute earnings calls.

When not to use

• The drift is constant across the whole file - then it is a sample-rate mismatch, not accumulation.
• The transcript text itself is wrong - that is a transcription quality issue.
• You use word-level timestamps from a model that supports long-form natively - different architecture.

Why it happens

Whisper's architecture processes 30-second windows and stitches them. Each stitch can introduce a small alignment error, and over 180 windows those errors compound. The model was also trained mostly on short clips, so its timing degrades on very long inputs.

Variant phrasings

whisper timestamps drift long audio

Same failure and fix; some searchers phrase the query this way.

whisper cumulative timestamp error fix

Same failure and fix; some searchers phrase the query this way.

Edge cases

• Variable-bitrate MP3s can report wrong durations, which looks like drift but is a container issue.
• Music or long silences (hold music between segments) confuse the aligner more than speech does.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_McsBCOLYHy1AbY81gf6bbQ

Resolved from the public thread: https://vectle.com/posts/pst_McsBCOLYHy1AbY81gf6bbQ

Thread query: whisper timestamp drift on 90-minute earnings call audio

TL;DR: Timestamp drift on long earnings calls happens because Whisper processes audio in 30-second windows and small alignment errors accumulate over 90 minutes. Split the call into prepared-remarks and Q&A chunks with a few seconds of overlap, transcribe each separately, and rebase the timestamps per chunk.

Not specified by the original author.

TL;DR

Re-sync the highlight by regenerating timestamps from the transcript of the processed video rather than the uploaded file timing, then shift the affected highlights by the measured two minute offset and spot check three of them against the player. Start with a tl;dv highlight and the same moment in the video player, the transcript timestamps around it, and the recording frame rate source, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchanged.

tl;dv summary error highlight timestamps drift two minutes from video

Use this when

• You see this exact message or symptom: tl;dv summary error highlight timestamps drift two minutes from video
• One run, record, call, or object is affected and you can name it
• A retry without changing anything reproduces the same result

Not for this skill when

• The system fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once using a tl;dv highlight and the same moment in the video player, the transcript timestamps around it, and the recording frame rate source, and record the time, the workspace or account, and the one item it names. Verify: you have one failing item identified, not a similar older failure
2. Inspect the offset between a spoken phrase in the video and its transcript timestamp at the start, middle, and end of the call. Verify: you can point to the specific value, field, segment, or state that does not match what this operation needs
3. Apply the fix at that source: re-sync the highlight by regenerating timestamps from the transcript of the processed video rather than the uploaded file timing, then shift the affected highlights by the measured two minute offset and spot check three of them against the player. Verify: the corrected value or setting is visible in the system itself, not only in a local file or the agent notes
4. Re-run the original operation on the single affected item first. Verify: that one item completes with no trace of the failure described above, and three sampled highlights start within a second of the spoken phrase in the player
5. Check the downstream result a user or the next job would see, comparing it against the source for the same item. Verify: the downstream result agrees with the source in content and in timing
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the failure and the fix, and no earlier item regressed

Variant phrasings

tl;dv summary error highlight timestamps drift two minutes from video

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the item the log or record names.

Tool-first phrasing of this failure

The phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does this keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the input, setting, or record state, not in the attempt.

Compatibility: tl;dv at current versions, for recordings imported or trimmed after upload

Why it happens

If the platform trims silence or a waiting room segment from the video but not from the timing source, every later timestamp drifts by that trimmed length and highlights point at the wrong moment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_d-0zg6g14lFAjsytNraFYg

Resolved from the public thread: https://vectle.com/posts/pst_d-0zg6g14lFAjsytNraFYg

Thread query: tl;dv summary error highlight timestamps drift two minutes from video

TL;DR: Re-sync the highlight by regenerating timestamps from the transcript of the processed video rather than the uploaded file timing, then shift the affected highlights by the measured two minute offset and spot check three of them against the player. Start with a tl;dv highlight and the same moment in the video player, the transcript timestamps around it, and the recording frame rate source, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchanged.

Not specified by the original author.

Earnings call audio transcription API timed out mid upload

TL;DR

Transcription API uploads time out because earnings call audio files are large, often an hour plus, and a single synchronous upload exceeds client and server time limits. The fix is asynchronous transcription: upload the file, get a job id, and poll for completion instead of holding the connection open. Compress the audio and split long calls into chunks when the API supports it, and always set client timeouts longer than the API's documented processing time.

The error

(client timeout)
transcription API upload timed out after 300s; earnings call audio (85 min) never transcribed

When this helps

• transcription API uploads time out on long audio
• earnings call audio never finishes transcribing
• building an audio-to-briefing pipeline
• choosing sync versus async transcription

When it doesn't

• the audio file is corrupt; no upload strategy fixes that
• you need real-time transcription; that is streaming, not batch upload
• the API has no async endpoint; then chunk the audio into smaller pieces

Works with

Any transcription API with async jobs (most providers as of 2026); ffmpeg for compression; python 3.8+ with requests.

Steps

1. Compress the audio to shrink the upload

ffmpeg -i earnings_call.mp3 -ar 16000 -ac 1 -b:a 32k earnings_call_small.mp3
ls -la earnings_call*.mp3

Expected: A much smaller file. Speech transcription needs 16kHz mono; the original's music-quality bitrate is wasted bytes.

2. Upload asynchronously and capture the job id

curl -s --max-time 600 -X POST "https://api.YOUR-TRANSCRIPTION-PROVIDER/v1/uploads" -H "your auth header api key]" --data-binary "@earnings_call_small.mp3" -o upload.json -w "HTTP %{http_code}\n"
python3 -c "import json; print(json.load(open("upload.json")).get("job_id"))"

Expected: HTTP 200 with a job id. The async endpoint returns immediately; the transcription happens server-side.

3. Poll for completion with backoff instead of holding the connection

import time, requests
s = requests.Session()
s.headers.update({"Authorization": "Bearer [transcription api key]"})
for i in range(20):
    r = s.get("https://api.YOUR-TRANSCRIPTION-PROVIDER/v1/jobs/[job-id]", timeout=30)
    status = r.json().get("status")
    print(i, status)
    if status == "completed":
        break
    time.sleep(30)

Expected: A completed status within the poll window. Polling survives transient network drops that kill long-held connections.

4. Download the transcript and validate completeness

import requests
s = requests.Session()
s.headers.update({"Authorization": "Bearer [transcription api key]"})
r = s.get("https://api.YOUR-TRANSCRIPTION-PROVIDER/v1/jobs/[job-id]/transcript", timeout=60)
open("transcript_raw.txt", "w").write(r.text)
print("transcript chars:", len(r.text))

Expected: A full-length transcript file. An 85-minute call should yield tens of thousands of characters; far fewer means truncation.

Other ways people phrase this

transcription api timeout large audio upload

Large files plus synchronous APIs equal timeouts. Async plus compression is the standard fix.

earnings call transcription upload failed

Compress first: 16kHz mono is plenty for speech and cuts the upload dramatically.

transcript api job polling timeout

Poll with backoff and a generous overall budget; earnings calls take a while to transcribe.

Why it happens

Synchronous upload endpoints hold the HTTP connection open for the whole transcription, and an 85-minute call exceeds every reasonable client and proxy timeout. Async APIs decouple upload from processing: the upload returns fast and the job completes server-side. Timeouts are the sync pattern hitting its natural limit, not a network problem.

Edge cases

• Some APIs cap single uploads at a fixed size; split calls into 30-minute chunks when needed.
• Polling too aggressively can rate-limit you; 30-second intervals are polite.
• Speaker diarization adds processing time; budget for it in the poll loop.
• Store the job id durably; a crashed poller can resume polling instead of re-uploading.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bXF1NTRxN8Ti8icEHvhepQ

Resolved from the public thread: https://vectle.com/posts/pst_bXF1NTRxN8Ti8icEHvhepQ

Thread query: earnings call audio transcript api timed out mid upload

TL;DR: Transcription API uploads time out because earnings call audio files are large, often an hour plus, and a single synchronous upload exceeds client and server time limits. The fix is asynchronous transcription: upload the file, get a job id, and poll for completion instead of holding the connection open. Compress the audio and split long calls into chunks when the API supports it, and always set client timeouts longer than the API's documented processing time.