[MiniMax Music 3] Output sounds corrupted ("horror movie" timbre) on RTX 5090 / sm_120

Summary

Running the diffusers ModularPipeline for MiniMaxAI/MiniMax-Music3 on an RTX 5090 (sm_120) produces audio with a corrupted / distorted / "horror movie" timbre, even when using the exact code snippet from the model's official README. RMS dynamics look correct on paper but the audio is unlistenable on every duration I tried (11s through 150s). The official reference audio (hosted on the HF repo at assets/minimax_ttm.wav) sounds correct.

Reproduction

Using the verbatim snippet from MiniMaxAI/MiniMax-Music3's README on a clean Python install:

import soundfile as sf
import torch
from diffusers import ModularPipeline

pipe = ModularPipeline.from_pretrained("MiniMaxAI/MiniMax-Music3")
pipe.load_components(dtype=torch.bfloat16)
pipe.to("cuda")

lyrics = """[verse]
Morning light filtering through the pine
Every quiet street is yours and mine
[chorus]
Softly the world begins to breathe"""

prompt = (
    "Genre: acoustic pop. BPM: 96. Key: C major. Warm and intimate, building gently into the chorus. "
    "Vocals: soft female lead, close and breathy, light stacked harmonies in the chorus. "
    "Arrangement: fingerpicked guitar and soft piano; brushed drums and upright bass enter in the chorus."
)

audio = pipe(
    prompt=prompt,
    lyrics=lyrics,
    audio_duration=60.0,
    generator=torch.Generator("cuda").manual_seed(7),
    output="audios",
)[0]

sf.write("song.wav", audio.T.float().cpu().numpy(), pipe.sampling_rate)

Result on RTX 5090 (sm_120, this issue)

• audio_duration=60.0 request produces 11.28 seconds of audio (the LM hits EOS after only ~28 LM frames)
• The output WAV plays back with severely distorted, "creepy" timbre throughout
• pipe.sampling_rate is 44100 — but the reference audio on the repo is at 32000 Hz (mismatch with docs, which explicitly say "32 kHz, 16-bit stereo WAV audio")
• A tokenizer warning is printed at load:

  "The tokenizer you are loading from '...' with an incorrect regex pattern: ... You should set the fix_mistral_regex=True flag when loading this tokenizer to fix this issue. This will lead to incorrect tokenization."

Reference (from the same checkpoint, official reference audio)

• MiniMaxAI/MiniMax-Music3/assets/minimax_ttm.wav — 32 kHz, 284.85s, sounds clean
• The same reference audio is what SGLang-Omni's /v1/audio/speech endpoint returns

Environment

Verified model weight counts after load:

• language_model: 8.58B params (Qwen3-8B)
• transformer: 2.43B params (Flow Matching)
• vocoder: 0.05B params (Flow-VAE decoder)
• rvq_depth_decoder: 0.65B params
• condition_encoder: 0.03B params
• tokenizer: vocab 151643 (Qwen2TokenizerFast)

All match the architecture description in the model card.

What I tried

The energy profile (RMS over time) on every output looks like a valid song — quiet intro, building verses, loud chorus hits, etc. — but the audio itself sounds like a corrupted/garbled version of what the LM is trying to generate.

Why I suspect the diffusers modular pipeline specifically

Community integrations (Anil-matcha/minimax-music-3-comfyui, the official MiniMax-AI/MiniMax-Music3 repo's example script) don't run the local diffusers ModularPipeline — they hit the MuAPI hosted endpoint, or the SGLang-Omni local server. The only related diffusers-side issue I can find is #14486, which is a performance study that doesn't mention audio quality problems but does flag several places where the merged pipeline interacts with torch.compile / StaticCache / batched CFG in ways that surprised the author.

The model card explicitly lists SGLang-Omni as the recommended inference framework, with diffusers listed alongside. I'm wondering whether the diffusers path has correctness gaps in a Blackwell / Windows / transformers 4.57.6 environment that don't show up on Linux + a different transformers version.

Notes on the tokenizer warning

At pipeline load, every run prints:

The tokenizer you are loading from '...' with an incorrect regex pattern:
https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503/discussions/84#69121093e8b480e709447d5e
This will lead to incorrect tokenization.
You should set the `fix_mistral_regex=True` flag when loading this tokenizer to fix this issue.

The flag isn't directly exposed through ModularPipeline.from_pretrained (the tokenizer is loaded internally by a component spec), so I can't easily opt in to verify whether it fixes the output. The warning is shown for Qwen2TokenizerFast, which makes me wonder if this regex pattern is being applied to the wrong tokenizer class.

Sample-rate mismatch

• vocoder/config.json declares "sampling_rate": 44100
• pipe.sampling_rate returns 44100
• Output WAVs are saved at 44100 Hz, 16-bit, stereo
• The model card documentation and SGLang-Omni both say output should be 32 kHz, 16-bit stereo WAV
• The official reference audio is 32000 Hz

If the model is producing 32 kHz audio internally but the pipeline is faking the header to 44100, every saved WAV would play back at the wrong speed/pitch and sound like a horror soundtrack. I tried resampling my 44100 outputs back to 32000 with scipy.signal.resample but that can't recover the original sample data if the header was just relabeled.

Suggested investigation areas

1. Sample rate: is vocoder.config.sampling_rate = 44100 correct, or should it be 32000? If the model was trained at 32 kHz and the diffusers config is wrong, all output is at the wrong rate.
2. Tokenizer regex: the warning fires unconditionally — does the loaded tokenizer.json actually have the wrong regex, and is the resulting tokenization silently corrupting the LM conditioning?
3. LM early stop: with audio_duration=60 the LM emits the _AUDIO_END_TOKEN_ID = 151670 after only ~28 LM frames (decoded to ~11s of audio). Does the vocab_mask[_AUDIO_END_TOKEN_ID] = False at line 325 of encoders.py apply correctly, or is the model ending the song prematurely because of a tokenization bug in the prompt?
4. The eos_token_id = None on language_model/config.json (vocab_size=200000) — does this interact badly with transformers generation utilities anywhere in the pipeline?

Logs / artifacts

I have a 60s WAV (bug_repro_60s.wav) generated by the verbatim README snippet, plus several other durations and prompts, all showing the same corruption pattern. Happy to share any of them.