老番修复实战：从残片到高清收藏版的完整流程

老旧的硬盘翻出来时，那个文件就安安静静躺在“未整理”文件夹里，名字是 dragonballz_e232-2.mkv。如果你也收过老番，一定懂这种既视感：文件名像机器生成的编号，体积大得离谱，打开播放器之后发现是电视台录制版，右上角还烙着一个明显的台标。这是我当年为了补《龙珠Z》魔人布欧篇留下的半成品素材，e232 代表第 232 集，-2 代表这集被广告切出来的后半段。这篇文章要讲的，不是“怎么下载老番”，而是当你手里只有这种“残废片源”时，怎么通过一整套修复、对齐、封装流程，把它变成一份还能看的个人收藏版。整个过程涉及片源判断、逐帧处理、音轨对齐、字幕精校和最终编码，每一步都有可以直接抄作业的工具和参数。

适合谁看？如果你手里也压着一堆老动画的采集档，对画质不满又不知道从哪一步开始处理；或者你只是想搞懂“那些论坛里的重制版到底是怎么做出来的”，这篇都能给你一条完整的路线。我用第 232 集后半段作为实验对象，走了完整流程，后面所有经验都是实测结果，不是纸上谈兵。

1. 这个文件暴露了老番收藏的三个典型问题

dragonballz_e232-2.mkv 这个文件名看起来很规整，但恰恰是这种“规整”掩盖了三个麻烦。第一，它没有标注片源类型；第二，它被广告切成了两段，文件名末尾的 -2 说明它只是半集；第三，它里面混着多条不匹配的音频和字幕轨道，如果不检查就直接看，你会遇到前十分钟音画同步、后十分钟彻底对不上的情况。

很多老番收藏爱好者都栽在这上面。你以为自己存的是一个完整剧集，实际上它是一个需要“拆开重装”的原始素材。这里我建议所有人在处理老番前先做三件事，成本很低但能避免之后白干几小时：

• 用 mkvmerge --identify 或 MediaInfo 检查文件里到底有几条视频流、几条音轨、几条字幕轨。
• 用 ffprobe 看一下视频的真实分辨率、帧率、编码格式。
• 在播放器里跳着抽看三到五个时间点，确认是否有黑场、花屏、音画不同步。

我当时跑完发现情况比想象中“标准”：640×480 分辨率、25fps、MPEG-2 编码，这基本确定是电视采集源。音频是 MP2 格式，延迟偏了大约两秒，字幕轨一条中文、一条日文，但是时间轴完全错位。也就是说，画面要降噪去交错，音频要对齐，字幕要重新调轴，等于三线并行。

如果你也是半路出家，建议先别急着上滤镜，先把这些信息收集全。老番重制最忌讳“猛药乱下”——还不知道片源什么问题就堆一堆滤镜上去，最后出来的画面要么糊成一片，要么锐化得像塑料。

2. 片源版本摸底：为什么我决定拿第 232 集后半段开刀

2.1 龙珠Z常见的几种片源到底差在哪

做修复之前，你得先搞清楚手上是什么版本的片源。同样是《龙珠Z》，市面流传的片源大概分这几类，差异比很多人想象中大得多。

Dragon Box 是很多老粉公认的“正经底子”，色彩、颗粒感都接近原始胶片，但保存不完整且是 DVD 清晰度；30周年BD虽然清楚，但为了16:9裁掉了上下画面，很多龙珠粉丝不喜欢这种构图上被腰斩的感觉。电视台录制版最大的问题是台标和广告切分，但好处是它保留了当年电视播出的真实质感，噪点分布很自然，修复出来不会像某些 AI 修复版那样“假清晰”。

2.2 为什么偏偏是 e232-2 而不是 e232-1

e232 这一集被广告切成了两段，我手里的 e232-2 是后半段。我选择先拿后半段做实验，一半是客观原因，一半是主观判断。

客观原因是 e232-1 那个文件当年采集的时候出现了连续丢帧，而且损伤的位置正好在片头曲结束后的正片起点，如果想要完整修复，需要从别的版本里补帧，工作量会翻倍。主观原因是第 232 集后半段的作画信息量更密集，动作场景多，很适合用来测试降噪、去交错、补线这些技术是不是真的到位。简单说，修复老番不能用静态场景来验证效果，必须拿运动场景来压。

所以我当时的判断很直接：先用好修的一半跑通全流程，把参数和经验确定下来，再回头处理损坏的前半段。最后的实际结果也证明这个顺序是对的——如果你第一次就把最难啃的骨头放在前面，容易在一堆失败尝试里消耗掉耐心。

2.3 修复目标的设定：不是“越清晰越好”

在动手之前，你需要给自己定一个“到站”的标准。我的标准只有三条：

• 画面要干净，但必须保留赛璐璐时代的颗粒感，不能变成过度磨皮的塑料片。
• 台标必须去掉，但去台标区域不能出现明显的糊块。
• 音画必须同步，字幕时间轴不能让人出戏。

这三条听起来很朴素，实际上每条背后都有一堆细节。尤其是“保留颗粒感”这一点，很多新手修复老番都喜欢把噪点全部抹掉，结果角色脸部像玻璃一样光滑，动作场景的力度感全部丢了。《龙珠Z》这种当年的赛璐璐动画，颗粒感是画面质感的一部分，处理目标应该是“去掉脏噪点、保留颗粒”，而不是“全部清干净”。

3. 第232集修复实操：从拆帧到输出的完整链路

3.1 为什么是 VapourSynth，而不是直接在剪辑软件里弄

如果你打开 Premiere 或者剪映，第一反应可能是“我在这里面加个锐化滤镜不就行了”。但老番修复和短视频调色完全是两码事。你需要做的是逐帧级的图像处理，要控制到像素级别的动作，而剪辑软件能给你的处理空间远远不够。

我这里用的是 VapourSynth，一个基于 Python 的逐帧处理框架。选它的理由很实际：

• 可以用 Python 脚本精确控制每一个处理步骤，顺序透明，参数可保存可复现。
• 降噪、去交错、倍线这些滤镜都有现成的高质量实现，比如 QTGMC、BM3D、nnedi3。
• 脚本处理完之后，输出的是无损中间文件，后面再用 x265 压制成最终成品。

对比之下，剪映和 Premiere 更适合处理“临时观看用的视频”，而不是“值得长期保存的重制版本”。我见过有人在剪辑软件里逐帧抠台标，那种操作量大得惊人，而且效果远不如 VapourSynth 里用 mask 做区域处理来得稳定。

3.2 第一步：处理隔行扫描和台标

电视录制版最明显的画面问题是隔行扫描。25fps 的录制源里面，每一帧其实是由两个场交错组成的，运动场景中会看到明显的横向锯齿，也就是大家常说的“梳状纹”。处理这个的标准方案是 QTGMC，它不仅是去交错，还能顺便做一次高质量逐行化。

我用的脚本片段是这样开始的：

python复制import vapoursynth as vs
core = vs.core

# 加载源视频，假设已经用 ffvideosource 解封装成无损中间格式
src = core.ffvideosource.Source("e232-2_intermediate.mkv")

# 切成 RGB 或 YUV，依照最终输出需求走
src = core.resize.Bicubic(src, format=vs.YUV420P8)

# 去交错：QTGMC 的 Slow 档位，保留细节同时消除锯齿
src = core.qtgmc.QTGMC(src, Preset="Slow", TR=1)

QTGMC 的 Preset 参数越慢，效果越细致，但耗时成倍增加。对于 640×480 的素材，我用 Slow 档已经足够，没必要上 Placebo——那个档位一集下来要多跑好几个小时，而肉眼差距极其有限。

台标处理我是在去交错之后做的。老番台标一般固定在右上角或左上角，对于静态位置的台标，可以用 video 领域常见的 delogo 类滤镜，给它一个矩形区域，让它用周围像素“补”掉台标区域。但要注意，台标底下一旦有物体经过，简单的填充就会露馅。我当时的处理方案是先做一个 mask，只对纯台标区域做填充，对台标和画面重叠的区域走另一条神经网络的补全流程，避免出现明显的色块。

不要指望滤镜全自动，台标去除是最需要抽检的步骤。我处理第 232 集时，有好几处背景画面本身就带渐变，delogo 默认参数补出来的区域会有肉眼可见的条纹，必须手动调整 mask 和模糊参数。

3.3 第二步：降噪与倍线，避免两个方向翻车

降噪我用了 BM3D，这是一个在图像处理里口碑很好的算法，对“保留细节同时去掉压缩噪声”非常有效。参数上我把 sigma 控制在 1.2 左右，处理到噪点变柔但不消失为止。

关键在于，不要对整帧画面用同一个强度。动画的背景和人脸轮廓需要的降噪强度不一样。VapourSynth 里可以用一些局部保护机制，让人物轮廓线不变成“毛边”。这里有一个新手容易犯的错误：降噪参数一旦调大，人脸的线条会变淡，接下来再做锐化时，整个画面会出现明显的“描边感”。这就是为什么我会把降噪和锐化放在同一个思路里考虑，而不是先猛降噪、再猛锐化。

倍线这一步，我是用 nnedi3 把 640×480 拉升到 1280×960。nnedi3 是插值算法里对“线条边缘”相对友好的一个，比普通 bilinear 缩放要锐利，又比 AI 修复稳。很多朋友喜欢用各种 AI 放大工具，把画面直接拉到高清，但一旦遇到运动场景，AI 放大很容易出现线条抖动和“幽灵残影”。《龙珠Z》这种老动画，我不建议用激进的 AI 放大方案。

锐化我用的是 LimitedSharpenFaster，并且把强度调低。这个滤镜的特色是只强化“有细节”的区域，不会过度放大噪声。参数大概是这样：

python复制src = core.rgsf.LimitSharpFaster(src, strength=100, radius=2)

如果你用的滤镜版本不支持，也可以换用常见锐化后再用一个 mask 限制住。总之记住一句话：锐化是最后一步，不是提升清晰度的主手段。

3.4 输出中间文件与抽帧检查

处理完画面后，我选择先输出一个无压缩的中间文件，不要把最终编码放在同一轮流程里跑。原因是修复参数很难一次到位，如果你直接输出最终文件，每改一次参数就要重新编码一遍，浪费时间。

我是这样做的：先用无损编码输出一份中间片，然后播放器里连续抽帧检查；确认台标干净、没有梳状纹、线条没有明显振铃之后，再进入音轨和字幕环节。如果发现某个场景有问题，回到 VapourSynth 脚本里改参数，重新输出中间片。

这一步很笨，但很稳。修复老番不是跑批处理，它是“精细活”，每一帧都牵涉到审美判断。宁可多花时间抽帧对比，也不要等整集压完才发现问题。

4. 比修画面更折磨的环节：音轨对齐和字幕轴精调

4.1 从波形对齐音轨延迟：2150ms 是怎么测出来的

画面修完之后，你可能会以为工程快结束了。实际上，音轨对齐是另一场硬仗。我手里的录制版音频是 MP2 格式，虽然整体延迟相对固定，但因为它被广告切分过，开头和结尾的时间戳不可信。

处理音轨我推荐用 Audacity，朴素但有效。先把修复后的视频导出一条静音轨道（或者直接用原片视频），然后在 Audacity 里导入原音轨，放大波形视图，找到开头的鼓点或对话起始点，和视频画面对比。

我当时测出来整条音轨相对画面延迟了 2150 毫秒，也就是 2.15 秒。这个数字看着不大，但对看番体验来说非常致命——角色嘴型都对不上，连特效音都提前响了。用 Audacity 的“延迟”效果把整条音轨往前移动 2150 毫秒之后，再找一个中间的场景复核，确认误差控制在两帧以内，就可以导出成 WAV 或 FLAC 备用。

有一个小技巧：不要只对开头做对齐，必须在片头、中段、片尾各选一个参考点。因为很多录制版在前半段是准的，到后半段因为帧率问题会逐渐漂移，这种情况单纯用固定延迟是修不好的，得靠后期软件里的“音频拉伸”或者“按帧率重采样”来纠正。我这次运气好，是固定延迟，所以只做了一次平移就搞定。

4.2 字幕轴：所有版本的时间轴都是“仅供参考”

字幕的问题比音轨更琐碎。我从原来的 dragonballz_e232-2.mkv 里提取了一条简体中文字幕轨，但它是基于另一个版本的时间轴做的，也就是说，直接拿来用必然错位。

处理字幕我用的是 Aegisub，这是目前最顺手的字幕工具之一。流程是：

1. 把修复后的视频放进 Aegisub 的视频窗。
2. 加载字幕文件。
3. 找到第一句对白的实际开始帧，对照旧轴，算出差值。
4. 整轴平移，然后逐段检查。

如果只是整体平移，问题不大。真正麻烦的是有些地方的帧率不同，导致前半句准、后半句飘。比如旧轴是基于 23.976fps 做的，而我的录制源是 25fps，那么每过一分钟，字幕就会多偏移约 2.5 秒。这类问题的处理办法是重新调整帧率再平移，或者干脆用 Aegisub 的“将时间轴从 23.976 转为 25”工具。

遇到没有可用字幕的时候，我也会自己听写。听写龙珠台词不算太难，但要注意那些音译词和人名，不能全凭听力乱写，最好对照日本维基或英文站点的台词表做二次校准。比如贝吉塔叫错成“贝基塔”这种低级错误，一旦压进字幕里再发布，后续想改就要等到下一个版本，很影响口碑。

4.3 封装：mkvmerge 参数和轨道安排

画面、音轨、字幕都齐了之后，最后一步是封装成 MKV。我用的是 mkvmerge，命令大致如下：

bash复制mkvmerge -o dragonballz_e232-2.final.mkv \
  --default-track 0:0 --language 0:jpn e232-2.video.mkv \
  --language 0:jpn --default-track 0:1 e232-2.audio.mka \
  --language 0:chi --default-track 0:0 e232-2.chs.ass \
  --language 0:jpn e232-2.jpn.ass

这里有三个细节容易踩坑。第一，默认轨要设对，否则播放器可能默认加载日文字幕而不是中文字幕；第二，音轨最好转成 AAC 或 AC3，兼容性比 FLAC 好，虽然 FLAC 音质更高，但放到电视或一些家用播放器上容易不出声；第三，内封字体不是必须，但如果你用了特殊字体，最好把字幕转成图形字幕（PGS）或者将字体装入 MKV 的附件轨道，否则别人打开字幕就是方块。

封装完之后，我会用 MediaInfo 再检查一次轨道信息，确保语言标签、默认轨道、章节都正确。千万别小看这一步，很多重制版在下载站里被评论“字幕乱”“默认音轨错”，十有八九就是封装时少了语言标签或者默认设置没写。

5. 画质对比验证和发布配置：我踩过的一些坑

5.1 对比不能只看“变清晰了”，要看细节是否“活着”

修复完最爽的事情是截对比图。但对比不能只截一帧你精挑细选的静态画面，那叫“官方宣传片”。我习惯抽三个维度来对比：

• 静态背景：看台标区域是否干净，背景线条是否有色块。
• 角色脸部特写：看轮廓线是否自然，皮肤涂色区域是否过平滑。
• 高速运动画面：看有没有重影、线条断裂、马赛克残留。

我抽第 232 集后半段里悟空快速移动的场景时，发现 QTGMC 默认参数在高速横移的镜头里产生了轻微重影，画面的边缘会拖出半透明的残影。这个问题在静止帧里完全看不出来，但只要播放起来就特别明显。后来我调整了 QTGMC 里的 TR 参数，让相邻帧的信息参与去交错，重影才消失。

下面是一个简单的对比维度表，你可以参考着建立自己的检查清单：

5.2 最容易翻车的三个地方，我全都栽过

第一是降噪过度。我最初把 BM3D 的 sigma 拉到 2.0，结果背景非常干净，角色脸也干净到发假。后来才明白：降噪强度要跟着“片源噪点层级”走，不是越高越好。第二是台标补洞产生的糊块。动态背景下的台标去除，仅靠 delogo 的矩形填充完全不够，出来的背景会和周围材质断裂，像贴了一块马赛克。后来我改用按帧补全的 mask 方法，把台标底下的背景纹理补了回来。第三是倍线后的振铃效应，也就是线条外侧出现一圈虚影。这个问题的来源是锐化过度，而不是缩放阶段的问题。降低 LimitedSharpenFaster 的强度之后振铃基本消失。

如果你也打算做老番重制，我的建议是先拿一集里最复杂的一分钟来做试水，调好参数再批量跑整集。不要一开始就跑整集，等几个小时后看到结果再返工，那种时间成本实在太高了。

5.3 最终编码参数与命名规范

成品压制的编码参数，我用的是 x265 的 10bit 模式，CRF 18，preset medium。CRF 越高文件越小，但画质损失越明显；CRF 18 在 10bit 下已经非常接近视觉无损，再低到 14 或 16 只会让文件体积暴涨，而肉眼几乎看不出来。Preset 推荐 medium 或 slow，再慢就没有必要了。

bash复制ffmpeg -i e232-2.intermediate.mkv -map 0:v:0 -c:v libx265 -crf 18 -preset medium -tag:v hvc1 -pix_fmt yuv420p10le e232-2.video.mkv

注意 -tag:v hvc1 这一步不能省。很多播放器，包括苹果设备上的播放器，只认 hvc1 标签；如果不加，封装出的 HEVC 会在某些平台上无法播放。这个坑我以前栽过，后来固定写进了脚本里。

最终的文件命名我统一成：DragonBallZ_E232_B_Part2_1080p_Restored.mkv。我知道有的朋友喜欢用原文件名 dragonballz_e232-2 来保持“原汁原味”，但对于收藏型文件，清晰可读的名字比短名更重要，至少 -2 这种歧义不能再出现了。

6. 这套流程能不能批量复用？我在实际使用中的经验和扩展

把第 232 集后半段跑通后，我顺手处理了前面几集。批量处理最大的收获不是效率，而是“参数稳定性的考验”。

单集处理时，每一次翻车都是可控的，你可以盯着屏幕调参数。但一旦写成一个批处理脚本，它就会暴露很多“单集环境下不会出现”的问题。比如台标位置可能因为不同片段的分辨率微调而偏移几个像素，或者某些场景的光线变化导致降噪强度不一致。所以我的建议是：不要指望一套参数从第一集用到最后一集，要把“分场景调参”当成一个正常状态，而不是意外。

具体做法是把 VapourSynth 脚本拆成两层：

• 第一层是全局参数，包括基础分辨率、倍线算法、输出格式。
• 第二层是逐集覆盖参数，包括降噪强度、台标位置、锐化强度。

跑脚本的时候先输出一整季的“低强度快速预览版”，播放着检查几个关键镜头，确认没问题后再跑最终版。预览版的分辨率可以减半，参数降到最保守，目的是快速发现问题，不是为了看最终效果。

我个人对老番修复的最终体会是：修复是有“度”的，这个度取决于片源本身，而不是取决于你的滤镜能力。像《龙珠Z》这种经历过赛璐璐时代、胶片转换、电视播出的老动画，它的画面天生带着颗粒感和色彩偏差，这些都是时代的一部分。修复的意义在于把“电视信号损失”和“编码劣化”去掉，而不是把作品变成一部现代画风的翻新版。

第 232 集的后半段，我现在偶尔还会翻出来看。画质干净了，台标没了，音画同步了，字幕也顺了，但它看起来仍旧是一部有点“糙”的老动画——这一点我很满意。如果你手里也有一个类似 dragonballz_e232-2 这样的文件，试试按这套流程走一遍，你会比那些直接下别人压好的版本更懂这部片子。