MP3 ID3 修复与封面歌词验证
为什么要做元数据验证
很多转换器做音频转换时"只管音频帧,不管元数据"——转换后的文件里封面没了、歌词丢了、ID3 标签被 FFmpeg 写错了也不管。ZenConverter 不接受这种行为:
如果支持的元数据存在但无法被验证,任务失败并保留诊断信息。
换句话说:宁可让任务失败,也不给你一个封面丢失、歌词错乱的半成品。
三条路线的元数据处理
| 格式 | 验证路径 | 核心策略 |
|---|---|---|
| MP3 | MP3 容器 ID3 验证 + 封面验证 + USLT 歌词 | 修复优先,实在不行失败 |
| Opus | Ogg 容器元数据验证 + 封面验证 | 可能走 metadata-only remux 修复 |
| FLAC | FLAC 容器元数据验证 + 封面验证 | 可能走 metadata-only remux 修复 |
MP3 的 ID3 修复(重点)
MP3 输出的元数据验证是最激进的。ZenConverter 做以下检查:
- 第一张 JPEG/PNG 封面:源文件里的第一张封面图(APIC 标签)必须在输出容器里正确存在;
- 常见音乐字段:标题(TIT2)、艺术家(TPE1)、专辑(TALB)、专辑封面艺术家(TPE2)、年份(TYER / TDRC)、曲目号(TRCK)——常见字段尽量拷贝;
- 普通嵌入歌词:优先检查 USLT 帧(真正的歌词帧)。如果源文件的歌词只存在 .lrc 文件里(不嵌入),不会自动合并;
- MP3 歌词修复:如果源文件有歌词但不是真正的 ID3
USLT帧(比如某些播放器把歌词写在 TXX 私有标签里),ZenConverter 会把歌词修复成真正的 USLT 帧——不碰音频帧,只写容器层。
修复的两种方式
方式 1:正常 remux 修复
重新编码音频帧后,把从源文件验证出来的正确元数据(封面、ID3 字段、USLT 歌词)写进输出容器。这是正常输出路径。
方式 2:metadata-only remux(Opus/FLAC 专用)
对于 Opus 和 FLAC,如果第一次 mux 后元数据验证不通过,ZenConverter 会再走一次纯 metadata 的 -c:a copy remux:
- 音频帧不动(
-c:a copy,不重新编码); - 只重新写入容器元数据;
- 第二次 remux 的目标是"在音频帧不变的前提下,把元数据写对"。
这条路只在 Opus 和 FLAC 上有。MP3 不走这条,因为 MP3 的 ID3 修复就是走帧级的,不需要 remux。
验证失败 = 任务失败
如果两条修复路径都跑不通(比如源文件的元数据确实有问题、或者当前容器不支持某些字段),任务会直接失败,并在前台服务里给出诊断信息。
这不是 bug——这是 ZenConverter 的设计哲学:不支持或验证不过的就明确失败,不给半成品。
不保证的元数据场景
| 场景 | 处理方式 |
|---|---|
| 多个封面 | 只拷贝第一张,其他丢弃 |
| 私有标签(非标准 ID3) | 不保证保留 |
| 外部 .lrc 文件(不嵌入) | 不自动合并进音频文件 |
| 章节(chapters) | 裁剪/分割后的章节时间戳不再有效,直接丢弃 |
| WAV/WMA/M4A 的元数据 | best-effort 处理,不做同等深度的验证 |
对用户意味着什么
好消息是:你的音频转换任务如果成功,输出文件的封面和歌词基本不会丢。坏消息是:如果源文件的元数据确实有问题,任务可能失败(但会给诊断信息)。
对比大多数 Android 转换器"转换完封面没了但也不说"的体验,ZenConverter 的策略是对谨慎用户更友好的——你不会在几个月后某一天突然发现"哦,我那批转换的 MP3 封面全没了"。
相关页面
- 音频格式互转 —— 六种格式的编码管线
- 从视频里抽取音频轨 —— 视频嵌的音频也走元数据验证
- 本地优先就是隐私优先 —— 为什么要对转换结果的质量负责