[Alex-Wengg]

Closes #1031.

Why is this change needed?

#1032 fixed the issue's first finding, the splice guard. The second finding was a question: should tdtJa resolve melChunkContext to off? It should. Today's short-gap seam repair (#1061) also adds a tdtJa-specific problem.

I measured it on real read speech: 500 JSUT basic5000 clips (BASIC5000_4501–5000, 16 kHz), joined into 31 min with their transcripts as the reference. A second copy trims each clip's edge silence so more seams land in speech. CER is NFKC, without punctuation or spaces; "drops" are runs of 5 or more deleted reference characters.

tdtJa on main b20d209	joined: CER / drops	trimmed: CER / drops
default (mel context on), seam repair off	23.48% / 65	22.29% / 67
default (mel context on)	10.37% / 7	9.56% / 3
--no-mel-context	8.90% / 2	8.52% / 2
--no-mel-context --seam-gap-min 1.5	8.49% / 3	8.19% / 2
this PR, defaults	8.49% / 3	8.19% / 2

Before #1061, the no-mel path already scored 8.49% / 8.17%. #1061's 0.5 s gap floor added 19 insertions on the joined file, and every one is re-heard neighbour text ("モデルモデル", "ころはころは", "ノーベルノーベル"). Its short-gap rules (skip gaps inside a word, complete a cut word, drop re-heard bordering words) need word boundaries, and tdtJa's unspaced vocabulary has none: with the splice guard off, every piece counts as a word.

What changes?

• resolvedMelChunkContext(for:) resolves to false for .tdtJa. An explicit melChunkContext: still wins.
• ChunkProcessor.seamGapMinGapFrames: when there's no word guard (spliceSafeTokenIds == nil), the repair pass probes only gaps of 1.5 s or more. Vocabularies with a guard keep the configured floor.
• Docs and CLI help updated.

v3 output is byte-identical on three Earnings-22 calls (4469088, 4474506, 4483937): text and word timings. The tdtJa default is also faster here: 3.6 s against 6.9 s for the 31 min file. 190 chunk, seam and config tests pass, including the new ones.

🤖 Generated with Claude Code

[github-actions]

Sortformer High-Latency Benchmark Results

ES2004a Performance (30.4s latency config)

Metric	Value	Target	Status
DER	30.3%	<35%	✅
Miss Rate	28.2%	-	-
False Alarm	0.9%	-	-
Speaker Error	1.2%	-	-
RTFx	14.6x	>1.0x	✅
Speakers	4/4	-	-

_{Sortformer High-Latency • ES2004a • Runtime: 3m 46s • 2026-11-01T21:42:55.938Z}

[github-actions]

ASR Benchmark Results ✅

Status: All benchmarks passed

Parakeet v3 (multilingual)

Dataset	WER Avg	WER Med	RTFx	Status
test-clean	0.57%	0.00%	5.86x	✅
test-other	1.19%	0.00%	3.54x	✅

Parakeet v2 (English-optimized)

Dataset	WER Avg	WER Med	RTFx	Status
test-clean	0.80%	0.00%	6.11x	✅
test-other	1.00%	0.00%	3.76x	✅

Streaming (v3)

Metric	Value	Description
WER	0.00%	Word Error Rate in streaming mode
RTFx	0.64x	Streaming real-time factor
Avg Chunk Time	1.409s	Average time to process each chunk
Max Chunk Time	1.630s	Maximum chunk processing time
First Token	1.738s	Latency to first transcription token
Total Chunks	31	Number of chunks processed

Streaming (v2)

Metric	Value	Description
WER	0.00%	Word Error Rate in streaming mode
RTFx	0.67x	Streaming real-time factor
Avg Chunk Time	1.355s	Average time to process each chunk
Max Chunk Time	1.448s	Maximum chunk processing time
First Token	1.360s	Latency to first transcription token
Total Chunks	31	Number of chunks processed

_{Streaming tests use 5 files with 0.5s chunks to simulate real-time audio streaming}

_{25 files per dataset • Test runtime: 6m32s • 11/01/2026, 04:43 PM EST}

_{RTFx = Real-Time Factor (higher is better) • Calculated as: Total audio duration ÷ Total processing time
Processing time includes: Model inference on Apple Neural Engine, audio preprocessing, state resets between files, token-to-text conversion, and file I/O
Example: RTFx of 2.0x means 10 seconds of audio processed in 5 seconds (2x faster than real-time)}

Expected RTFx Performance on Physical M1 Hardware:

• M1 Mac: ~28x (clean), ~25x (other)
• CI shows ~0.5-3x due to virtualization limitations

_{Testing methodology follows HuggingFace Open ASR Leaderboard}