The aligner that failed and said it succeeded

The symptom nobody would have looked for

Ten books had been processed and the log said all ten succeeded. A verification step ran over each one and passed. Read-along worked when you opened it.

It worked at the start of a chapter. Measuring spoken seconds against runtime gave a different picture: coverage ran from 100% down to 32%, and one book had a three-hour stretch with no alignment at all. The figure was monotonic in chapter length across the entire shelf, which is the shape of a resource limit rather than a content problem.

A kill, reported as a skip

Each chapter was handed to the aligner whole, and any non-zero exit code was counted as `skipped`. An eighty-minute chapter returns code 137 in about ten seconds. That is the OOM killer, not a skip. Peak memory measured against window length: 300 seconds needed 64 MiB, 600 needed 278 MiB, 900 needed 575 MiB. Anything past roughly twenty minutes died on a machine with a few hundred megabytes free.

The verification step could not have caught this. It proved the map was generated from the right source text, which was true. It never asked whether the map reached the end of the book. A component that reports “skipped” for something it was killed doing is not emitting a warning. It is emitting silence, and everything above it believes the silence.

Bounded windows

Chapters stay the outer anchor, because chapter boundaries are exact and publisher-supplied and stop error accumulating across a book. Below that, no call ever sees more than 600 seconds of audio. A long chapter is walked by overlapping windows that re-anchor on their own output with both ends pinned by the chapter, so a failed window now costs a window instead of a chapter.

One book went from 69% to 93.7% coverage. Another aligned all 24 chapters at 99.9%, processing five and a half hours of audio in four minutes.

A fix that made it worse

Worth recording because it was plausible. The window walker also treated “the text estimate has reached the last line” as a signal to stop. For any chapter under about fifteen minutes that condition is true on the first window, so the whole chapter’s text was aligned against its first ten minutes of audio. Coverage fell from 93.7% back to 68.2% with an identical fragment count, which is exactly the kind of regression that hides from a check counting outputs. Reverted.