28
36
MuScriptor 本地跑推理
2026-10-23 19:36:24
0点赞
0收藏
0评论
本地跑 MuScriptor 报错或导出空 MIDI，通常不是「模型不行」，而是两件事没对齐：权重文件是不是仓库说明里那一个、音频参数是不是模型期望的采样率与声道。这两件事都不用猜，靠目录列表、启动日志、一条十秒音频的最小推理就能判断出问题卡在哪一段。先别急着喂长曲子，把链路跑通比跑长更重要。
处理 MuScriptor 本地推理失败，建议按「权重核对 → 十秒音频最小推理 → 音频参数检查 → 显存与耗时观察 → 固化成脚本」的顺序排查。判断依据只看可验证的东西：权重路径与文件大小、启动日志里打印的加载信息、推理进程的退出码与输出文件是否非空。边界是：本文不给具体版本号、下载地址和性能数值，因为这些必须结合你本地的仓库说明和硬件确认；若仓库说明与你的环境冲突，以仓库说明为准。
核对仓库给出的依赖与权重获取方式
先保证「装的是对的东西」。MuScriptor 这类音频转乐谱的项目，依赖通常分几类：Python 解释器版本、深度学习推理框架、音频解码库（常见是 ffmpeg 以及 Python 侧的读取库）、以及可选的加速或导出相关库。具体包名和版本区间以仓库的依赖清单文件与 README 为准，不要凭印象凑环境，也不要随手装最新版去覆盖。
依赖来源：优先按仓库列出的清单文件安装，先建独立虚拟环境再装，避免与系统里已有的框架版本打架。
权重获取方式：看仓库说明里写的是「手动下载放到某个目录」还是「首次运行时自动拉取」。两者排查方式不同：手动放置的，路径写错就是加载失败；自动拉取的，网络不通会停在下载环节。
权重放置路径：仓库一般会约定一个默认目录，或通过启动参数、环境变量指定。确认时用
ls -l看文件是否真实存在且大小不为 0，如果发布方给了校验摘要，可以自己算一次比对。
# 只做存在性与大小核对，不写死任何路径
ls -l /path/to/weights/
du -sh /path/to/weights/
# 若发布方提供了摘要，再自行比对
sha256sum /path/to/weights/*.bin
启动时留意日志里是否打印了权重加载路径和加载成功的提示。如果日志停在这一步或提示键名不匹配、文件缺失，问题在权重侧，先把这里解决，后面的推理不用试。
用一段十秒音频跑最小推理，确认链路通
用最短路径验证三件事：模型能加载、推理能跑完、结果能导出。准备一段十秒左右、内容简单的音频（人声清唱或单一乐器），放在工作目录下，用下面的骨架调用，占位符全部替换成你本地仓库实际给出的入口与参数名。
MuScriptor 本地跑推理 / 先核对权重文件和音频采样率python -m muscriptor.infer
`--audio` ./samples/test10s.wav
`--ckpt` /path/to/weights
`--out` ./out/test10s.mid
`--device` cuda
2>&1 | tee ./logs/min_run.log
每一步的预期输出和失败位置不同，对照着看：
加载阶段：日志出现权重路径、参数量或「loaded」类提示。失败通常报文件不存在、state_dict 键不匹配、框架版本不兼容，问题在权重或依赖。
推理阶段：日志开始跑帧或分段处理。失败常见于采样率断言、张量形状不符、显存不足，问题在输入参数或硬件。
导出阶段：输出目录出现 .mid 文件。失败多是目录不存在、无写权限或编码器缺失。
命令末尾把日志落到文件里，后面固化脚本时这份日志就是对照基准。判断成功不看终端滚动多热闹，看退出码是否为 0、输出文件是否存在且大小不为 0。
检查音频采样率与声道数，不一致先转码
输出为空或明显异常时，先排除输入侧。多数音频模型对采样率和声道有隐含期望，用错不会一定报错，可能只是安静地给出空结果。先查参数，再决定转不转。
MuScriptor 本地跑推理 / 先核对权重文件和音频采样率# 查看采样率、声道数、时长
ffprobe -v error -show_entries stream=sample_rate,channels,duration
-of default=noprint_wrappers=1 ./samples/test10s.wav
如果与仓库说明中的期望值不一致，先转码再复检，不要直接丢给推理：
# 示例：统一为单声道、指定采样率
ffmpeg -i ./samples/test10s.wav -ac 1 -ar 44100 ./samples/test10s_44k_mono.wav
# 转码后复检，确认两项都改过来了
ffprobe -v error -show_entries stream=sample_rate,channels
-of default=noprint_wrappers=1 ./samples/test10s_44k_mono.wav
转码后拿同一段音频重跑上面的最小推理命令。如果原来空输出、转码后能出音符，问题就锁定在输入参数上，接下来再处理长音频时就有了正确的前处理方式。
观察显存占用与单次推理耗时
链路通了再谈能跑多长。做法是：一边用显存查看命令盯着占用，一边按音频时长逐档加长（比如十秒、三十秒、一分钟），每档记录一次单次推理耗时和峰值显存，形成你自己机器上的经验边界。
MuScriptor 本地跑推理 / 先核对权重文件和音频采样率# 单独开一个终端持续观察
nvidia-smi -l 1
# 或在推理时记录单次耗时
/usr/bin/time -v python -m muscriptor.infer `--audio` ./samples/long.wav ...
记录方式建议简单点：音频时长、显存峰值、单次耗时三列，写在一个文本表里。这里不提供任何具体数值结论，因为不同显卡、不同音频密度差异很大；你只需观察趋势——显存在哪一档接近上限、耗时是否随时长近似线性增长。超过上限的那一档，就是你当前环境下该切段处理的位置。
把成功运行的命令与日志要点固化成脚本
跑通一次之后，把命令收敛成一个脚本文件，把会变的东西全部提到脚本开头做变量，避免下次又靠回忆改参数。
#!/usr/bin/env bash
set -euo pipefail
AUDIO="${AUDIO:-./samples/test10s_44k_mono.wav}"
CKPT="${CKPT:-/path/to/weights}"
OUT="${OUT:-./out/test10s.mid}"
DEVICE="${DEVICE:-cuda}"
LOG="${LOG:-./logs/run_$(date +%Y%m%d_%H%M%S).log}"
mkdir -p "$(dirname "$OUT")" "$(dirname "$LOG")"
python -m muscriptor.infer
`--audio` "$AUDIO" `--ckpt` "$CKPT" `--out` "$OUT" `--device` "$DEVICE"
2>&1 | tee "$LOG"
# 成功检查点：输出存在且非空
[ -s "$OUT" ] || { echo "输出为空，回看 $LOG"; exit 1; }
echo "OK: $OUT"
必须外置的参数：音频路径、权重路径、输出路径、设备、日志路径；采样率如果是前处理固定项，也一并写成变量并注释说明。
日志里必须保留的关键行：权重加载路径与加载结果、推理开始与结束标记、导出的输出路径、任何断言或异常信息。
判定成功的检查点：脚本退出码为 0、输出文件大小大于 0、文件能被 MIDI 解析器读出至少一个音符事件。前两条脚本里已能自动判断，第三条建议手工打开一次确认，别只看文件存在。
到这里，报错到底出在权重还是音频，你已经有明确的判断路径，而不是反复重装环境。
