音游谱面预览视频制作全流程：以Cryogenic FBD12 6.0速为例-平芜编程栈

《In Falsus》里的Cryogenic这张 FBD12 谱面，用 6.0 速播放预览，第一眼看到的往往不是“难度”，而是谱面在高速下是否干净、能不能读。谱面预览在这个圈子里承担的任务很明确：制谱作者用来复查手感，玩家用来判断要不要挑战，视频作者用来做谱面收录、难度拆解和搬运。这次我们就把“制作一版可发布的 FBD12 谱面预览”当成一个完整流程来处理。

这不是一个需要显卡、显存、API 的 AI 类项目，而是一个偏内容生产和技术执行的任务。关键点有三个：用什么载体播放谱面，怎么把画面稳定录下来，以及 6.0 速下应该观察哪些键型特征。文章会按“预览准备 → 录制 → 拆解分析 → 批量处理 → 性能观察 → 问题排查 → 发布”的顺序展开，也会给出 ffmpeg 和 Python 的可复用处理脚本，方便之后做曲包或谱面合集时直接套用。

先说结论：如果只是为了发一条谱面预览，不需要换硬件，不需要额外装模型，普通手机或电脑模拟器都能完成。真正影响成片质量的，是“录制帧率是否稳定”和“是否保留 6.0 速下完整可读的画面”。下面逐段拆开讲。

1. 谱面预览信息速览

先把这版谱面预览涉及的关键信息整理成一张速览表。

能力项	说明
项目类型	音游谱面预览视频制作
曲目与难度	Cryogenic / FBD12，具体难度含义以游戏内难度表为准
预览速度	6.0 速
核心用途	制谱复查、玩家读谱、谱面收录、手元拆解、难度讲解
涉及 AI 能力	不涉及。不需要大模型、OCR、TTS 或目标检测
硬件要求	无明显额外门槛。手机端内录和模拟器录屏都可用
软件要求	游戏回放/试玩、录屏工具、ffmpeg、图片查看工具
是否需要 API	不依赖在线 API。批量剪辑时可走 ffmpeg 命令行
批量任务支持	可用 ffmpeg 批量切片、抽帧、重新编码
推荐输出规格	1080p/60fps 起步，高密度谱面优先保证帧率，再提高码率
发布注意事项	标注歌曲名、难度、速度、谱师或谱面来源，确认授权后再搬运

这里的“6.0 速”不是判定数值，而是播放画面中 note 落下的显示速度。不同音游对“速”的定义有差异，但在做视频预览时，我们只关心它带来的视觉结果：同一段时间内出现的 note 数量更多，位移更快，对录制设备的画面连贯性要求也更高。

2. 适用场景与使用边界

谱面预览适合谁？至少有三类读者会直接受益。

第一类是普通玩家。FBD12 通常是难度表里的高位段，玩家在决定推分前往往想先看一遍谱面跑图，判断键型是否适合自己。比起从零开始打一把，预览能提前暴露密集纵连、爆发段、位移较大的楼梯配置，帮助玩家选择练习顺序。

第二类是制谱作者。自己做的谱面在编辑界面里看是一回事，放在 6.0 速下回放是另一回事。速度提高后，原本在低倍速下不明显的视觉拥挤、轨道重叠、提示点不足等问题会迅速暴露。很多制谱错误都是通过预览回放发现的。

第三类是做谱面收录、难度讲解的 UP 主和图文作者。封面图、谱面展示片段、关键段慢放这些素材，都来自一次性高质量录制。如果没有一套稳定的预览录制流程，最后容易出现音画不同步、模糊、掉帧，影响讲解可信度。

使用边界也要说清楚。预览视频本质上是对他人谱面作品或游戏内容的再展示，并不等于可以免费搬运、下载或随意加工。正式发布前，需要确认：

谱面是否为本人制作。非本人创作时，应标注谱师或原作者。
是否使用了游戏内正常播放/回放功能。不建议通过破解、注入或擅自修改数据文件来制造特殊预览效果。
如果谱面尚未公开，或者属于内部测试版本，原则上不要泄露完整铺面内容。
曲绘、背景素材、歌曲音频同样存在版权问题。尤其是“谱面预览”类视频，背景音乐是相对明确的版权对象，公开分发时应选择已经获得授权的曲目。

3. 预览前的准备工作与速度设置

录制前先确认几个前置条件，能省掉后面大量返工。

第一，确认游戏版本和谱面入口。不同版本里 FBD12 谱面的实际铺面可能不同，进入方式也有差异。有的游戏支持直接开启“预览/回放”，有的只能用练习模式 + 自动播放或镜像播放实现。进入前先确认当前使用的是官方版本还是第三方修改版本，不要在缺少版权说明的改版环境下直接录制。

第二，把游戏画面设置成固定状态。推荐先关闭游戏内不需要的弹窗、通知、连击特效和动态背景干扰。如果游戏本身支持调速，将速度调整为 6.0 并固定下来。这里要特别注意：不是所有音游的“速度”都以数值倍率显示，有的采用“速 6.0”这类档位编号，有的则直接是 BPM 比例。录制前多录 10 秒检查一次，确保显示的是目标档位。

第三，先做一次低画质试录。不要一上来就开 4K 加极高码率录制完整谱面。高难谱面在后半段可能堆积大量 note，导致画面渲染压力骤升。先以 720p/30fps 试录一段 30 秒的爆发段，回放时看是否出现掉帧或音画不同步。如果没问题，再切换到 1080p/60fps 正式录制。

第四，确认录制时的声音通道。谱面预览必须保留准确的 BGM，否则后续无法判断 note 是否压在拍点上。如果使用模拟器，检查音频采样率和视频帧率是否匹配。常见问题是模拟器把音频输出成 44.1 kHz 或 48 kHz，而录屏容器按 30/60fps 封装，导致后期音画偏差逐渐拉大。

需要说明的是，以上流程不完全依赖某一种特定设备。手机、平板、PC 模拟器、甚至游戏原生 PC 版都可以按这个思路执行。差异主要出现在帧率稳定性和编码可用性上，下一节会讲到如何控制这部分变量。

4. 录制预览视频：从游戏画面到可发布文件

4.1 优先选择“游戏内回放 + 内录”的方式

产生谱面预览视频的最佳方式，是游戏自带的谱面回放或自动播放模式。原因很简单：回放模式不会因为玩家操作失误而中断，画面也不会出现多余的手指遮挡。

移动端录制时，推荐优先使用系统内录。iOS 和安卓都有系统级录屏功能，基本能保证 60fps 输出。注意三个设置：

关闭屏幕自动关闭，防止录制中途息屏。
开启“勿扰模式”，避免消息横幅进入画面。
关闭触控指示图层，避免屏幕上的白点或手型轨迹遮挡轨道判定区域。

模拟器录制时，帧率能否跑满 60，取决于模拟器对 GPU 的调用效率。不要只看游戏画面流畅度，还要看录屏软件能否抓到每秒 60 帧的独立视频流。建议先在任务管理器里观察两项指标：GPU 3D 占用和 Video Encode 占用。如果 Video Encode 接近满载，说明硬件编码已经吃紧，应降低分辨率或码率。

4.2 使用系统录屏还是第三方录屏

只录一段简单预览，系统录屏完全够用；需要频繁剪辑、保留无损素材、做多机位对比时，桌面端建议直接用 OBS 录像。

OBS 中的关键设置并不复杂：

配置项	推荐值	说明
输出分辨率	与游戏分辨率一致	避免二次缩放产生模糊
帧率	60 fps	高密度谱面不要使用 30fps
编码器	NVIDIA NVENC / AMD AMF（桌面端）	优先硬件编码
码率控制	CBR 或 VBR	建议 1080p/60fps 时 12–16 Mbps
音频	桌面音频 + 麦克风分开	方便后期单独处理解说
色彩格式	避免 4:2:0 极端压缩损失	常规 Rec.709 即可

模拟器窗口建议固定尺寸，不要使用“窗口自适应缩放”。录制时如果游戏帧率低于显示器刷新率，OBS 可能插入重复帧，虽然播放器显示仍是 60fps，但实际运动不连贯。判断方法很简单：把录好的视频逐帧快速切图，如果连续两帧完全相同，说明发生了重复帧。

4.3 用 ffmpeg 做基础剪辑和重新编码

录屏文件往往很长，正式发布前需要切片、标记起点终点、统一编码。这里给出一套通用 ffmpeg 命令模板，具体路径需要替换成自己的实际文件名。

# 从原文件中截取 00:00:20 开始的 45 秒片段，并重新编码为 H.264 ffmpeg -i raw_preview.mp4 \ -ss 00:00:20 -t 00:00:45 \ -c:v libx264 -preset medium -crf 18 -pix_fmt yuv420p \ -c:a aac -b:a 192k \ cryogenic_fbd12_6x_preview.mp4

这条命令把原始录制文件裁剪成 45 秒预览视频。-crf 18属于视觉无损区间，适合做成片；如果只是临时归档素材，可以把-crf调到 23 以上缩小体积。

如果要生成慢放片段用于键型分析，可以用如下方式，把画面速度放慢到原来的 50%：

# 将视频画面时间轴拉长一倍，实现 0.5 倍慢放 ffmpeg -i cryogenic_fbd12_6x_preview.mp4 \ -filter_complex "setpts=2.0*PTS" \ -an slow_0_5x_preview.mp4

注意：直接修改PTS只会改变画面播放时间轴，音频不会自动随之拉伸。如果需要带 BGM 的慢放，必须额外使用音频变速滤镜，如atempo，否则会产生音画错位。建议普通发布视频不采用慢放方式，慢放只作为分析素材存在。

5. 用预览拆解谱面：键型、位移与易读性

当你面前有一段“6.0 速完整跑图”的视频，不要只看完整播放，更有效的做法是分三个层级观察。

第一层，全速看完整个谱面。这个阶段只回答两个问题：全曲的密度分布是否均匀？有没有某一两段明显超过全曲平均密度？如果全速播放时眼睛已经捕捉不到 note，说明该段对玩家的瞬间反应要求极高。反过来，如果全速播放时能较清晰地数出连续 note 的行进方向，说明铺面提示做得相对好。

第二层，慢放观察键型。桌面端可以把录制视频导入剪辑软件，像看逐帧动画一样拖动时间轴。音游铺面中常见的键型特征包括：

纵连：连续多个 note 落在同一轨道或相邻很近的轨道上；
楼梯：note 沿轨道连续平移，形成斜向路径；
双押：同一时刻多个轨道同时触发；
叠键：先后两个 note 在视觉上距离极近，甚至出现遮挡；
交互：左右手交替击打的连续 note 排列。

分析时，把视频调到 0.25 倍，逐段判断这些键型出现在第几秒、属于哪一组小节、主位移方向是什么。可以先把问题记录成文字，再结合音频判断是否对应重拍或旋律变化。

第三层，观察轨道重叠与遮挡。6.0 速会把低倍速下相距很远的 note 压缩到较近的时间窗口。如果两个 note 间距很小，并且颜色、大小没有区分，那么玩家在实际游玩时几乎无法判断先后顺序。这不是“手法难度”，而是铺面可读性问题。

重点提醒：只靠预览视频无法确定 note 的精确判定间距，因为显示是连续的，而谱面文件里的 note 时间轴可能有更细的精度。更严谨的做法是用谱面文件导出的时间轴配合视频分析，或者结合游戏内暂停截图来确定关键拍点的准确位置。如果手上没有谱面文件，就不要在结论里写死“某处一定是多少个 16 分音符”，建议用“视觉上高度密集”“疑似存在较密叠键”这类偏观察性的表述。

5.1 用逐帧截图辅助分析

把 6.0 速预览视频抽成均匀帧，可以一次性看到 note 在画面中的水平分布。下面的命令会每隔 6 帧抽 1 帧，把画面保存到frames目录。

mkdir -p frames ffmpeg -i cryogenic_fbd12_6x_preview.mp4 \ -vf "select='not(mod(n,6))',setpts=N/(60*TB)" \ -vsync vfr frames/f_%05d.png

此时生成的图片已经按原视频正常时间戳保存。用支持快速翻页的图片工具打开这些 PNG，就能观察每个时间点的轨道占用情况。

如果需要把若干帧拼在一张图里做对比，可以运行下面的 Python 脚本。它会读取frames目录里前若干张 PNG，横向拼接成一张长图，方便观察同一段内轨道变化的趋势。

from pathlib import Path from PIL import Image frames = sorted(Path("frames").glob("*.png")) selected = frames[::10][:12] if not selected: print("未在 frames 目录中找到图片，请先执行 ffmpeg 抽帧命令") else: imgs = [Image.open(p) for p in selected] width = sum(im.width for im in imgs) height = max(im.height for im in imgs) sheet = Image.new("RGB", (width, height)) x = 0 for im in imgs: sheet.paste(im, (x, 0)) x += im.width sheet.save("sequence_compare.jpg", quality=90) print("已生成 sequence_compare.jpg")

需要安装 Pillow 库才能运行：

pip install Pillow

这个脚本只做最基础的“连续画面拼合”，虽然不涉及谱面内部数据，但对观察整张铺面在高速下的空间分布很有帮助。用拼接长图对比时，重点看轨道列上的浓密程度，而不是单张 detail。

6. FBD12 这类高难谱面的观察重点

Cryogenic 的 FBD12 属于高难谱面后，阅读方式不能停留在“难不难”的表面。更难也更有价值的内容，是判断这种难度是否有清晰的书写逻辑。下面的观察维度可以直接套用在其他 FBD12 谱面上。

6.1 密度峰值与休息段的搭配

好的高难谱面不会从头到尾保持同一个密度，而是会在连打、爆发和间隙之间留有呼吸空间。如果 6.0 速预览中出现连续 20 秒以上超高密度段，玩家实际游玩时容易产生体力和注意力的双重透支。观察预览时，可以记录密度峰值持续时间和峰值前是否出现明显跳变，如果峰值只是短暂 3～5 秒，说明谱面作者可能只在旋律记忆点处加难；如果峰值持续超过 10 秒，建议在视频简介里明确标注“耐力段较长”，避免玩家误判。

6.2 高难段切换是否伴随视觉提示

FBD12 谱面在进入爆发段时，前面的铺面是否给出节奏变化信号，会影响玩家是否能提前调整握持和读谱习惯。如果预览里上一段还是稀疏音型，下一段直接进入高速密集音符，没有任何渐入缓冲，这类“阅读陷阱”通常容易让初次尝试的玩家快速掉血。

6.3 位移轨迹是否与人体动作协调

用手元视角观察时，关注角色或谱面要求的手指移动方向是否是自然轨迹。例如连续双押后接大跨度楼梯，会让手部肌肉状态发生剧烈切换。长时间看预览如果觉得“眼睛很累”，这种感受本身已经可以作为风险指标。

6.4 音画是否对齐

谱面预览最大的优势就是能直观看到 note 是否对准音乐节拍。6.0 速下如果 note 落到判定线的瞬间明显偏离听觉节拍，那可能是铺面 BPM 设置或 offset 本身存在误差。这种误差在预览视频里会被放大，所以发布前需要单独检查 3～4 个强音位置。

需要明确的是：即使预览显示没问题，也不能推断实际良率或理论值可行。高难谱面的物理表现、设备延迟和个人手法都会影响最终成绩，预览只是手段之一。

7. 批量处理与素材管理：曲包级预览工作流

需要整理曲包、多难度谱面或制作谱面合集时，不可能一只手动用剪辑软件。这里提供一套可以复用的“批量预览素材处理”思路。

首先要统一文件命名。推荐格式为：

游戏名_歌曲名_难度_速度_日期.mp4

例如：

InFalsus_Cryogenic_FBD12_6x_20250101.mp4

这样在后续遍历时，可以通过文件名中的难度字段快速筛选。下面给出一个 Python 脚本示例，它会遍历指定目录下的所有 mp4，并输出视频分辨率、时长和帧率信息。这个脚本适合录完大量谱面后先做一次归档检查。

import subprocess from pathlib import Path video_dir = Path("./previews") for video in sorted(video_dir.glob("*.mp4")): result = subprocess.run( [ "ffprobe", "-v", "error", "-select_streams", "v:0", "-show_entries", "stream=width,height,avg_frame_rate,duration", "-of", "json", str(video), ], capture_output=True, text=True, ) print(video.name) print(result.stdout)

如果发现某个视频时长过短或帧率为 0，说明录制可能中断或损坏，可以先挑出来重新录制。运行时需要本地安装 ffmpeg，并且确保ffprobe已被加入系统 PATH。

批量切片也可以只准备一份原始录像，然后用命令逐段生成多个片段。比如要切 3 个高亮段，可以在一个脚本里多次调用 ffmpeg：

# 对同一份录像截取三段不同区间，文件名按难度标识区分 ffmpeg -y -i raw_fbd12_6x.mp4 -ss 00:00:05 -t 00:00:10 \ -c copy part1_intro.mp4 ffmpeg -y -i raw_fbd12_6x.mp4 -ss 01:12:00 -t 00:00:18 \ -c copy part2_burst.mp4 ffmpeg -y -i raw_fbd12_6x.mp4 -ss 01:50:30 -t 00:00:15 \ -c copy part3_climax.mp4

这里使用-c copy是流复制模式，速度快且无画质损失，但要求截取的起始时间对齐关键帧位置，否则播放器可能会闪第一帧。发布成品时，仍然建议用上一节的完整重编码方式重新输出一次。批量任务的核心是日志和重试，如果切了很多段，一定要在脚本中为每个命令设置独立输出目录，防止互相覆盖。

8. 资源占用与性能观察

跑一段谱面预览并不需要高端 GPU，但它属于“长时间持续渲染 + 实时编码”的双重负载任务。观察性能时，关注重点不是“显存占用”，而是下面四个指标。

GPU 3D 占用：反映游戏渲染压力。如果持续超过 90%，说明游戏画面本身可能不稳。
Video Encode 占用：反映硬件编码压力。如果接近满载，录制画面可能出现帧率波动，但不一定影响游戏内的实时画面。
内存占用：长时间预览和多次重录会积压内存，尤其是模拟器，建议保持内存占用不要长期逼近物理内存上限。
温度与降频：手机端录 10 分钟以上容易触发温控降频，表现是游戏画面还行，但录屏码率或帧率下降。这种情况优先缩短录制时间，拆分段落录制，而不是一直录完整段。

实际操作时，推荐“分段录制 + 一次拼接”的方式：先把一首歌拆成前段、中段、后段，分别录制；每段录完先检查单段画面是否有重复帧，再统一拼接。这样即使某一端出现卡顿，也不需要从头重录。

低分辨率是否真的能降低负载？对于硬件编码而言，分辨率降低通常会减少编码压力。但音游谱面预览要求能看清 note 和判定线位置，分辨率过低会出现压缩伪影，反而影响分析。1080p/60fps 是一个比较合理的折中点；若要追求极高的“逐帧可读性”，优先提高帧率而不是分辨率。

编码格式上，H.265 比 H.264 同码率下体积更小，但对编码器压力更高。如果设备编码器较强，可以使用 H.265 归档，发布到公共平台时再转回 H.264，避免播放器兼容性问题。

最终成片也不建议在录屏文件基础上反复导出，因为每转一次都会引入一次压缩损失。正确流程是先录制并抽帧检查，确认无卡顿和音画偏移后，把剪辑、调色等操作集中在一次导出里完成。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
录出的视频播放时像“跳帧”	游戏帧率与录制帧率不一致，或编码器满载	用 ffprobe 查看视频实际帧率，逐帧观察是否有重复帧	降低录制分辨率或改用硬件编码，固定游戏帧率为 60fps
音画逐渐不同步	录屏时音频时钟与视频帧率没有对齐	播放到后半段，观察 BGM 是否越来越早/晚；对比原曲总时长	改用系统内录或 OBS 统一时钟；剪辑时不要使用流复制直接拼接
画面出现花屏或色块	编码器设置错误、模拟器渲染异常	先关闭硬件编码，改用软件编码测试；检查驱动	重置编码器设置或升级显卡驱动程序
慢放时音画不同步	只用`setpts`拉伸画面，没有处理音频	检查是否未添加音频滤镜	参考 ffmpeg 音频变速处理，或关闭原声后单独补音轨
视频文件过大	码率设置过高，或录制时间过长	用媒体信息工具查看码率	调整 CRF 或码率上限，归档用 H.265
6.0 速下 note 视觉模糊	录制帧率过低，或压缩伪影严重	截帧观察 note 边缘是否清晰	提高帧率到 60fps，提高码率，避免导出到低清平台后再放大
模拟器录制时游戏流畅但录屏卡	独立录制进程和游戏竞争编码器资源	查看任务管理器中 Video Encode 占用	改用 GPU 硬件编码或换用内录模式
发布到平台后画面更糊	平台二次转码降码率	对比本地源文件和平台播放效果	本地保留高码率素材，平台版本适当锐化或提高灰度细节

如果音游本身没有回放功能，但玩家自己完成了一局手元，同样可以按照上面的流程录制。不过“手元录制”会增加手指遮挡因素，建议正式录制前先模拟一遍完整动作，确认不会在关键键型区遮挡判定线。手动录制的预览还有一点风险：玩家实际打到的 note 和铺面理论上应该出现的 note 不一定一致。这类素材的定位应是“手元表演”，而不是纯粹谱面预览。

10. 发布与合规建议

发布谱面预览视频前，最后要做一次完整的信息检查。

标题中是否包含曲目名、难度和速度。例如“Cryogenic FBD12 6.0速预览”，能让观看者在搜索时快速定位。
简介或置顶评论是否标注谱面作者。非本人制作的谱面，不标作者容易引发二次转发纠纷。
是否有必要加上“谱面内容仅为预览展示，难度以正式版为准”之类说明。尤其是测试版本谱面，这个提示可以降低信息误导。
如果视频中出现了游戏 UI、曲绘、人物立绘和背景素材，是否已经满足素材使用边界。音乐游戏的谱面预览视频通常属于游戏内画面的再展示，但不同游戏和平台对搬运内容容忍度不同，不能一概而论。稳妥做法是优先发布到作者本人账号，或获得授权后发布。
涉及“挑战”“收割”“AP 手元”等关键词时，不要夸大通关能力。预览不等于实战，更不等于理论值验证。

另外，不要在预览视频中声称谱面文件可以下载、诱导私信发送谱面源文件。如果只是分享谱面，应提供明确的官方来源，而不是把别人未公开的数据包直接转发。遇到玩家在评论区求谱面文件时，直接说明“请前往官方渠道”或“请向谱师确认授权”即可。