0.8.1: stop rewriting the timeline, and let the prompt reach the model - #38
Merged
Conversation
Cierra #35 y #36. silenceremove encabezaba la cadena de limpieza, y borrar pausas reescribe la linea de tiempo: cada cue despues de la primera pausa removida quedaba adelantada, con error acumulativo y no un offset constante que un consumidor pudiera restar. Medido sobre una grabacion de 90.538s, el audio que llegaba al modelo corria 88.966s: 1572ms de deriva, sin nada en la salida que lo dijera. Y no compraba nada: misma grabacion, 436 cues con y sin, y la corrida sin el era mas rapida (7.6s contra 8.7s). Verificado end-to-end: input 90538ms contra transcrito 90539ms, 1ms de diferencia. El preset verbatim ademas nunca llegaba al modelo. El prompt inicial ES contexto de texto, y el default --max-context 0 lo descarta, asi que una corrida con prompt volvia identica byte a byte. Ahora, cuando hay prompt y el contexto es 0, se abre lugar. Verificado por contenido y no por flags: el preset recupera 'Ok.' y 'Eh,' que la corrida sin prompt limpiaba. Ojo con lo que este fix NO arregla: el drift de timestamps que vcut reporta baja de 28% a 25% de las cues pero el peor caso sube de 1318ms a 1418ms. Ese resto es el modelo estirando palabras hacia el silencio, un fenomeno distinto del timeline reescrito. coverage() suma inputDurationMs, transcribedDurationMs y lastCueEndMs a los tres backends. Tres numeros y ningun veredicto: un transcript corto se leia igual fuera silencio, corte temprano, o el archivo equivocado.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes and the reporting that would have made both visible. Closes #35, #36.
The timeline was being rewritten
silenceremoveled the cleaning chain, so pauses were deleted before transcription. That moves every cue after the first removed pause, and the error accumulates rather than being a constant offset a consumer could subtract.It also bought nothing. Same recording, with it and without: 436 cues either way, and the run without was faster — 7.6s against 8.7s, because dropping pauses costs more in the filter than the shorter audio saves in the model.
dynaudnormandafftdnstay; both preserve duration.After: input 90538ms, transcribed 90539ms. One millisecond.
--preset verbatimnever reached the modelShipped in 0.8.0 and inert. The flags were built into the whisper invocation correctly and then discarded: an initial prompt is text context, and the default
--max-context 0throws it away. A prompted run came back byte-identical to an unprompted one, which is exactly what I measured in the 0.8.0 PR and wrongly attributed tosilenceremove.The default is worth keeping when nothing was asked for — it stops the model carrying its own hallucinations forward between windows — so the fix opens room only when a prompt exists.
Verified by content rather than by flag inspection:
Ok.andEh,are the material a cutting tool reads.What neither fix changes
A consumer measuring transcript positions against audio energy still finds drift, because the model stretches a cue backwards into the pause before a word. Measured with
vcut detecton the same recording: cues claiming a word starts inside measured silence went from 28% to 25%, while the worst single case rose from 1318ms to 1418ms.That is a different phenomenon from a rewritten timeline, and this release does not address it. Saying so because the two are easy to conflate — I conflated them when filing #35.
Coverage reporting (#36)
Three numbers, no verdict. The gap between the first two is what the cleaning stage changed; the gap between the second and third is audio that produced no words. A short transcript used to read the same whether the recording was mostly silence, the model stopped early, or the wrong file was handed in — the confusion that produced a false bug report against this project earlier today.
Present on all three backends. The caller decides what is suspicious for its own material, which beats a threshold picked here.
65 tests pass, lint clean. Schema and changelog updated.