Basic Information - Models Used
speech-02-hd (or speech-01 if older) voice_id: Chinese (Mandarin)_Unrestrained_Young_Man
Basic Information - Scenario Description
TTS voice messages for AI roleplay (WeChat channel). All generated audio now ends with an unwanted electronic "beep" tone starting ~2026-08-13 01:10 UTC+8. Affects all voices. Regression.
Is this bug known and solvable?
Information about environment
- Caller: AI agent on OpenClaw platform (not direct CLI/API)
- Channel integration: openclaw-weixin
- Region: CN (assumed api.minimaxi.com)
- Specific MCP server version: Unknown (managed by platform)
- Specific TTS model: Unknown (not returned in API response)
- Python/OS: not directly accessible (managed by OpenClaw)
- Reproducible: 100% (every call since 2026-08-13 ~01:10 UTC+8)
Trace-ID in the request head
Unable to provide
Description
Bug summary: TTS audio generated by synthesize_speech has an unwanted "beep" tone appended at the end, on all voices, since 2026-08-13 ~01:10 UTC+8. This is a regression — audio generated before that time does not have this issue.
Expected behavior: Audio ends cleanly with the spoken text. No additional tones should be appended.
Actual behavior: A short electronic "beep" / "滴滴滴" tone plays at the end of the audio, after the spoken text finishes. The tone is audible to human ears but not always detectable by automated audio analysis (likely short duration, low energy, or in a frequency band that audio classifiers ignore).
Reproduction:
1.
Call synthesize_speech with any voice_id and any text input
2.
Play the generated mp3 file
3.
Listen to the last 0.5-1 second of the audio
4.
Observe: a short "beep" tone is appended after the spoken text ends
Voices tested (all have the same issue):
Chinese (Mandarin)_Unrestrained_Young_Man
Chinese (Mandarin)_Gentleman
male-qn-badao-jingpin
Parameters tested (no effect on the issue):
pitch: 0, -1, -4
speed: 0.82, 0.85, 0.86, 0.9
Various text inputs (short and long)
First observed: 2026-08-13 ~01:10 UTC+8 Audio generated before this time: clean, no end tone
Caller environment:
AI agent on OpenClaw platform
Channel integration: openclaw-weixin
Region: CN (api.minimaxi.com)
Specific MCP server version: Unknown (managed by platform)
Specific TTS model: Unknown (not returned in API response)
trace_id: Not available (AI agent caller does not surface trace-ids in the response)
Suggested fix: Option A: Remove the end-of-audio tone by default. Option B: Add an opt-out parameter, e.g. disable_end_tone: true.
Impact: Makes TTS unusable for voice message applications where the audio needs to end cleanly. Affects all users relying on MiniMax TTS for natural-sounding voice output.
Basic Information - Models Used
speech-02-hd (or speech-01 if older) voice_id: Chinese (Mandarin)_Unrestrained_Young_Man
Basic Information - Scenario Description
TTS voice messages for AI roleplay (WeChat channel). All generated audio now ends with an unwanted electronic "beep" tone starting ~2026-08-13 01:10 UTC+8. Affects all voices. Regression.
Is this bug known and solvable?
Minimax-MCPandMinimax-MCP-JS.Information about environment
Trace-ID in the request head
Unable to provide
Description
Bug summary: TTS audio generated by synthesize_speech has an unwanted "beep" tone appended at the end, on all voices, since 2026-08-13 ~01:10 UTC+8. This is a regression — audio generated before that time does not have this issue.
Expected behavior: Audio ends cleanly with the spoken text. No additional tones should be appended.
Actual behavior: A short electronic "beep" / "滴滴滴" tone plays at the end of the audio, after the spoken text finishes. The tone is audible to human ears but not always detectable by automated audio analysis (likely short duration, low energy, or in a frequency band that audio classifiers ignore).
Reproduction:
1.
Call synthesize_speech with any voice_id and any text input
2.
Play the generated mp3 file
3.
Listen to the last 0.5-1 second of the audio
4.
Observe: a short "beep" tone is appended after the spoken text ends
Voices tested (all have the same issue):
Chinese (Mandarin)_Unrestrained_Young_Man
Chinese (Mandarin)_Gentleman
male-qn-badao-jingpin
Parameters tested (no effect on the issue):
pitch: 0, -1, -4
speed: 0.82, 0.85, 0.86, 0.9
Various text inputs (short and long)
First observed: 2026-08-13 ~01:10 UTC+8 Audio generated before this time: clean, no end tone
Caller environment:
AI agent on OpenClaw platform
Channel integration: openclaw-weixin
Region: CN (api.minimaxi.com)
Specific MCP server version: Unknown (managed by platform)
Specific TTS model: Unknown (not returned in API response)
trace_id: Not available (AI agent caller does not surface trace-ids in the response)
Suggested fix: Option A: Remove the end-of-audio tone by default. Option B: Add an opt-out parameter, e.g. disable_end_tone: true.
Impact: Makes TTS unusable for voice message applications where the audio needs to end cleanly. Affects all users relying on MiniMax TTS for natural-sounding voice output.