★ FEATURED ARTICLE 1. 从“先有谱还是先有声”这个老问题说起做音乐生成模型的人大概都绕不开一个根本性的分歧一首歌到底是先有谱子还是先有声音传统音乐工业的流程很明确——先写谱、再编曲、再录音、最后混音谱面是骨架音频是血肉。但过去几年主流的音频生成模型走的是另一条路直接端到端地“吐”出一段波形谱面信息被隐式地编码在模型权重里你没法拿出来看也没法改。这个分歧带来的实际后果非常具体。假设你用某个音频生成模型做了一首歌副歌旋律很抓耳但第二段的和弦走向不对你想改。对不起你只能重新生成一遍然后祈祷这次能撞上你想要的结果。你没法像改MIDI那样把某个小节的和弦从Am换成F因为模型压根没给你一个可编辑的中间表示。YuE2这篇工作要解决的就是这个问题。它的核心主张用一句话概括让模型先写出可读的谱面符号再基于谱面去合成音频。这听起来像是把传统音乐制作流程搬进了生成模型里但实现起来远没有这么简单——符号和音频是两个完全不同的模态前者是离散的、结构化的、有明确语法规则的后者是连续的、高维的、感知驱动的。要把两者统一在一个框架里需要解决表示对齐、训练目标设计、推理效率等一系列问题。我读这篇文献的时候最关心的不是它又刷了多少个指标而是它到底怎么处理“谱面”和“音频”之间的鸿沟。因为这个问题如果解决不好所谓的“统一”就只是把两个独立模型串起来中间加个转换层本质上还是各干各的。下面我会从几个角度拆解这篇工作的设计思路结合我自己在音乐信息检索和生成模型方面的一些实践经验聊聊它哪些地方做得聪明哪些地方还有坑。2. 符号表示的选择为什么是“类谱面”而不是标准MIDI2.1 标准MIDI的局限与替代方案YuE2没有直接用标准MIDI作为中间表示这个选择值得细说。MIDI的问题在于它太“薄”了——它只记录音高、时值、力度这些离散事件丢失了演奏法、音色变化、表情细节等大量信息。如果你用MIDI作为中间层从MIDI到音频的合成阶段就需要一个非常强的声学模型来“脑补”那些缺失的细节这实际上把大部分生成压力推到了第二阶段。更麻烦的是MIDI的量化特性会让模型在生成阶段被迫做离散化决策。比如一个滑音在MIDI里要么被量化成两个半音要么用弯音轮事件近似但弯音轮的分辨率是128级对于细腻的连续音高变化来说太粗糙了。YuE2采用的是一种更灵活的符号表示我推测它可能结合了事件序列和连续参数的混合编码——音高、时值这类离散信息用token表示而颤音深度、滑音曲线这类连续信息用嵌入向量表示。这样既保留了符号的可编辑性又不会在量化阶段丢失太多表现力。2.2 符号粒度与生成可控性的权衡符号表示的粒度选择是个典型的权衡问题。粒度太粗比如只记录和弦进行那生成阶段的可控性就很有限你只能控制大致的和声走向具体旋律怎么走还是模型说了算。粒度太细比如记录每个音符的精确起始时间和力度值那符号序列会变得非常长生成效率急剧下降而且模型很容易过拟合到训练数据的具体演奏细节上。YuE2的做法看起来是采用了分层表示在较粗的时间尺度上比如每小节或每拍记录和声、节奏型等结构信息在较细的尺度上记录旋律音符和装饰音。这种分层设计的好处是你可以在不同层级上分别做条件控制。比如你想让副歌更“燃”一点可以在结构层把和弦从小三和弦换成大三和弦同时保持旋律层的音符不变。这种操作在端到端音频生成模型里是做不到的。2.3 符号序列的编码方式对训练稳定性的影响符号序列的编码方式直接影响训练稳定性。如果直接把符号事件按时间顺序排成一个长序列用标准的自回归Transformer去建模会遇到一个经典问题音乐中的长程依赖非常强副歌和主歌之间可能隔了几十秒但它们在和声上是有呼应的。标准的位置编码在这么长的序列上会衰减得很厉害模型很难学到跨段落的依赖关系。我注意到YuE2可能在编码里加入了显式的结构标记比如段落边界token、重复标记等。这些标记让模型能够“知道”当前处于哪个段落以及这个段落和之前哪个段落是重复关系。这种设计在符号音乐生成里其实有先例但把它和音频合成统一在一个框架里就需要在音频端也做对应的结构对齐。具体怎么对齐的文献里应该有一些细节我读的时候觉得这部分是整篇工作技术含量最高的地方之一。3. 两阶段训练先教模型“读谱”再教它“演奏”3.1 第一阶段符号生成模型的训练目标设计第一阶段的训练目标很明确让模型学会生成合理的符号序列。但“合理”的定义需要仔细设计。如果只用标准的交叉熵损失模型会倾向于生成高频出现的音符组合导致输出非常“安全”但缺乏创意。如果加入对抗损失又容易训练不稳定生成出语法上合法但音乐上莫名其妙的东西。YuE2可能采用了多任务学习的策略主任务是预测下一个符号token辅助任务包括和声一致性预测、节奏规整度预测等。这些辅助任务的作用是给模型提供额外的监督信号让它在学习局部转移概率的同时也学到全局的音乐结构约束。这种设计在自然语言处理里很常见比如BERT的下一句预测任务但在音乐生成里需要根据音乐特有的结构来设计辅助任务。3.2 第二阶段从符号到音频的声学模型第二阶段的声学模型是整个流程里计算量最大的部分。从符号序列到音频波形中间要经过音高映射、音色合成、混响处理等多个步骤。传统方法会用基于物理建模或采样合成的声源模型但这类方法对演奏表情的建模能力有限生成出来的音频往往听起来很“机械”。YuE2大概率用了基于神经网络的声码器或扩散模型来做音频合成。扩散模型的好处是生成质量高能够捕捉到细腻的音色变化和空间感但推理速度慢尤其是生成长序列的时候。我猜测他们可能用了某种加速采样策略比如DDIM或一致性模型来把推理步数压到可接受的范围内。另一个可能是用了流匹配flow matching的方法在训练稳定性和采样效率之间取得更好的平衡。3.3 两阶段之间的对齐避免“谱面好看但演奏难听”两阶段训练最大的风险是阶段之间的不对齐。符号生成模型可能生成出谱面上很合理、但声学模型很难合成好的序列。比如一个包含大量快速大跳的旋律在谱面上看没问题但声学模型可能因为训练数据里这类片段很少合成出来的音质很差。解决这个问题有几种思路。一种是在第二阶段训练时把第一阶段的生成结果也作为输入的一部分让声学模型学会处理这些“模型生成”的符号序列而不是只处理真实数据里的符号序列。另一种是在两阶段之间加一个可微的接口让音频端的损失能够回传到符号端实现端到端的微调。YuE2具体用了哪种方法文献里应该有说明我读的时候觉得这部分的设计直接决定了最终生成质量的上限。4. 推理阶段的实操细节从输入到成品的完整链路4.1 输入格式与预处理假设你现在要生成一首完整的歌曲输入可能是一段歌词、一个和弦进行、或者一段参考旋律。YuE2的推理流程大概是这样首先把输入编码成符号序列的初始状态然后符号生成模型自回归地补全整个序列最后声学模型把符号序列渲染成音频。预处理阶段有几个容易踩坑的地方。第一是歌词和旋律的对齐。如果你输入的歌词有多个音节对应一个音符的情况比如中文里的一个字对应多个音高变化需要有一个明确的映射规则。第二是调性和节拍的归一化。如果输入的和弦进行是C大调的但模型训练数据里大部分是G大调可能需要做移调处理否则生成质量会受影响。4.2 生成过程中的可控性调节生成过程中最实用的可控性调节手段是温度参数和top-k采样。温度高的时候模型更愿意尝试低频的符号组合生成结果更有创意但可能不连贯温度低的时候输出更保守更接近训练数据里的常见模式。我的经验是符号生成阶段用中等温度0.8-1.0声学合成阶段用较低的温度0.5-0.7这样能在创意和稳定性之间取得比较好的平衡。另一个重要的控制维度是结构约束。你可以在生成过程中强制模型在某些位置输出特定的符号比如指定副歌的第一小节必须用某个和弦。这种硬约束在自回归生成里需要特殊的解码策略比如在每一步对logits做mask把不允许的token概率置零。YuE2应该提供了类似的接口具体怎么用需要看文档。4.3 后处理与编辑生成出来的音频通常需要一些后处理才能达到可发布的质量。最基本的包括响度归一化、去直流偏移、淡入淡出等。如果生成结果里有明显的瑕疵比如某个音符的起音太突兀可以在符号层面做微调然后重新渲染那一段而不是对整个音频做修复。这正是符号中间表示的优势所在——你可以在一个可解释的层面上做精确编辑。我自己的习惯是生成完先听一遍标记出有问题的段落然后回到符号序列里找到对应的位置调整音符的时值或力度再重新渲染。这个过程比在音频波形上做修复要高效得多而且不会引入额外的伪影。5. 和现有方案的对比YuE2到底解决了什么别人没解决的问题5.1 与纯音频生成模型的对比纯音频生成模型比如基于扩散或自回归的波形生成模型最大的优势是端到端不需要中间表示训练流程简单。但它的可控性很差你很难对生成结果做精细的编辑。而且纯音频模型通常需要大量的训练数据因为模型要同时学习音乐结构、和声规则、音色合成等多个层面的知识这些知识全部压缩在模型参数里学习效率很低。YuE2通过引入符号中间层把“音乐结构”和“声学细节”解耦开来。符号模型只需要学习音乐的结构规律声学模型只需要学习符号到音频的映射关系。这种解耦让两个模型都可以用更少的数据和更小的参数量达到更好的效果。代价是推理流程变复杂了需要两阶段串联而且两阶段之间的对齐需要额外处理。5.2 与符号音乐生成模型的对比传统的符号音乐生成模型比如基于LSTM或Transformer的MIDI生成模型只输出符号不输出音频。你要听到声音还得自己挂一个音源。这类模型的优势是生成速度快、可控性强但最终的音乐质量取决于你用的音源模型本身不负责音质。YuE2把声学模型也包进来了这意味着它可以直接输出可听的音频不需要外部音源。但这也意味着它要同时承担符号生成和音频合成的双重任务训练和推理的复杂度都更高。从文献里的实验结果看它在符号层面的生成质量和专门的符号生成模型相当在音频层面的质量也接近专门的声学模型这种“两不误”的表现是它最大的卖点。5.3 统一框架的代价与收益统一框架的代价主要体现在工程复杂度上。你需要维护两套模型、两套训练流程、一套对齐机制。推理的时候需要管理两个阶段之间的数据流任何一个阶段出问题都会影响最终结果。调试的时候也更麻烦因为错误可能来自符号端、音频端、或者两者之间的接口。但收益也是明显的。最直接的是可控性——你可以在符号层面做编辑然后重新渲染不需要重新生成整个音频。其次是可解释性——符号序列是人类可读的你可以直接看到模型生成了什么和弦、什么旋律而不是面对一堆看不懂的隐变量。最后是数据效率——解耦之后每个模型只需要学习自己擅长的部分整体上需要的数据量比端到端模型少。6. 实际使用中的坑与经验6.1 符号序列的“合法但不合理”问题符号生成模型最容易出现的问题是生成出语法上合法但音乐上不合理的序列。比如一个和弦进行从C大调突然跳到升F大调在符号层面没有任何语法错误但听起来就是不对劲。这类问题很难通过增加训练数据来解决因为“音乐合理性”本身就是一个模糊的概念不同风格、不同时期的音乐对“合理”的定义都不一样。我的经验是在推理阶段加入一些基于规则的约束比如限制调性变化的范围、强制和弦进行遵循某些常见的模式。这些规则不需要很复杂但能过滤掉大部分明显不合理的生成结果。YuE2可能提供了一些内置的约束选项具体怎么配置需要根据你的目标风格来调整。6.2 声学模型的音色一致性声学模型在生成长序列时容易出现音色不一致的问题。比如前30秒的钢琴音色偏亮后30秒变得偏暗。这是因为模型在自回归生成过程中误差会逐渐累积导致音色漂移。解决这个问题的一个方法是使用全局的音色嵌入在生成每一帧时都把同一个音色向量作为条件输入。另一个方法是分段生成然后做音色对齐后再拼接。我在实际使用中发现音色一致性问题在生成超过1分钟的音频时会变得很明显。如果你的应用场景需要生成长曲建议在声学模型端加入显式的音色控制机制而不是完全依赖模型自己保持一致性。6.3 两阶段推理的延迟优化两阶段推理的延迟是实际部署时的一个大问题。符号生成阶段通常很快因为序列长度有限模型参数量也不大。但声学合成阶段很慢尤其是用扩散模型的时候生成长音频可能需要几十秒甚至几分钟。如果你的应用需要实时或近实时的响应这个延迟是不可接受的。优化延迟有几个方向。一是用更快的声码器比如基于GAN的声码器推理速度比扩散模型快一个数量级但音质可能略有下降。二是用流式生成把长音频切成短片段逐段生成这样用户可以在生成过程中就开始播放而不是等全部生成完。三是用模型蒸馏把大模型的能力压缩到小模型里牺牲一点音质换速度。具体选哪种方案取决于你的应用对音质和延迟的容忍度。7. 这个方向后续还能怎么玩符号和音频的统一框架打开了很多有意思的应用场景。比如交互式音乐创作——你可以在符号层面实时编辑声学模型在后台持续渲染你听到的永远是编辑后的结果。这种交互模式比传统的“生成-试听-重新生成”循环要高效得多。另一个方向是个性化音色合成。如果你有一个目标歌手的音色样本可以用它来条件化声学模型让生成的音频带有那个歌手的音色特征。符号层保持不变只换声学模型的条件输入就能实现“同一首歌不同人唱”的效果。这在虚拟歌手、音乐教育等场景里很有用。还有一个方向是跨模态检索。符号序列和音频波形在统一框架里有了对齐的表示你可以用一段音频去检索相似的符号序列或者反过来。这在音乐推荐、版权检测等场景里有潜在的应用价值。从文献到落地还有不少距离但YuE2至少指出了一个可行的方向与其让模型在隐空间里同时学习结构和声学不如显式地把两者分开用符号作为桥梁。这个思路在语音合成里已经有成功的先例在音乐生成里能不能走通还需要更多的实验和工程验证。我个人的判断是这条路在可控性和可解释性上的优势是端到端模型很难替代的尤其是在专业音乐制作场景里创作者需要的是可编辑、可调整的工具而不是一个黑箱。
阅读完成 · 觉得有帮助？
