音频喂进 Ming-3.0，结果不对或者直接报错，最常见的误判是先去怀疑模型、权重或显存。更省时间的顺序是先证明输入文件到底是什么样：采样率、声道数、时长这三项都能用命令读出来，不需要靠猜。把这三项固定成一条可复查的记录，再决定要不要动模型侧。

建议把输入格式核对和模型排查拆成两步：先用探测命令记录采样率、声道数、时长；再统一采样率、转单声道、切掉超长片段；最后用处理前后两段音频各跑一次并对比输出。处理后结果恢复正常，问题基本落在输入链路；两段都异常，才去看模型、权重和解码配置。边界是：这套流程只排得掉可测量的格式因素，录音本身的噪声、内容和静音段问题不在其中。

先用探测命令读出音频的采样率、声道数和时长

这一步只做一件事：把输入侧的事实写下来。建议在准备喂给 Ming-3.0 的那个原始文件上执行，不要在转码后的副本上执行，否则记录的不是真正进来的东西。

ffmpeg 自带的 ffprobe 够用，字段也够细：

ffprobe -v error -select_streams a:0 -show_entries stream=codec_name,sample_rate,channels,channel_layout,bits_per_sample,duration -show_entries format=format_name,duration -of default=noprint_wrappers=1 input.wav

关键字段的含义：sample_rate 是每秒采样点数（常见 8000、16000、44100、48000）；channels 是声道数，1 为单声道、2 为立体声；channel_layout 说明声道排布，mono、stereo 这类值比 channels 更直白；duration 是时长，流级和容器级可能不一致，以 stream 的 duration 为准更稳妥；codec_name 与 bits_per_sample 用来确认是不是无损 PCM，压缩格式在解码时可能引入额外差异。

不想装 ffmpeg 的环境可以用 sox 自带工具，输出更短：

soxi input.wav

把结果整理成一条输入的三项参数记录，后面每一步都拿它做基线：

表格先空着，填的是你自己环境里读出来的值。这条记录的作用是：之后任何一次输出异常，都能回头对一遍输入有没有被悄悄换掉。

把采样率统一到目标值并重采样一次

采样率不匹配通常不会给出明确报错，而是表现为输出内容错乱、听起来像加速或减速、或者模型侧直接给出无意义结果。所以建议在送进模型前统一重采样一次，而不是指望模型自己处理。

目标值不要凭习惯定。先看 Ming-3.0 部署侧的音频配置项或示例代码里写的采样率，通常是 16000 或 8000，具体需要结合你使用的权重和推理配置确认。确认之后再执行：

mkdir -p resampled
ffmpeg -hide_banner -y -i input.wav -vn -ar 16000 -c:a pcm_s16le resampled/input_16k.wav

-vn 丢弃视频流，-ar 16000 指定目标采样率，-c:a pcm_s16le 输出未压缩 PCM，避免二次解码差异。如果你要保留原始位深，把 pcm_s16le 换成对应编码即可，但前后两次记录要保持一致。

处理完立刻再探测一次，和处理前并排对比：

ffprobe -v error -select_streams a:0 -show_entries stream=sample_rate,channels,duration -of default=noprint_wrappers=1 resampled/input_16k.wav

采样率一栏必须和目标值一致，时长一栏应该和原来接近（重采样一般不改时长，仅末尾可能有毫秒级取整差异）。如果时长明显变了，说明命令里混进了别的处理，需要拆开重跑。

统一声道数并切掉超长片段

多声道输入的常见表现是模型只读到了其中一路，或者读到了交错数据，输出内容出现截断、重复、空白。建议统一转成单声道，先排除这一层干扰：

mkdir -p mono
ffmpeg -hide_banner -y -i resampled/input_16k.wav -vn -ac 1 -c:a pcm_s16le mono/input_16k_mono.wav

超长片段同理。一次性喂几分钟的音频，容易撞上长度上限或内存边界，报错信息未必指向长度，反而看起来像模型加载失败。建议按固定时长切分，先切 30 秒这类保守值，再根据环境确认是否放宽：

mkdir -p seg
ffmpeg -hide_banner -y -i mono/input_16k_mono.wav -f segment -segment_time 30 -reset_timestamps 1 -c copy seg/input_16k_mono_%03d.wav

-c copy 在这里是安全的，因为前面已经统一成 PCM；-reset_timestamps 1 让每段从零开始计时，方便和模型输出的时间戳对齐。

命名规则建议带全三项信息，避免以后分不清哪个文件是哪一步产物：原始文件名 + 采样率 + 声道 + 三位序号，例如 input_16k_mono_000.wav、input_16k_mono_001.wav。切分后对每个片段再探一次时长，确认没有出现零字节或极短的空片段，这类片段本身就是一种输入异常。

用处理前后的两段音频各跑一次并对比输出

到这里输入侧已经收拢成两份可比对的素材：原始文件，和单声道、已重采样、已切分的干净片段。接下来各跑一次，其他条件（模型、权重、解码参数、并发）保持不变。

调用方式按你的环境替换，命令行或 HTTP 请求都行，下面是通用骨架：

# 第一次：原始文件
python run_ming3.py `--audio` input.wav `--out` out_raw.json

# 第二次：处理后的第一段
python run_ming3.py `--audio` seg/input_16k_mono_000.wav `--out` out_clean.json

用请求方式调用时同理，只换 audio 字段指向的路径，其余参数原样复制。两次运行之间建议清一下进程状态，避免上一轮的缓存或显存残留影响判断。

把两次结果填进同一张表：

判定输入侧是不是原因，可以按这三条走：处理后片段正常、原始文件异常，问题在输入侧，优先回到采样率、声道、长度三项逐项核对；两次都异常且报错文本相同，说明与输入格式无关，转去查模型权重、推理配置和显存；两次都正常但内容质量都不理想，则属于音频内容层面的问题，格式处理帮不上忙。

需要提醒的是，这套对比只能证明“格式因素是否参与”，不能证明“模型一定没问题”。如果处理后片段只是不再报错、输出仍然明显偏离预期，建议保留两次的输入文件和输出记录，用同一段已知正常的参考音频再跑一次，把输入侧的变量彻底压到最小，再判断是不是模型侧的问题。