Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

v0.17.0: window merge duplicates words on long audio (single-window decode of the same audio is correct)

Aperta
  • Qualcosa non va?
#954 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

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

Direzione di ricerca

The cross-window merge lives in AsrManager+Transcription.swift, introduced by the window-entry rework for #855/#897; start by reading redecodeEmissionJitterFrames (=5) and reconcileFinalWindowSeam, and how a re-decoded window's head is stripped. Reproduce with the reporter's ~660 s WAV via fluidaudiocli transcribe talk.wav --word-timestamps --output-json out.json and diff the token stream against v0.15.6. Done means the inserted "no no" and "presentation presentation" pairs vanish while single-window decode, punctuation and speed stay unchanged; the reporter can supply the audio and test a patch.

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

Descrizione

Since v0.17.0, transcribing long audio duplicates occasional words. The same audio decoded as a single window is correct, so it is the cross-window merge rather than the acoustic model.

Noticed while upgrading an app from 0.15.6 to 0.17.0.

Reproduction

A ~660 s recording of a conference talk (single speaker, natural hesitant delivery), 16 kHz mono WAV, through the CLI at each tag:

fluidaudiocli transcribe talk.wav --word-timestamps --output-json out.json
doubled-word pairs in 1,6xx words
v0.15.6 8
v0.17.0 9

Most are genuine — the speaker really does say "taking taking", "the the", "I I". The interesting ones are the two v0.17.0 adds:

v0.15.6   …they gave them no budget and uh no guidance on like what the regulation…
v0.17.0   …they gave them no budget and uh no no guidance on like what the regulation…
                                            ^^^^^

v0.15.6   …It also can use JSYC which is another experiment presentation library.…
v0.17.0   …It also can use JSYC, which is another experiment presentation presentation library.…
                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^

v0.17.0 also loses one I I that v0.15.6 emitted, so the net count barely moves — but the inserted tokens are new.

The part that localises it

Cutting a 14.5 s clip of the same audio around each word — short enough to decode in one window, so no merging happens — gives the correct text at both versions:

clip around "no"            0.15.6: …gave them no budget and…
                            0.17.0: …gave them no budget and…
clip around "presentation"  0.15.6: …another experiment presentation library. Then…
                            0.17.0: …another experiment presentation library. Then…

Same model, same audio, correct output. The duplication appears only when that audio is part of a longer file that gets windowed.

Where I would look

This looks like the window-entry rework in AsrManager+Transcription.swift for #855 / #897 — every window after the first now re-decodes from frame 0 on a fresh decoder state with source-level emission suppression, leaving dedup "only the jitter margin" (redecodeEmissionJitterFrames = 5). The leaked tokens are short function words and word-initial repeats, which is what I would expect if a re-emitted token lands outside that margin or is not matched by reconcileFinalWindowSeam's head-stripping.

One caveat on the evidence: the reported startTime of both inserted tokens (179.28 s and 386.56 s) does not fall inside a nominal overlap region for 15 s windows at 13 s stride, so I could not confirm alignment from timestamps alone. The clip test above is the stronger signal.

Why the benchmarks may not show it

Both cases sit in hesitant, filler-heavy delivery ("uh no guidance", a restarted phrase). Clean read speech does not seem to trigger it — a 64 s single-speaker studio narration produced zero doubles at either version, with only punctuation differences. Utterance-level corpora like LibriSpeech would also never exercise the window merge at all.

Happy to share the sample audio if useful, and to test a patch.

Not a regression report against the fix itself

To be clear, 0.17.0 is otherwise a clear improvement in our testing — noticeably better sentence punctuation, ~28% faster, and the macOS 14 BNNS diarizer warning in 0.15.7 matters to us. The old mid-window entry dropping 10 s of speech is plainly worse than a duplicated "no". This is a rough edge in the new approach, not an argument for the old one.

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

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.