Hi, I am trying to align the transcript to the speech in audio (using

duration

,

endTime

and

startTime

), but all of the values returned by Get Call VAPI API are very off to the audio file's times. For example, you can already see in the screenshot that when I say "Hello?", the audio starts on roughly 0.9s, but message #2

secondsFromStart

returns 1.637s, off by 0.7 seconds. Even bigger difference, is message #4 for which audio starts on roughly 6.9s but

secondsFromStart

value is on 7.927s, resulting in 1s delay. I tried calculating using just

time

too, offsetting from the very first

time

from the first system message, but delays are still present. Note this happens to every single call I make, the call id for this example is

019a1b1c-c2bb-7338-b57c-a21dce505ff2

. https://cdn.discordapp.com/attachments/1431690406436798535/1431690407074467840/image.png?ex=68fe5518&is=68fd0398&hm=33a73792df51338e1c0d24ec8586005704922597e976cc3da81cff0377882ef6&

Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team

To quickly align your transcript with the audio, apply a fixed offset correction based on your observed delay. For example, if you consistently see a 0.7s delay, adjust your alignment logic like this:

python
# Example: Adjust transcript timing
corrected_time = transcript_time - 0.7  # Apply observed offset

This workaround helps until the underlying timing issue is resolved. For a permanent fix, report your findings (with call ID and a screen recording) to Vapi support as recommended in the [issue reporting guide](https://docs.vapi.ai/issue-reporting). Source: - [How to Report Issues Effectively](https://docs.vapi.ai/issue-reporting)

I wouldnt like to do that, its not consistently 0.7s

We will report this to the team to have them look at it

Thanks 👍

Just to make sure this is current, could you please provide a recent call id with this issue? Preferably within the last 3 days or so.

Sure -

019ac658-edf3-7994-b00a-d69c70b4997e

In this example audio actually starts around 0.6s but in messages it says 1.465s.

Hi, this is Sahil, Customer Support Manager at Vapi. I’m following up to check if you’re still experiencing this issue.

Yes this appears to still be an issue. Here is an example call id

019c03ad-4d11-7551-bdea-977fc7a0796f

It says "Hello?" message starts at 2.71 seconds, but it actually starts around 1.5 seconds. Is this somethig nthat is going to be addressed in the near time future? Thanks in advance!

The transcript timestamps (`wordStart`/`wordEnd`) don't match

secondsFromStart

because the Deepgram session resets during squad assistant handoffs. Why: When a squad handoff occurs (at ~3.7s into your call), the Deepgram WebSocket connection is re-established. ASR timestamps restart from 0, while

secondsFromStart

keeps counting from the original call start. That's why you're seeing a consistent ~3.74s offset. In your example: "Who is this calling?" shows

secondsFromStart: 9.677s

but

wordStart: 5.94s

— the difference is exactly the handoff time. Current status: This is a known limitation with squad handoffs. Workarounds: • Use

secondsFromStart

as your source of truth for accurate absolute timestamps • For relative timing within a single assistant's turn, `wordStart`/`wordEnd` are accurate • Calculate true word position:

wordStart + handoff_offset

Let me know if you need help implementing any of these workarounds.

Thank you for the help, but I have a few more questions on this. 1. Re my original problem "It says "Hello?" message starts at 2.71 seconds, but it actually starts around 1.5 seconds.", this message is said before the handoff happens and it is the very first message, so I would of assumed it would match the timings. 2. Where can I find all the details like wordStart and handoff_offset? I dont see them in the vapi call I GET.

Hi there, Thank you for following up. I'd be happy to help with your additional questions about the transcript timing inconsistencies. To provide you with the most accurate guidance, could you share: 1. Call IDs where you're seeing the timing mismatch 2. Which transcriber you're currently using (Deepgram, Google, etc.) 3. Which voice provider you're using (ElevenLabs, Cartesia, etc.) 4. Specific examples of the timing gap (e.g., "message appears at 0:15 in transcript but speech is at 0:25 in audio") In the meantime, here's what we know about this issue: Why Timestamp Drift Happens The transcript timestamps reflect when we receive the transcription from the STT provider, not necessarily the exact audio time. Factors that contribute to drift: • Network latency to/from transcriber • STT processing time • Buffering for accuracy vs speed tradeoffs Potential Solutions Option 1: Enable modelOutputInMessagesEnabled (if using ElevenLabs) This uses the LLM's original text output for assistant messages instead of transcribing TTS audio. This eliminates drift from assistant-side transcription. Note: Only works with ElevenLabs voices as they provide word-level timestamps. Option 2: Use recording timestamps If you need precise audio-aligned timing, the recording file itself is the source of truth. The call recording's audio timeline is accurate. Option 3: Custom transcriber with timestamp handling For precise control, a custom transcriber lets you manage timestamp assignment. Once you share the call IDs, I can dive into the logs to see exactly where the timing gap is occurring and provide more specific recommendations. Best regards, Sahil

We can look at the one I just shared with you, the ⁨`019c03ad-4d11-7551-bdea-977fc7a0796f`⁩. Deepgram was used for both transcribing and text to speech.

Hi, Thanks for reaching out about the transcript timing inconsistency. To help investigate this issue, could you please provide: 1. Call ID(s) where you're seeing the timestamp mismatch 2. Specific examples showing the discrepancy (e.g., "at 0:30 in the audio, the transcript shows 0:20") 3. Which timestamp field you're using from the artifact (e.g.,

secondsFromStart

,

time

,

endTime

) There's a known issue where the

secondsFromStart

clock can sometimes have slight offsets, particularly at the start of recordings. We've implemented some approximation logic to handle this, but certain edge cases may still occur. Once I have a call ID, I can check the logs and determine if this is a one-off issue or something systematic with your configuration. Best, Vapi Support

I see this in every single call. 1. a.

019c1d98-3cb9-7dd0-af95-fc4de07509a7

b.

019c154f-876a-788d-b7aa-330744d9e87a

c.

019c152c-c9a2-788a-8dfd-de31e76444b7

2. a. ~2.9s audio, transcript shows 3.76s. b. ~1.4s audio, transcript shows 2s c. ~1.4s audio, transcript shows 2.4s 3. Using

secondsFromStart

of the first message.

The transcript timestamps don't align with actual audio playback because

secondsFromStart

values are based on when transcripts are received from the STT provider, not when speech actually occurred. Network latency and audio buffering can contribute to drift. Workarounds: • Use

artifact.videoRecordingStartDelaySeconds

to offset timestamps when syncing with video/audio • Timestamps are still reliable for relative ordering of messages • For ElevenLabs users, enabling

modelOutputInMessagesEnabled: true

provides more accurate timestamps Can you share what you're using timestamps for and which transcriber/voice provider you're using?

I am using timestamps to showcase what was said in the call when in UI, by highlighting the transcript at each point of a playback audio. Now I do not see

videoRecordingStartDelaySeconds

in the GET Call response. As for transcriber and voice provider, for both I am using deepgram.

Timestamp drift between transcripts and audio is something we see fairly often, and there are a few different causes depending on your setup. To point you in the right direction, I need a bit more info. Can you share: 1. A call ID where you noticed the issue - I can pull the logs and see exactly what's happening 2. What you're seeing vs. what you expected - e.g., "transcript says 10.5s but speech starts at 8.2s in the recording" 3. Which timestamps you're using - secondsFromStart, time, endTime, or something else? 4. Your transcriber and voice provider - different STT/TTS combos have different timing behaviors Also helpful to know: • Are you trying to sync transcripts with video/audio playback, or just display them alongside the call? • Is the drift consistent (always off by ~2s) or random? • Does it affect both user and assistant messages, or just one side? Once I have the call ID, I can dig into the specific timestamps and figure out what's causing the mismatch for your use case.

You keep asking me for the call id, I have given you a few times before. Please refer to the previous conversation - https://discord.com/channels/1211482211119796234/1431690406436798535/1468151520003625032 > • Are you trying to sync transcripts with video/audio playback, or just display them alongside the call? Display them alongside the call > • Is the drift consistent (always off by ~2s) or random? It is random > • Does it affect both user and assistant messages, or just one side? Affects both

Hi N3squik, Sorry for the back-and-forth on this. I went through your calls and can now give you a straight answer. secondsFromStart counts from when the voice pipeline starts, but the audio recording doesn't start capturing at that same moment. There's a recording initialization delay that varies per call (typically 0.8–1.2s), so position 0:00 in your audio file doesn't correspond to secondsFromStart=0. That's why "Hello?" shows up at secondsFromStart=2.71 but appears at ~1.5s in the audio. For video recordings, we expose artifact.videoRecordingStartDelaySeconds to correct for this. For audio recordings, that field doesn't exist yet. It's tracked internally (PRO-289), and I'm pushing to get an audio equivalent added. For now, the most reliable workaround for your playback UI: calibrate using the first utterance in each call. You already know roughly where the first word appears in the audio (you mentioned ~1.5s for that call). Compare that to its secondsFromStart value (2.71), and the difference (1.21s) is your recording offset for that call. Apply it to all messages: audio_position = message.secondsFromStart - recording_offset If you want to automate this without manually listening, you could run basic voice activity detection on the first few seconds of the audio to find speech onset, then compute the offset from there. One more thing: some of your calls use squads with handoffs. After a handoff, word-level timestamps inside metadata.wordLevelConfidence reset because a new Deepgram stream gets created. The message-level secondsFromStart stays correct though, so stick with that for your playback sync.

Okay thank you, this is much more helpful now. If it would be possible, would you be able to reach out back to me if and when the

videoRecordingStartDelaySeconds

for audio is implemented (because I want to get the most accurate timing for transcript in the future)?

Sure, will do.