MusicLM

这是一份写给"完全没接触过音频生成"的读者的精读笔记。全程类比、术语先定义、公式翻成人话。读完你能讲清"为什么给一句话就能生成几分钟连贯的音乐，MusicLM 是怎么把'画音乐'变成'接龙游戏'的"。

一句话讲什么（TL;DR）

给一句文字描述，比如"一段舒缓的小提琴旋律配上失真吉他 riff"，MusicLM 就能生成一段 24kHz、能连贯保持好几分钟的高保真音乐；还能让你哼一段跑调的旋律，它按你的文字风格把它"重新演奏"出来。

所以这一节是想说：这篇论文做的是"文字生成音乐"，而且能长时间连贯，还支持哼唱旋律做条件。

---

这是个什么场景

你在做一个短视频，想配一段"复古 80 年代合成器、节奏轻快、适合日落画面"的背景音乐。你不会作曲，也买不起版权曲库。理想情况是：把这句话打进一个 App，它就生成一段全新的、符合描述的音乐，长度够铺满整个视频，而且从头到尾风格一致、不跑偏。

这件事比"文字生成图片"难得多，难在两点：

• 音频是有时间结构的：一张图是一瞬间，一段音乐是几分钟里节奏、旋律、和声、音色的连续演化。生成时既要每一秒都好听（高保真），又要几分钟里保持连贯（长期结构），这非常难。
• 配对数据极稀缺：文字生成图片有海量"图 + 描述"数据；但"音乐 + 精准文字描述"的数据极少——因为用几个词准确描述一段音乐（旋律、音色、多种乐器、节奏）本身就很难。

MusicLM 要同时攻克"高保真 + 长期连贯 + 数据稀缺"这三关。

所以这一节是想说：目标是文字生成长时间连贯的高保真音乐，难点是时间结构复杂 + 配对数据稀缺。

---

之前的人怎么做的，为什么不够好

• 早期文字生成音频（如 AudioGen、Riffusion）：能从粗略描述生成简单声景或短片段，但仅限"几个声音事件、几秒钟"，做不出有长期结构、多声部的音乐片段。Riffusion 甚至是把音乐画成频谱图再用图像扩散生成，间接且受限。
• 符号音乐生成（MIDI）：生成音符序列，但那不是真实音频（没有音色、演奏细节），且需要 MIDI 数据。
• 商业工具（如 Mubert）：靠拼接预制片段，灵活性和保真度有限。
• 纯音频语言模型 AudioLM：能生成高保真、长期连贯的音频（语音或钢琴），但它不接受文字条件——你没法告诉它"生成什么"。
• 共同短板：要么不够长/不够真，要么无法用文字控制，要么被配对数据卡死。

所以这一节是想说：以前要么生成得短而糙，要么能长能真但没法用文字指挥，MusicLM 要把两者合起来。

---

这篇论文的关键想法

MusicLM 站在两个前作的肩膀上，做了一个漂亮的组合：

第一，把"生成音乐"重写成"接龙游戏"（AudioLM 的思路）。 不直接生成波形，而是先把音频压成一串离散的"音频词"（token），然后像语言模型写句子那样，一个 token 接一个 token 地生成。这样长期连贯性就变成了"语言模型擅长的长序列建模"问题。而且分成粗到细的多层 token（先定大结构，再补细节），兼顾长期结构和高保真。

第二，用 MuLan 绕开"配对数据稀缺"（本文关键招）。 MuLan 是一个"音乐-文字联合嵌入"模型（类似音乐界的 CLIP）：它把音乐和描述它的文字都投到同一个向量空间，配对的音乐和文字向量互相靠近。有了它，训练时可以只用音频——用"从音频算出的 MuLan 向量"当条件；推理时才用文字——用"从文字算出的 MuLan 向量"当条件。因为两者在同一空间，训练时看音频、推理时听文字，模型也能对上。这就彻底绕开了"必须有海量音乐-文字配对"的死结。

第三，顺手解决评测荒：发布 MusicCaps——5.5k 条由专业音乐人手写描述的音乐-文字对，作为文字生成音乐的评测集。

所以这一节是想说：核心是"把音乐生成变成 token 接龙（AudioLM）+ 用 MuLan 让训练只需音频、推理才用文字"，一举解决连贯性和数据稀缺。

---

它分几步做的（方法）

MusicLM 的生成是一个分层的"序列到序列"过程，涉及三种 token 和三个模型（MuLan、w2v-BERT、SoundStream）。逐块按"输入 → 处理 → 输出"讲。

1. 三种"音频词"：语义 token、声学 token、MuLan token

先认识三种把音频/文字变成离散符号的方式，它们是接龙的基本单位。

• SoundStream 声学 token（acoustic token）：SoundStream 是一个神经音频编解码器（neural audio codec）——把波形压成一串离散码、又能还原回高保真波形。它的 token 管"听起来的细节和保真度"。
• w2v-BERT 语义 token（semantic token）：w2v-BERT 是一个自监督音频表示模型，它的 token 抓的是"音乐的长期结构和内容"（旋律走向、乐句结构），管"整体连不连贯"。
• MuLan token：MuLan 把音乐或文字映射到同一嵌入空间，量化后得到的 token 当作"这段音乐/这句话大概是什么"的高层条件。

token（离散符号）：把连续信号切成一格一格、每格给个编号，就像把音频变成一串"词"。语言模型擅长处理这种离散序列。

所以这一节是想说：MusicLM 用三套 token 分工——MuLan 管"是什么"、语义 token 管"结构连贯"、声学 token 管"听感保真"。

2. 训练：只用音频，靠 MuLan 音频向量当条件

输入。 大量无标注的音乐音频（不需要配对文字）。

处理。 对每段音频，用 MuLan 算出它的音频嵌入并量化成 MuLan token。训练目标是让模型学会：给定 MuLan token（高层"是什么"），生成对应的语义 token（结构），再由语义 token 生成声学 token（细节）。因为训练时用的是"从音频算的 MuLan 向量"，所以完全不需要文字标注——这正是绕开数据稀缺的关键。

输出。 一个学会了"从高层条件生成结构、再生成细节"的分层生成模型。

所以这一节是想说：训练阶段只喂音频，用 MuLan 音频向量当条件，避免了对海量音乐-文字配对的依赖。

3. 推理：把文字变成 MuLan 向量，接龙生成音乐

输入。 用户的文字描述（如"enchanting jazz song with a memorable saxophone solo"）。

处理（分层接龙）。

1. 用 MuLan 把文字算成 MuLan 向量 → MuLan token。因为文字和音频共享空间，这个 token 和训练时的"音频 MuLan token"性质一致，模型能无缝接受。
2. 第一阶段（语义建模）：由 MuLan token 生成语义 token——先定下音乐的长期结构和走向。
3. 第二阶段（声学建模）：由 MuLan token + 语义 token 生成 SoundStream 声学 token——补上音色、保真细节。
4. 用 SoundStream 解码器把声学 token 还原成 24kHz 波形。

输出。 一段符合文字描述、24kHz、可连贯几分钟（论文展示可达 5 分钟）的音乐。

所以这一节是想说：推理时把文字投进 MuLan 空间当条件，然后"先结构后细节"两级接龙，最后解码成高保真长音乐。

4. 旋律条件：哼一段，按文字风格重演

输入。 一段哼唱/口哨旋律音频 + 一句文字描述。

处理。 MusicLM 额外支持把"旋律"也作为条件——从哼唱里提取旋律信息，再让生成的音乐既跟随这个旋律、又渲染成文字描述的风格（比如你哼一段《欢乐颂》，文字说"用电子舞曲风格"，它就把《欢乐颂》做成 EDM）。

输出。 跟随你哼的旋律、但穿上文字所述风格的音乐。

下面用 ASCII 图把生成流程画出来：

   训练(只用音频):
       音乐音频 ──MuLan──► MuLan token ──► [学: →语义token →声学token]

   推理(用文字):
       文字描述 ──MuLan──► MuLan token
                              │
                              ▼  第一级(语义)
                        语义 token(定长期结构)
                              │
                              ▼  第二级(声学)
                     SoundStream 声学 token(补音色细节)
                              │
                              ▼  解码
                        24kHz 音乐(可达数分钟)

再用一张 ASCII 图看"三种 token 各管什么"：

   MuLan token   ──►  "这段大概是什么"(整体语义/风格)     粗
   语义 token    ──►  旋律走向 / 乐句结构 / 长期连贯      中
   声学 token    ──►  音色 / 保真 / 演奏细节              细

所以这一整节是想说：MusicLM = 三种 token 分工 + MuLan 解耦训练与推理 + 分层接龙生成 + 可选旋律条件，合起来实现文字生成长连贯音乐。

---

关键数字（What works）

数字来自论文（arXiv:2301.11325）；主观/客观评测的具体分数属正文表格，标注"需读原文"。

项目	数值/结论	说明
采样率	24 kHz	高保真
连贯时长	可达 5 分钟	长期结构保持
数据招式	训练只用音频，推理才用文字	靠 MuLan 共享空间
依赖前作	AudioLM（生成）+ MuLan（条件）	组合创新
声学编解码	SoundStream	波形↔离散码
语义表示	w2v-BERT	长期结构
MusicCaps 数据集	5.5k 条 音乐-文字对	专业音乐人手写，公开发布
对比基线	优于 Mubert、Riffusion	质量与文字契合度
记忆化研究	生成序列与训练集显著不同	降低抄袭风险

三个要点：第一，24kHz + 5 分钟连贯是当时文字生成音乐的巨大跨越（此前多是几秒声景）；第二，MuLan 让训练无需配对文字是全篇最聪明的一招，直接化解了数据荒；第三，**发布 MusicCaps（5.5k 专业标注）**给整个领域立了评测标准，是长期贡献。

所以这一节是想说：高保真长音乐、无需配对数据的训练招式、以及公开评测集，是它的三大硬贡献。

---

实验结果说明了什么

论文通过客观指标和人工评测证明：

• 质量与契合度都更好：相比 Mubert、Riffusion 等，MusicLM 生成的音乐在音频质量和"与文字描述的契合度"上都更优，验证了 AudioLM + MuLan 这套组合的有效性。
• 能处理复杂描述：对"90 年代柏林 techno、低音强劲踢鼓"这类相当具体的描述也能生成合理音乐，说明 MuLan 条件传递的信息足够丰富。
• 支持超越文字的条件：旋律（哼唱/口哨）条件生成成功，说明框架有扩展性。
• 记忆化风险受控：作者专门研究了模型会不会"背下训练集原样吐出来"，发现用 MuLan 条件时生成的 token 序列与训练集显著不同，降低了直接抄袭的风险（但不等于完全无风险）。

所以这一节是想说：实验证明它质量高、能理解复杂描述、可扩展到旋律条件，且认真评估了抄袭风险。

---

你应该懂的几个新词

• token（离散音频符号）：把连续音频切格编号变成一串"词"，让语言模型式建模成为可能。
• neural audio codec（神经音频编解码器）：如 SoundStream，把波形压成离散码又能高保真还原。
• SoundStream 声学 token：管音色和保真细节的 token。
• w2v-BERT 语义 token：管音乐长期结构和内容的 token。
• MuLan：音乐-文字联合嵌入模型（音乐界的 CLIP），把音乐和文字投到同一空间。
• AudioLM：把音频生成当语言建模的框架，MusicLM 的生成骨架来自它。
• hierarchical / coarse-to-fine（分层、粗到细）：先定大结构再补细节的生成方式，兼顾长期连贯和保真。
• MusicCaps：本文发布的 5.5k 条专业标注音乐-文字评测集。

所以这一节是想说：token、codec、MuLan、AudioLM 是理解本篇的四块基石，也是听觉生成领域的通用词汇。

---

它有什么搞不定的

• 歌词/人声语义不行：MusicLM 能生成"像人声的声音"，但唱不出清晰、正确的歌词，人声更多是当音色处理。
• 细粒度控制有限：文字能控制大风格，但很难精确指定"第 30 秒转到 D 大调、加一段 4 小节的鼓 fill"这种细节。
• 配对数据稀缺仍在底层：MuLan 绕开了对生成模型的配对需求，但 MuLan 本身的训练和评测仍受"音乐-文字数据少"的限制。
• 记忆化/版权风险：虽做了研究、风险较低，但从大量受版权音乐学习，仍有法律与伦理争议。
• 不开源模型：Google 当时未公开模型权重，复现门槛高（仅公开了 MusicCaps 数据集）。

所以这一节是想说：它在歌词、细粒度控制、数据底层限制、版权、开放性上都有明显边界。

---

它和别的几篇是什么关系

• 直接前作：AudioLM（生成骨架）、MuLan（文字条件）、SoundStream（声学编解码）、w2v-BERT（语义表示）——MusicLM 是这几块的集大成组合。
• 图像界类比：思路上呼应文字生成图像（DALL·E、Imagen、Parti），但音频的时间结构让它更难。
• 同代/后续对手：Meta 的 MusicGen（开源、单阶段 Transformer）、Stable Audio（潜在扩散）是后来的重要竞品，各走不同技术路线。
• 听觉栈邻居：Whisper（识别）、EnCodec/SoundStream（编解码）、AudioPaLM（语音-文本统一）都是同一听觉生态里的组件。

所以这一节是想说：MusicLM 是 Google 听觉栈（AudioLM/MuLan/SoundStream/w2v-BERT）的组合杰作，也是文字生成音乐这条线的里程碑。

---

和本导读的关系

本笔记对应导读 Ch20: 听觉智能。Ch20 覆盖识别、编码、生成的整条听觉栈。MusicLM 是"生成"这一支的代表，它示范了一个反复出现的强大范式：把连续信号离散成 token，再用语言模型式的接龙来生成。这个"离散化 + 序列建模"的思想在语音（AudioLM）、音乐（MusicLM）、乃至动作（后面的 VLA、FAST）里都在用。读完本篇再看同章的 encodec/soundstream（提供 token 的编解码器）、audiolm（生成骨架），能理解这套 token 生成范式的来龙去脉。

所以这一节是想说：把 MusicLM 放进 Ch20，它是"离散 token + 语言模型生成"这一通用范式在音乐上的旗舰案例。

---

思考题

Q1：为什么把音频"离散成 token 再接龙"比"直接生成波形"更容易做到长期连贯？

提示

语言模型天生擅长长序列的依赖建模。离散 token 把音频变成了它熟悉的形式，长期结构就交给了它最擅长的机制。

Q2：MuLan 为什么能让"训练只用音频、推理才用文字"？关键前提是什么？

提示

前提是音乐和文字被投到同一个嵌入空间且配对的靠得近。这样"音频算的向量"和"文字算的向量"性质一致，可以互换当条件。

Q3：MusicLM 用了三种 token（MuLan / 语义 / 声学），如果只用声学 token 会怎样？

提示

只有细节 token 缺乏长期结构引导，容易生成"每秒都好听但整体散乱"的音乐。想想为什么要分粗到细。

Q4：为什么"文字生成音乐"比"文字生成图片"更难？至少说两点。

提示

一是音频有时间维度（要长期连贯），二是音乐-文字配对数据远比图-文少、且更难准确描述。

Q5：作者为什么要专门研究"记忆化"？这对生成模型意味着什么？

提示

若模型把训练里的受版权音乐原样背出来，会有抄袭/侵权问题。研究它是为了评估和降低这种风险。

Q6：发布 MusicCaps（而不发布模型）这个选择，对领域有什么影响？

提示

评测集让别人能在同一尺子上比拼，推动后续工作（如 MusicGen）；不发模型则限制了直接复现。想想开放的两难。

Q7：这套"离散 token + 语言模型生成"的范式，除了音乐，你还能想到哪些信号可以照搬？

提示

语音、视频、机器人动作（FAST 就把动作离散成 token）。想想任何"连续序列"都可以被离散再接龙。

---

一些好奇心问答（FAQ）

Q：它能生成带歌词的歌吗？

不能生成清晰正确的歌词，人声更像一种音色/氛围。清晰演唱是后续工作（如带歌词的音乐生成）的方向。

Q：为什么用 24kHz 而不是常见的 44.1kHz？

24kHz 已经能覆盖音乐的主要频率、算是高保真，同时在生成难度和计算成本之间取了平衡。

Q：我能自己跑 MusicLM 吗？

官方没开放权重。想动手可以用开源的 MusicGen（Meta）或 Stable Audio 等替代，思路可参照本篇。

Q：MuLan 和 CLIP 是一回事吗？

思想一样（跨模态联合嵌入、对比学习），CLIP 对齐图-文，MuLan 对齐音乐-文。可以把 MuLan 理解成"音乐版 CLIP"。

所以这一节是想说：它是研究里程碑而非可直接下载的产品，想动手就看开源替代品。

---

如果你想再深入

1. 生成骨架：AudioLM — 理解"音频即语言建模"的原始框架。
2. 文字条件：MuLan — 理解跨模态嵌入如何绕开配对数据。
3. 编解码：SoundStream / EnCodec — 理解波形与离散 token 的互转。
4. 开源竞品：MusicGen / Stable Audio — 看不同技术路线（单阶段 Transformer / 潜在扩散）。
5. 图像类比：Parti / Imagen — 对照文字生成图像的思路。

所以这一节是想说：把 SoundStream → AudioLM/MuLan → MusicLM → MusicGen 串起来，能看清文字生成音乐的技术演进。

---

原文信息

• 标题：MusicLM: Generating Music From Text
• 作者：Andrea Agostinelli, Timo I. Denk, Zalan Borsos, Jesse Engel, Mauro Verzetti, Antoine Caillon, Qingqing Huang, Aren Jansen, Adam Roberts, Marco Tagliasacchi, Matt Sharifi, Neil Zeghidour, Christian Frank
• 发表：arXiv 2023（Google Research）
• arXiv：https://arxiv.org/abs/2301.11325

@article{agostinelli2023musiclm,
  title   = {MusicLM: Generating Music From Text},
  author  = {Agostinelli, Andrea and Denk, Timo I. and Borsos, Zalan and Engel, Jesse and Verzetti, Mauro and Caillon, Antoine and Huang, Qingqing and Jansen, Aren and Roberts, Adam and Tagliasacchi, Marco and Sharifi, Matt and Zeghidour, Neil and Frank, Christian},
  journal = {arXiv preprint arXiv:2301.11325},
  year    = {2023},
  url     = {https://arxiv.org/abs/2301.11325}
}

◼

@online{eai_musiclm_2026,
  title       = {(readable note) MusicLM},
  author      = {Xun, Jason},
  year        = {2026},
  note        = {Note on a 2023 paper},
  howpublished = {\url{https://estelledc.github.io/embodied-ai-reading-station/papers/musiclm/}},
  organization = {Embodied AI: Zero to One}
}