A 2.4-second silence gap buys five words of audio description

word_budget() is three operations. Subtract 0.30 seconds of padding from the measured gap, multiply by 2.5 words per second, truncate to an integer ^[12]. Run it on the second gap in the post's own silencedetect output, which lasts 2.4 seconds, and (2.4 - 0.30) x 2.5 gives 5.25, so int() takes it to five words ^[8][1]. The 3.648-second gap gets eight ^[2].

"A great 9-second description is a defect if the gap is 2.4 seconds," the post says ^[3]. At 2.5 words per second, nine seconds of narration is about 22 words, four and a half times what that gap will accept ^[5].

The two length thresholds in the pipeline are set independently and they do not line up. silencedetect runs with d=1.2, on the reasoning that a gap under about a second cannot hold a useful sentence anyway ^[7][10]. usable_gaps then drops any gap whose budget comes out under four words, and clearing four words takes a gap of at least 1.9 seconds ^[13][3]. So everything between 1.2 and 1.9 seconds is detected and then discarded ^[4]. The post wants those logged instead of silently dropped, because they are the moments where WCAG's extended audio description criterion 1.2.7, Level AAA, applies and the only fix is pausing the video ^[15].

The walkthrough tells you to check 2.5 for yourself: measure your own voice by rendering 100 known-length sentences and dividing, because voices and languages differ substantially ^[16]. Assume too high a rate and the budget overfills. A five-word line from a voice that actually speaks 2.1 words a second renders in 2.38 seconds against a usable window of 2.10, an overrun of roughly a quarter of a second ^[8]. Nothing upstream of the renderer catches that. Step five does: reject if the rendered audio is longer than the gap, then retry shorter ^[19].

silencedetect writes its silence_start and silence_end lines to stderr, not stdout, which is why find_gaps scans proc.stderr ^[6]. A parser reading stdout returns no gaps. The 0.15 seconds trimmed from each end exists because narration that begins the instant dialogue stops sounds wrong and clips on some decoders; that padding costs 0.75 words out of every budget ^[11][7].

The claim that the overrun check is "the step everyone skips" is the author's, offered without a survey of implementations ^[2]. The 47-gap count is one video ^[14]. For those numbers to transfer, your content needs similar dialogue density, your noise threshold has to be strict enough for its music bed, and your TTS voice has to run near 2.5 words a second ^[9][16]. The last two steps leave the original track alone: step six overlays narration on the original audio, and step seven ships the result as a second audio rendition in the HLS ladder ^[18].