Hallucination on very short standalone utterances (single-word Polish sentences: "tak"/"nie"/"ja")

Environment

• OS: Windows 10 Home (10.0.19045)
• Python: 3.12.13
• torch: 2.11.0+cu128
• CUDA: 12.8 (cuDNN 91900)
• GPU: NVIDIA GeForce RTX 2060 (6 GB VRAM)
• voxcpm: 2.0.2 (VoxCPM2 model)
• transformers: 5.5.3
• librosa: 0.10.2.post1
• soundfile: 0.12.1

Generation params used: cfg_value=2.30, inference_timesteps=12, min_len=3 (defaults are cfg_value=2.0, inference_timesteps=10, min_len=2 — we tuned these slightly higher, problem reproduces at both default and tuned values).

Summary

When synthesizing very short, standalone Polish sentences — typically a single word plus punctuation, e.g. "Tak.", "Nie.", "Ja.", "Pa." — the model frequently hallucinates extra trailing words/syllables that are not present in the input text. This is consistent and reproducible across many different reference/prompt audios, not tied to one specific voice.

Minimal reproduction

from voxcpm import VoxCPM

model = VoxCPM.from_pretrained("openbmb/VoxCPM-1B") # or local VoxCPM2 checkpoint

wav = model.generate(
text="Tak.",
prompt_wav_path="reference.wav",
prompt_text="",
cfg_value=2.30,
inference_timesteps=12,
min_len=3,
)

Repeating this call (same text, same reference) across many samples shows a high rate of duplicated/invented content in the output audio.

Observed behavior

Real examples from Whisper transcription of the generated audio for input "Tak." (reference voice unchanged between runs):

• "Tak. Danczna"
• "Tak. Biaq"
• "Tak. Tak"

i.e. the model appends an extra (sometimes nonsensical/garbled) word after the correct one-word utterance, instead of stopping.

Expected behavior

Output audio for a single-word input sentence should contain only that word, without appended/duplicated content.

What we've tried (workarounds on our side, not fixes to VoxCPM itself)

We built an A/B test harness that generates the same short word with different punctuation/marker wrappings around it, transcribes each sample with faster-whisper, and measures the duplication rate. Ranking of duplication rate (lower = better), consistent across repeated words tested (tak, nie):

• prefix dash only, e.g. "- tak." → ~7% (best)
• raw / no marker, e.g. "tak." → ~9%
• prefix + trailing dash, e.g. "- tak -." → ~20%
• trailing dash only, e.g. "tak -." → ~23%
• prefix dash + quotes, e.g. '- "tak".' → ~30%
• quotes only, e.g. '"tak".' → ~33% (worst)

Interesting/counterintuitive finding: a trailing dash (' -' at the end) appears to be interpreted by the model as a "continuation" cue, which increases hallucination for isolated one-word lines specifically — even though the same trailing-dash marker works fine for words embedded in longer sentences. We currently mitigate by wrapping isolated short words in quotes ("tak".) for the first attempt, and only add the dash inside the quotes ("- tak".) as an escalation on retry after ASR verification fails — this is subjective-ear-tested to reduce (not eliminate) the artifact, though our own duplication-rate proxy actually ranks quotes worse than a bare prefix dash, so there seems to be a difference between "duplication rate" and "perceived naturalness" that we don't fully understand.

We also noticed retry_badcase / retry_badcase_ratio_threshold (audio-to-text length ratio) exists in VoxCPM._generate(), but for a single extra short/garbled word appended to a 1-word utterance, the length ratio may not cross the default threshold (6.0) even though the output is wrong — so this safeguard doesn't reliably catch this specific failure mode.

Questions for maintainers

1. Is this a known limitation of the model specifically for very short/isolated utterances (as opposed to short sentences that are part of a longer context)?
2. Is there a recommended min_len / cfg_value / inference_timesteps combination that reduces this for single-word inputs, without degrading longer sentences?
3. Would tightening retry_badcase_ratio_threshold for short inputs (e.g. scaling it by input length) be a reasonable mitigation, or is there a better internal signal (e.g. stop-token confidence) that could be exposed?
4. Is this behavior specific to Polish (lower-resource language for the model), or has it been observed for other languages on short isolated inputs too?

Start with the minimal VoxCPM.generate reproduction for "Tak." and inspect retry_badcase handling in VoxCPM._generate(). Compare default and tuned cfg_value, inference_timesteps, and min_len settings across the reported short Polish inputs and reference audios. Done means determining whether this is a known short-utterance limitation and identifying a justified mitigation or internal signal without degrading longer sentences.