Nova-3 STT – Incorrect Word Durations & Duplicate/Overlapping Segments

[ofirBigvu]

🐛 Nova-3 STT – Incorrect Word Durations & Duplicate/Overlapping Segments

Hello Deepgram Team,
My name is Ofir, and I’m a backend developer integrating the Nova-3 STT model into our production pipeline. While testing the new model, I encountered two critical issues that affect timestamp reliability and transcript integrity.

---

Issue 1: Words Produced With Unrealistically Long Durations

In several responses from Nova-3, some words span many seconds — far beyond any plausible spoken duration.

Example A

"word": "i",
"start": 687.42,
"end": 706.94,
"confidence": 0.22619629,
"punctuated_word": "I"

Duration: 19.52 seconds
Request ID: a0820f89-8a91-4371-998e-14d59814cd02

Example B

"word": "so",
"start": 96.945,
"end": 115.744995,
"confidence": 0.45412618,
"punctuated_word": "So"

Duration: 18.80 seconds
Request ID: fcca0528-f0e7-4fa6-9d86-9b0366474ccd

Impact:
These durations break word-level alignment and make captioning and transcript syncing unreliable.

---

Issue 2: Duplicate Word Sequences With Overlapping Timestamps

Some transcripts contain duplicated segments where an entire word sequence appears twice with slightly shifted timestamps.

Request ID: 7cb9c1f2-0294-4e64-8dd3-0e2eb76902a5

First occurrence:

{ "word": "moments", "start": 27.145, "end": 27.945 },
{ "word": "are", "start": 28.025, "end": 28.345 },
{ "word": "where", "start": 28.345, "end": 29.064999 },
{ "word": "real", "start": 29.064999, "end": 29.625 },
{ "word": "growth", "start": 29.625, "end": 30.105 },
{ "word": "happens", "start": 30.105, "end": 30.505001 },

Duplicate overlapping occurrence:

{ "word": "moments", "start": 27.42, "end": 27.98 },
{ "word": "are", "start": 28.06, "end": 28.38 },
{ "word": "where", "start": 28.38, "end": 29.02 },
{ "word": "real", "start": 29.02, "end": 29.66 },
{ "word": "growth", "start": 29.66, "end": 30.06 },
{ "word": "happens", "start": 30.06, "end": 30.86 }

Impact:
This results in duplicated text and inconsistent timing, affecting transcript accuracy and alignment pipelines.

---

Summary

1. Words with unrealistic durations (15–20+ seconds).
2. Duplicate word sequences with overlapping timestamps.
3. Issues impact subtitle creation, alignment, and word-based analysis.

---

Request

Could the Deepgram team investigate whether this is
A model-level timing bug, Or an unintended behavior of the Nova-3 architecture?

I can provide full JSON responses or audio files if needed.

Thank you!
Ofir

[deepgram-community[bot]]

Thanks for asking your question. Please be sure to reply with as much detail as possible so the community can assist you efficiently.
_{Consider joining our Discord community for more opportunity to engage with your fellow Deepgram users. You can earn points which can be redeemed for cool stuff by being active in our communities!}

[deepgram-community[bot]]

Hey there! It looks like you haven't connected your GitHub account to your Deepgram account. You can do this at https://community.deepgram.com - being verified through this process will allow our team to help you in a much more streamlined fashion.

[deepgram-community[bot]]

It looks like we're missing some important information to help debug your issue. Would you mind providing us with the following details in a reply?

• The programming language you are working in (e.g. JavaScript, Python).

[ofirBigvu]

The code is written in Python

[jkroll-deepgram]

Hi @ofirBigvu, I'm sorry that these cases have been unexpected and difficult as you build with Deepgram. In rare cases, our timestamp algorithm falls back to estimating timestamps with more basic algorithms. This tends to be a rare enough case that while it can impact individual calls, it is not a widespread occurrence, and can be accepted or handled as each application finds best.

What percentage of your test calls have you observed this on? What is the critical blocker on your application side when this does occur?

If you share full JSON transcripts (or larger excerpts), we can look further to better explain these cases.

Since you have the test audio files - do you find that these issues are deterministic and can always be replicated with a particular audio file? Or is it nondeterministic and only sometimes occurs on the same audio?