ASR long-form: sentence-final period lost when a window ends inside the pause before the next sentence (both paths)

Aperta
  • Qualcosa non va?
#1,110 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@maboa ci sta già lavorando.

Dal 5/11/2026.

  • #1111 di @maboa — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
swift
Ambito
audio-video-rtc

Direzione di ricerca

Start by reading the long-form windowing code for both mel-context and no-mel paths, then inspect the final-window trimming change in #800 and its revert. Reproduce the reported pause-boundary cases with the CLI and compare each window’s tokens before merging. Done when both paths preserve sentence-final punctuation at interior window boundaries without disturbing seam matching.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

On long-form audio a sentence loses its final period when a sliding window ends inside the pause that follows it. The next window starts in the pause, hears the next sentence and capitalises its first word, but the period belongs to the previous window, which never emitted it: …let me just go into one here So this is a classic interactive transcript.

It happens on both long-form paths (mel-context with fixed-stride windows, and the default no-mel path with silence-aligned starts), on v3 and on Ultra, and the seam-gap repair pass makes no difference. Same family as #747 / #803 (a window ending inside silence), but it is punctuation that goes, not words.

Evidence

A 154 s English screen-recording narration (available on request), decoded with the CLI at aa9c19a7 (0.17.4 + #975 + #1021 + #1061).

The window never emits the period. A temporary print of each window's tokens before the merge:

WINDOW 1 start=12.88: … ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected]
WINDOW 2 start=25.76: ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected] ▁[email protected] [email protected] [email protected] …
WINDOW 9 start=115.92: … ▁[email protected] ▁[email protected] ▁[email protected] [email protected] [email protected] ▁[email protected]
WINDOW 10 start=128.80: ▁[email protected] ▁[email protected] '@131.76 [email protected] ▁[email protected] …

Window 1 runs to 27.84 s; the pause after "here" lasts until 29.6 s. Window 9 runs to 130.88 s; the pause after "to" lasts until 131.36 s. Neither window contains a . token, so the merge has nothing to keep. (Merge on/off, repair pass on/off: identical.)

The model emits the period late, at the next speech onset. In the same windows, periods inside a window sit a median 0.32 s after their word and up to 3.28 s after it, always just before the next piece: ▁sim il [email protected] [email protected] ▁[email protected] art. So a window that ends in the pause, before the next onset, is cut off before the period is due.

Each window alone gets its period. The same spans decoded as standalone files (-ss 12.96 -t 14.96, -ss 116.64 -t 14.96) end ▁here . and ▁to . — because the final window is trimmed to its last speech frame (#800), so the audio ends and the deferred period is emitted.

Default path, same loss elsewhere. Without --mel-context the 129 s case passes but the same pause now yields here. um So: the window boundary moved and the word before it lost its period instead.

Suggested fix

End a window at its last speech-bearing frame when its tail is dead silence — the rule #800 applies to the final window — for interior windows too, but only when the silent tail is longer than the punctuation latency measured above (≳ 0.5 s), not for every window. #800's revert of the all-windows snap was about perturbing dozens of windows per hour on ≥ 80 ms runs; a threshold at a few hundred ms touches only windows that end in a real pause, where the model has nothing to decode anyway, and gives it the audio end it needs to close the sentence. The overlap region keeps all its speech, so seam matching is unaffected.

An alternative at the merge would insert a sentence-final mark when the left side ends unpunctuated, the right side starts with a capitalised word and the gap is long, but that is language-shaped guessing, and the trim fixes the cause.

Lingua principale
Swift
Stelle
3k
Fork
451
Merge medio
2g 1h
PR unite (30g)
89

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di FluidInference/FluidAudio

Tutte le issue di FluidInference/FluidAudio

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.