Beyond the Thirty-Second Window: Duration, Not Memory, in a Fixed-Frame TTS Model

Long-form text-to-speech is usually evaluated by varying how much text is requested, which changes duration and text length at once. We separate them with two designs: a 124-word passage held fixed and requested at 40 and 60 s, and a crossing of requested duration with text length from 32 to 205 words. AuK-Flash's training sampler discards clips longer than 30 s, so the long requests tested here are out of distribution by construction. On an RTX 4090 D (23.52 GiB) it returns 0.665 of the requested words in order at 40 s and 0.107 at 60 s over ten seeds (0.008–0.218)—0.650 for the same 40 s cell over forty seeds—while reserving 12.8 GiB, 10.7 GiB below capacity. ZipVoice reserves up to 12.85 GiB and returns every requested word on every seed, so memory pressure is neither necessary nor sufficient. Beyond the window, duration rather than text length tracks the loss. At 60 s no text length from 32 to 205 words helps, the best cell returning 0.144. Requesting the same 60 s as three sentence-boundary calls returns 0.982, so what fails is the filling of a single long request rather than the text or the weights. ZipVoice keeps the words by spending 26% of the 60 s output in pauses of at least 0.5 s (31% counting all silence), about 14 of them, the longest gap up to 2.5 s. A single “intelligible at 60 s” score cannot separate the two systems: one loses words, the other loses speech. Long-form evaluation needs two measures—the share of requested words returned in order, and the share of the requested duration that contains speech—because either can be raised by lowering the other.