文件命名规范
文件名是唯一跟到底的元数据，字段顺序决定它能不能排序。
命名交付版本工程整理
相关
交付之后只剩文件名
工程里的轨道名、总线名、备注，到对方手里多半看不见；能跟着文件走完整个流程的，只有文件名。命名规范的目的不是整齐，而是让陌生人在不打开工程的情况下，知道这是哪首、哪段、哪一版、哪一组。
字段顺序就是排序规则
| 顺序 | 字段 | 写法 | 例子 |
|---|---|---|---|
| 1 | 项目或曲目代码 | 短、唯一、无空格 | PRJ07 |
| 2 | 内容 | 段落或乐器组 | CH02_DRUMS |
| 3 | 版本 | v01 起，两位补零 | v03 |
| 4 | 日期 | YYYYMMDD | 20261031 |
| 5 | 状态 | MIX、STM、MST、REF | MIX |
| 6 | 处理标记 | 可选，采样率与位深 | 48k24b |
把版本放在日期前面，同一段落的所有版本会排在一起；把日期放前面，则按时间排。两种都能用，关键是整批一致。空格、中文、括号与井号在跨系统传输时会被替换或截断，用下划线或连字符，ASCII 字母数字最稳。
版本号与状态分开写
v01、v02 是修改次数，MIX、STM、MST 是文件性质，两者不能互相代替。final 不是版本号，三个月后会出现 final2 与 final_final；用 v 加数字，旧版保留，交给对方的压缩包里只放当前版和一份变更说明。客户回稿用 REF 标记，避免与正式混音混在一起。
交接前的检查
- 同一批文件的字段顺序、分隔符、大小写一致
- 版本号连续，没有跳号或重号
- 日期是导出日，不是工程创建日
- 采样率、位深、声道数写在名字里或随附清单里
- 压缩包内没有系统缓存文件、缩略图与旧版混入
- 名字长度在对方系统限制内，路径不要太深
命名救不了的事
命名不能补上缺失的元数据，也不能替代交付清单；ISRC、版权归属、联系人仍要单独给。对方若有固定模板，先按对方模板，再谈统一。最危险的是看起来一样的文件：同名不同内容，或同内容不同名，都会让后期在错误版本上做决定。
在库中听例子
Radetzky-Marsch Op.228《拉德茨基进行曲》声部多，导出后最容易出现同名不同版本（C1）详情Symphony7 1交响曲乐章多，按乐章与声部编号才不会错配（C1）详情little%20town%20 %20orchestral%20midi分层配乐音色多，按功能命名比按音源命名更容易找（C1）详情La Primavera《春》的合奏编制整齐，适合练同一套字段贯穿分轨（C1）详情
每首均来自 midicn-lib，行内徽标为许可档位（C1 可商用 / C2 非商业 / C3 仅学习研究）。
同一条线
事实来源
- Avid Pro Tools Reference Guide，片段、文件与导出命名规则（产品文档）
- DDEX ERN 标准，电子发行元数据字段与版本（标准）
- EBU Tech 3293 EBUCore，音视频元数据与标识（标准）