给视频配一段完整 BGM：一次生成还是分段拼？

本文是《Mac mini 玩转 ComfyUI》专栏第 14 篇，音频篇第二篇。第 13 篇回答"能不能生成"------20 秒热态 2.1 秒，130 秒 40.8 秒；这一篇回答"怎么交付一段能用的完整 BGM"：把《钧天》2×68s 的分段工艺完整摊开，再和 mini 的 130 秒一次生成做一次同素材对照。
实测环境：Mac mini M5 Pro / 64GB / ComfyUI 0.43.0；本文全部数字实测于 2026-10-31。《钧天》（2026-10-20）、《玄穹》（2026-10-28）是历史归档，引用时单独标日期，不与本轮混排同一口径表。样本编号（J 组 / F 组 / L 组）与复现脚本随文标注。

第 13 篇结尾埋了三个问号：为什么要分段？acrossfade 的 8 秒怎么定？一次生成和分段拼接到底选哪个？ 这一篇用同一台机器、同一句 prompt、同一套 seed 回答。

先把结论放前面：分段从来不是为了音质，而是为了三件事------绕过内存墙、让迭代便宜、把无缝循环做成工程。内存墙今天可以靠硬件解决（64GB 的 mini 跑 130 秒只是 36 秒的事），后两件仍然只有"分段 + 拼接"这条链能优雅做到。你要 115 秒能循环、改段落不像重做、改一处只重跑 12 秒------分段工艺就还在。

一、《钧天》那晚：一段 115 秒的曲子是怎么变成 2×68s 的

2026-10-20，官网首页要一段 BGM：《钧天入座》，目标约 115 秒、能循环、-24 LUFS。当时跑 generate 的机器是 .31（Alienware / GTX 1070 8GB / 16GB 内存，ComfyUI 0.38.1）。

第一反应是直接生成 130 秒一枚。结果系统 OOM：进程 RSS 冲到 11GB / 16GB ，服务被内核 kill（2026-10-20 归档实录）。这不是模型限制------第 13 篇已经实测过 mini 上 130 秒、300 秒都一次通过------是那台 16GB 机器的内存上限。当天就换了工艺：

步骤	实际做法（历史归档，2026-10-20）
分段	2×68s：A 段 seed 42，B 段 seed 43，同 prompt；68s 在 .31 上约 3 分钟/枚
截静音	−40dB/0.3s 探测：A 头 1.0s + 尾 1.7s，B 尾 1.3s；实际截取 A 2.0--66.3s、B 0--66.6s
段间拼接	`acrossfade d=8, tri/tri` → 122.9s 整曲
首尾循环	acrossfade 8s → 114.9s
响度	两遍 loudnorm：I=−24 / TP=−3 / LRA=7 → 实测 −24.5 LUFS / −5.4 dBTP / LRA 8.0
交付	mp3 128k CBR，1.84MB ，ID3 title=钧天 artist=羲和Lab；上线 `public/bgm/juntian-v1.mp3`

prompt 原文照录（本文本轮的 J 组也原样用它，一个词没改）：

text 复制代码

slow ambient Chinese traditional music, guqin open-string phrases in pentatonic scale,
sparse stone chime accents, occasional water drop plinks, deep dark atmospheric synth pad,
spacious cold night sky mood, meditative, calm and restrained, no drums, no vocals, 60 bpm, seamless loop

两个关键决定值得说透：

A/B 两段必须换 seed。 同 seed 同参数会生成逐样本一致的曲子（第 13 篇的复现结论），两段一模一样拼起来就是复读机。seed 42/43 是"两首不同的 take"，在 crossfade 里交接班。

"medium 单枚 ≤68s" 是内存上限，不是模型上限。 换成 mini 的 64GB，这条红线今天不存在------所以《钧天》当年"必须分段"的第一个理由，已经被硬件化解。剩下两个理由还在，往下看。

这张判据把整个问题压缩成三问：

二、8 秒怎么定：一小节两拍，再加一层余振

acrossfade=d=8 当年不是拍脑袋。两条依据：

节拍：JP1 写着 60 bpm；按 4/4 算一小节 4 秒，8 秒正好两小节。crossfade 覆盖完整小节结构，接缝听起来是"乐句呼吸"，不是"卡带"。
混响余振：ambient 的长尾混响，一记琴音的余振衰减到 −40dB 往往要 5--7 秒（《钧天》归档实测各段尾静音 1.3--1.7s 只是"完全归零"的部分）。crossfade 窗短于余振，新内容进来时旧余振还没淡干净，听感就是"两首曲子叠着"。

今年重做《玄穹》时沿用的也是 8s；本轮再补一次单变量对照（同一对段 J2a/J2b，只改 d）：

组	acrossfade	整曲长	接缝 ±2s 谱通量 z 值（全片基线）
F4	d=4	127.6s	4.94
F8	d=8（《钧天》同款）	123.6s	5.60
F16	d=16	115.6s	2.72

读法要说实话：16 秒的 z 最低不奇怪 ------窗越宽越顺；但 4 秒和 8 秒的 z 都和曲内自然起伏同一个量级，程序指标分不出 4/8/16 谁更"自然" 。真正的裁决有两个：一是《钧天》在官网播放器连续循环播放了 8 天 （2026-10-20 交付 → 2026-10-28 才换《玄穹》，两个日期都在归档里）的日常实证；二是本文第六节的试听视频，你在 0:16 处亲耳听这条 8 秒的缝。

8 秒的答案是"两小节 + 余振"的推算，不是玄学：60 bpm 写进 prompt 这一步，就已经把 crossfade 的下限定了一半------这也是第 13 篇"写编制词、不写形容词"的又一处回报。

三、mini 64GB 之后：J 组对照，一次生成 vs 分段拼

今年 mini 到位后（M5 Pro / 64GB，0.43.0），第 13 篇实测 130 秒热态只要 40.754s 。内存墙拆除之后，能不能干脆一次生成整曲？本轮把《钧天》配方原样搬到 mini 上对照（JP1 / 8 步 / lcm·simple·cfg1.0 / 44.1kHz）：

样本	配置	wall	实测时长	LUFS / TP	文件
J1	130s / seed 42 / 一次生成	36.39s	130.032s	−18.8 / 0.0	11.9MB FLAC
J2a	68s / seed 42	12.405s	67.988s	−17.6 / −0.4	6.9MB
J2b	68s / seed 43	12.255s	67.988s	−21.6 / −1.6	6.4MB
R1	68s / seed 42 / 第二遍	12.148s	67.988s	同 J2a	PCM md5 同 J2a

先交代计时口径 ：mini 上还有别的项目在共用队列，J1 是排在一个 Qwen-Image-Edit 任务后面执行的，36.39s 是服务端 running→success 的时长（含冷加载 ，不含排队等待）。共享机器上排队时间是别人的进度，不能算进自己的账------这也是记录 manifest 时要写 wall_scope 字段的原因。

三笔账，这才是"一次 vs 分段"的真正比较：

时间账 ，用第 13 篇热态口径算更公平：130s = 40.75s vs 68s = 12.31s，一次生成的整曲约等于 3.3 倍单段耗时；本轮一次 36.4s vs 两段 24.7s------即便把 J1 的冷载大方摊进去，"总生成时间"的差距也就是 1.5× 上下。64GB 机器上一段一次过不是问题。

迭代账 ，这是分段真正的杀招：想改 B 段一句 prompt，分段只用重跑 68s 的 12.3 秒 ，整曲路线要全曲重跑 36--40 秒，差 3 倍。分段的本质就是"改动只作用于被改的那一段"------采样一步都不会少跑，能少跑的只有"没被改的段落"。

复现账 ：R1 和 J2a 的解码 PCM md5 完全一致 （532be0f3...）------同机同栈同 seed 可复现，对照组因此成立；这也顺带验证了第 13 篇"同机同栈、同 seed 同参数 → 可复现"的结论在 68s 长曲上仍然成立。

红线先声明：J1（seed 42 一次 130s）和 J2（seed 42+43 分两枚）走的是不同的采样路径 ，产物本来就是两首曲子。这组对照比的是交付能力 ------时间、迭代、循环------不是音质胜负 。谁更好听得耳朵说，本文第六节的 0:16 就是留给你的裁决点。

四、循环：prompt 里写 seamless loop，机器不替你还愿

J1 的 prompt 里带着 seamless loop（和《钧天》同一句收尾）。但实测头尾：

头 8s × 尾 8s 波形相关 0.0026 ；把尾静音（−40dB 下 1.863s ）剔掉、取纯音乐尾 8s，相关 −0.09；
头是"古琴起句"的开场密度，尾是收束段------头尾根本是两段不认识的曲子；硬把 J1 绕成环，先穿过 1.9 秒的空场，再从"不认识的开始"接回去。

"seamless loop"在 prompt 里是愿望，不是指令------模型没有"让结尾缝合起点"的显式训练目标。想无缝，得自己构造，而这正是当年《钧天》"首尾循环 acrossfade 8s"那一步踩过的坑，也是 2026-10-28《玄穹》上线时被修正的事：

旧构造（《钧天》当年"整曲×头 8s"的思路）：整曲的尾直接绕回头。这条缝会出现在"尾内容 → 头内容"这两个互不相识的点上，头部形成内容跳变（2026-10-28 归档勘误）。
新构造（《玄穹》定稿，本文 J2L 同款） ：取整曲 M，尾 8s crossfade 进头 8s，然后丢掉原头 8s：

bash 复制代码

# J2L = M − 8s，wrap 接缝两段都是"M 的第 8 秒点" = 同一内容点
ffmpeg -i M.flac -filter_complex \
  "[0]atrim=start=8,asetpts=PTS-STARTPTS[body]; \
   [0]atrim=end=8,asetpts=PTS-STARTPTS[head]; \
   [body][head]acrossfade=d=8:c1=tri:c2=tri" J2L.flac

magic 在最后一步：[body][head]acrossfade 之后，输出的最后 8 秒 是"曲尾内容 × 曲头内容"的混合区，而输出开头（body 的起点）就是 M 的第 8 秒内容；而输出结尾（head 的终点）恰好也是 M 的第 8 秒内容------循环点两边是同一段波形，缝在理论上不可闻。J2L 实测 115.62s = M − 8s，和《钧天》114.9s /《玄穹》116.9s 同一量级（后两个为归档数字）。

对照组也做了：L2a ------同样掐头 8s，但不加 crossfade 的裸环。wrap 处谱通量 z 5.43，J2L 5.47------指标差异无感，因为两条的缝在光谱上都不"炸"；但构造二的接缝落在内容连续处是设计保证的，不是指标给的。这种级别的"顺不顺"，只能耳朵判，本文不去抢这个裁判座。

五、交付链：截静音 → loudnorm → mp3，LRA 又立功

J2L 拼出来是 −19.32 LUFS / TP −0.41 dBTP / LRA 9.40（SA3 的输出就是没被治理的，13 篇说过"SA3 不负责响度"）。按《钧天》协议跑两遍 loudnorm：

口径	normalization	实测
I=−24 / TP=−3 / LRA=7	dynamic（逐窗增益 std 1.16dB）	−24.0 / −5.4 / LRA 7.0
I=−24 / TP=−3 / LRA=10	linear （逐窗增益 std 0.0000dB）	−23.9 / −5.1 / LRA 9.1

LRA 约束又来了 ：J2L 源 LRA 9.40，目标 LRA 7 就得压动态，loudnorm 自动退 dynamic；把 LRA 放到 10（≥源），linear=true 真正生效------同一素材、一个参数之差，从"逐窗压扁"变成"恒定增益 −4.68dB"。第 13 篇的结论在这里原样复现。

本轮交付选哪条？垫底类 BGM 用 I=−24 / TP=−3 / LRA=7 那版 （等于《钧天》协议；第 12 篇的混音口径同样是 BGM 用 −24 LUFS 母带垫底、loudnorm 取线性）------虽然它在本轮是动态模式，但逐窗增益差只有 1.16dB，起伏本来就不大。另一条是 LRA=10 的 linear 版：想多留起伏、少一点"被推子推过"的机械感就用它（《玄穹》当年源 LRA 低，LRA=7 一步就拿到 linear；本轮 J2L 源 LRA 9.40，目标得放到 10 才行）。两版都留在归档里。

最后转 mp3 128k CBR + ID3：1.85MB / 115.62s------对照《钧天》1.84MB、《玄穹》1.87MB，体例照旧（title=钧天2.0 artist=羲和Lab，comment 里写 AI 生成声明）。

顺带一条归档坑：当年 ffmpeg 对 flac 做 atrim 大块帧会报 invalid block size，得先转 wav 中转（2026-10-20 归档原话）；本轮 0.43.0 环境直接对 flac 走 atrim 没复现，但换机器、换版本时保不准还来，看到这报错先转 wav。

六、30 秒试听：就在循环点上

试听视频本片 30 秒 ，由 J3（母带后）的最后 16 秒 + 开头 14 秒 拼成：前 16 秒是曲子的收尾，0:16 就是循环缝------听得出来你就赢了，听不出来，说明那条工艺链至少在这个 seed 上是通的。

30 秒试 BGM：一次生成还是分段拼

规格照旧体例：H.264 / yuv420p / 24fps / AAC / faststart，1280×720，右上角烧"AI 生成"角标；波形可视化用 showwaves 中线波形（立体声左右声道分别橙、蓝着色，角标用预渲染 PNG overlay------本机 ffmpeg 没有 drawtext 滤镜，又是一枚"排查半小时、写进文章三秒钟"的坑）。封面两尺寸（544×306 / 1280×720）用 J3 母带的真实波形程序化绘制，同样打标。

七、下一步

第 15 篇起进入成品项目篇：30 秒广告片实战。配乐这一环直接用本篇的链路------30 秒级的短成片，直接一次生成（第 13 篇的热态口径里就是秒级）；要能循环的长曲，才动用"分段 + 循环"。到时候你会看到这三笔账在一个真实企划里怎么算。

互动：你的机器多大内存？ 一段两分钟以内的 BGM，你会选"一次生成"还是"分段 + 循环"？把你觉得最难的接缝场景告诉我（比如"需要严格落到某个小节线"），我按这套链跑给你们看。

口径脚注：本文数字实测于 2026-10-31（mini：Mac mini M5 Pro / 64GB / ComfyUI 0.43.0；《钧天》《玄穹》数字为历史归档（2026-10-20 / 2026-10-28），已单独标注，不与本轮混排同一口径表。J 组时长口径为服务端 running→success（J1 含冷加载，排队时间不计------共享队列共用者自负）；热态口径差异已注明。接缝 z 值与头尾相关为程序化代理指标，不代表"自然与否"；F 组实听结论交由读者在试听视频 0:16 自行裁决（官网连续循环播放是这套工艺的日常实证）。两版母带（dynamic / linear）均随留档。试听视频与封面右上角带"AI 生成"角标；音频为 AI 生成内容（Stable Audio 3 medium）。复现脚本与全部样本随文归档：run14.py / loop14.py / master14.py / analyze14.py。