[JarodMica]

Drama 3 sometimes repeats words or phrases at the end of a sentence. Testing suggests that splitting sentences across short text chunks contributes to this behavior. Selected cases triggered repetition screens when split and cleared them when generated whole.

This PR raises the default text_chunk_size from 128 to 4000 across the runtime, model specification, UI defaults and documentation. The chunking algorithm remains unchanged, though codex said changes to it might help drama 3, I didn't want to validate a change to it as it seems like it might be used by other engines here.

Evidence

The original 5,000-request V2 evaluation flagged 29 potential speech-repetition cases, all on multi-chunk inputs.

A follow-up tested 30 previously flagged cases six times each using the same GGUF and original runtime:

Chunk budget	Repetition flags
128	68/180
4000	0/180

That comparison also raised the frame cap from 1024 to 2048.

A separate four-take check kept the cap at 1024 and changed only text_chunk_size within each pair:

Case	Split input	Whole text, budget 4000
Spanish flores-0451-es	Budget 200; repetition flagged	No repetition flag
French flores-0170-fr	Budget 128; repetition flagged	No repetition flag

All four takes finished before the cap. These results use Nemotron 3.5 ASR repetition screens. Three transcripts were reused after byte-for-byte WAV matches; one clip received fresh transcription.

The four-take check used runtime 3bbbd1d2, V2 Q4_K experts, FP32 routers, BF16 embedding/head, all-GPU CUDA placement, eight threads, context 8192, temperature 1.0, top_p=0.9 and top_k=4097.

Limits and verification

The tested sentences fit in one chunk at 4000. Actual 4,000-character passages have not been validated, and the whole-text GGUF retest covered only the selected 30 cases. Automatic repetition flags are review screens, not confirmed failures or a general failure rate.

The 1024-frame cap permits about 48 seconds of audio per chunk. The default runtime context is 2048 rows, shared by text, reference audio, history and generation. Longer passages could exhaust either limit.

Validation for this patch: the production WebUI build passed, the runtime/spec/UI defaults agree, and git diff --check passed. The checked-in bundle changes only the two Drama 3 defaults. The native binary was not rebuilt for this draft; the runtime evidence above comes from the recorded comparison builds.

Related history

• #916: initial native port.
• #977: tag-aware closing-quote fix.
• #978: sampling changes and the 128-character default. Maintainer request.
• #1188: parity, chunk budgets and token caps.
• #1197: history anchors and context fitting.
• #1200: opt-in handling for EOS before any audio frame.
• #1217: V2 documentation and original comparison.
• Discussion #891: V2 evaluation results.
• #920: earlier long-form measurements.

[0xShug0]

@JarodMica I accidentally merged the PR (it's been a long day) and have just reverted it. Changing the default significantly increases VRAM usage, and the larger chunk size also requires adjusting the context length to avoid hitting its limit. Existing pipelines that worked with the defaults could suddenly fail with OOM errors after updating.

I think the right approach is to keep the current default and document increasing text_chunk_size as a workaround for repetition, with guidance on VRAM usage and context length.

I'll run more tests tomorrow.

[JarodMica]

@JarodMica I accidentally merged the PR (it's been a long day) and have just reverted it. Changing the default significantly increases VRAM usage, and the larger chunk size also requires adjusting the context length to avoid hitting its limit. Existing pipelines that worked with the defaults could suddenly fail with OOM errors after updating.

I think the right approach is to keep the current default and document increasing text_chunk_size as a workaround for repetition, with guidance on VRAM usage and context length.

I'll run more tests tomorrow.

No problem! That sounds like a good approach here. I can draft a PR for that. I didn't expect the PR to merge here without some testing, probably shouldve left it on draft before opening, mb!