认识 Music Understanding:设备端音频分析
在 WWDC 2026 上,Apple 的 Final Cut Pro 团队推出了两项建立在同一个框架之上的功能:一项节拍检测功能,能呈现歌曲的节拍网格,让剪辑者得以将剪接点对齐到小节与节拍;以及 iPad 上的一项蒙太奇功能,可自动将片段与音乐同步。1两者皆运行于 Music Understanding 之上,这是一个全新的框架,能将歌曲的音乐智能(调性、节奏、结构、律动、乐器活动与响度)交到您手中,而您完全不必懂得任何信号处理或机器学习的知识。它完全在设备端运行,因此您所分析的音频得以保持私密,并可离线工作。1本文将以边读边建的方式走过这个框架:六大分析领域、MusicUnderstandingSession 如何产生这些结果,以及那个让音频反应式视觉效果得以实现的流式响度 AsyncSequence。
重点摘要
- Music Understanding 在设备端分析歌曲的六大领域(调性、节奏、结构、律动、乐器活动与响度),完全不需要信号处理或机器学习的专业知识。1
- 您可从
AVAsset或自定义的音频提供者创建MusicUnderstandingSession,接着调用analyze()获取全部结果,或调用analyze(for:)锁定特定类型、跳过不必要的运算。1 - 结果会以
SessionResult结构返回,其中每项特征都是一个 optional 字段;一般的analyze()会填满全部,而锁定式的analyze(for:)则让其余字段保持nil。1 - 两种具时间感知的类型贯穿整个 API:
TimedValue将一个值与一个CMTime配对,而RangedValue则将一个值与一个CMTimeRange配对。1 MusicUnderstandingSession还提供一套流式响度 API,每分析 100 毫秒的音频便通过AsyncSequence传递数值,这正是驱动实时音频反应式动画的基础。1
为何设备端的音乐智能如此重要
来自 Apple 计算音乐团队的 Conner 从 1:39 开始逐一介绍该框架的六大分析领域。
这项定位既聚焦又坦诚:该框架「替您处理所有的信号处理与模型推理,因此您无需具备任何信号处理或机器学习的专业知识便能使用它」。1这恰好免去了音频分析中大多数应用程序开发者从来不想自己扛起的那一块。检测节拍、将歌曲切分为副歌与主歌,或是测量感知响度,过去都意味着要么授权第三方引擎,要么亲手打造一条 DSP 管线。
在设备端运行也改变了隐私这笔账。由于该框架「完全在设备端运行,您所分析的音频得以保持私密,并可离线工作」。1歌曲为了分析而从不离开手机,而且分析在毫无信号的飞机上也能进行。对于一款依节拍整理曲库的 DJ 应用程序,或是一套要将剪接点对齐节拍的视频剪辑工具而言,无网络依赖加上音频不离开设备,这样的组合正是实际中的关键突破。
Apple 将这六大领域定位为一首歌的构成元件。节奏是脉动,由一个个节拍推动,逐步累积成小节;一分钟内的节拍数即为每分钟节拍数,也就是 bpm。1小节组成乐句(音乐的句子),乐句结合为段落,段落再构筑出副歌、主歌、前奏或桥段等区段。1鼓、贝斯或人声等乐器,会在不同时刻、以不同强度,围绕着一组共同的音符演奏,而这组音符称为调性。1一首歌可以维持稳定的 bpm,而不同部分却感觉较慢或较快,Apple 将此称为律动(pace);同时歌曲在某些段落会比其他段落更为响亮。1这六个概念与框架的结果类型一一对应。
会话:一个对象,两种询问方式
应用程序通过 MusicUnderstandingSession 交互,并以「AVAsset 或自定义音频提供者」加以初始化。1若要执行分析,您调用 analyze 并等候结果。默认行为是分析所有类型,而 Apple 明确点出了性能的关键杠杆:「为求最高性能,您可以指定感兴趣的分析类型,以避免不必要的运算。」1只运算您要呈现的内容,正是反应灵敏的工具与每次加载都卡顿的工具之间的差别。
示例应用程序 Music Understanding Lab 完整演示了文件路径的处理。一个 SwiftUI 的 fileImporter 选取一首歌并返回其 URL,而这个 URL 便成为一个 AVURLAsset。Apple 特别指出有一项设置至关重要:将 PreferPreciseDurationAndTimingKey 设为 true,「以确保得到最准确的结果」。1接着您从该 asset 创建会话,调用 analyze 并等候会话结果返回。
这些结果会落在一个 SessionResult 结构中,其中「Music Understanding 分析的每项特征都拥有自己的结果字段。这些全都是 optional。」1两个入口点的差别在于它们会填入哪些内容。一般的 analyze() API 会让所有结果都可获取;锁定式的 analyze(for:) API 只返回您所请求的结果,而「其余的将会是 nil」。1因此,optional 的特性并非 API 设计上的偶然,而是框架用来告诉您它实际做了哪些工作的方式。
有两种类型贯穿整个框架,用来为一个值附上时间信息。TimedValue 将一个值与一个 CMTime(单一瞬间)相关联,而 RangedValue 则将一个 CMTimeRange(一段区间)与一个值相关联。1底下几乎每一项结果都以这两种形态之一来表达,因此只要学会这两者一次,便能在所有六大领域中受益。
逐一走过六项结果
调性。 对于调性分析,框架会返回一个 KeyResult 结构,它「包含一个区间的数组,通过 RangedValue 将 KeySignature 映射到特定的时间区间」。1一个 KeySignature 含有一个主音(tonic)与一个调式(mode)。主音「可以是任何一个标准的半音音高」,代表歌曲所环绕构建的根音(例如 C 或 G);调式「不是大调就是小调」。1由于结果是区间的数组而非单一数值,这套 API 也能容纳在中途转调的歌曲。
节奏。 针对节奏的分析会产出一个 RhythmResult。这个结构提供「每个节拍与每个小节的时间戳,以 CMTime 的数组呈现」,并通过 beatsPerMinute 给出整体的全局速度。1有一个细节对实时 UI 很重要:beatsPerMinute 是 optional,「因为若框架尚未处理足够的音频以找出至少两个节拍,bpm 便会被设为 nil」。1测量一段间隔需要两个节拍,因此那个 nil 正是框架拒绝妄加揣测的表现。
结构。 请求结构分析会返回一个带有三项属性的 StructureResult,「分别对应 sections、segments 与 phrases」,而每一项您都会得到一个 CMTimeRanges 的数组。1这三个层级彼此嵌套:一个区段由一个或多个段落构成,而每个段落又由乐句构成。1正是这套层级,让剪辑者得以将剪接点吸附到副歌的边界,而非任意的时间戳。
律动(pace)。 律动「告诉您音乐对聆听者而言感觉有多快」,较有活力的部分所带的数值会高于较缓慢的部分。1请求它会返回一个 PaceResult,这是一个带有「单一属性、其中含有一个 ranged value 数组」的结构。1律动有别于 bpm:速度可以维持稳定,而所感受到的能量却起起伏伏。
乐器活动。 请求乐器活动会返回一个带有两项属性的 InstrumentActivityResult,一项对应区间(ranges),一项对应活动(activity)。1Ranges API「提供一个字典,将每个 Instrument 映射到」一个逐乐器的值(逐字稿在说出该值的类型之前便中断了),而 Apple 将 ranges 定位为当「您只想知道某项乐器是否存在」时的恰当选择。1activity 属性则携带更多细节:它「将一项乐器映射到一个 Floats 的 TimedValue」,而这些数值「表达一项乐器随时间推移演奏得有多强烈」。1Apple 称这项活动结果是「驱动音频反应式动画的绝佳来源」,因为逐乐器的逐瞬间强度,正是可视化工具想要绑定的对象。1
响度。 框架以 Loudness Units Full Scale(LUFS)测量响度,这是「用于建模人耳如何感知音量的业界标准」。1请求响度分析会产生一个 LoudnessResult 结构,它支持 integrated、momentary 与 shortTerm 三种响度。1Integrated 是代表音频整体响度的单一数值。Momentary 与 shortTerm 两者都每 100 毫秒提供带有时间戳的数值,但采用不同的时间窗:momentary 使用 400 毫秒的时间窗,能捕捉「响度上短促而突然的尖峰」,而 shortTerm 则使用 3 秒的时间窗,提供「对响度趋势随时间变化更为平滑的视角」。1结果还携带一个 peak 值,即以分贝测得的绝对最高音量。1
流式响度 AsyncSequence
上述的批处理 API 分析的是一个已完成的文件。对于实时工作,MusicUnderstandingSession「也提供一套响度的流式 API」,其中「数值会在框架每分析 100 毫秒的音频时,通过 AsyncSequence 传递」。1每 100 毫秒就有一个新的响度读数,正是实时可视化工具所运行的节奏,这也是为什么真正担当音频反应式 UI 主角的,是这套 API 而非批处理那一套。
其使用模式是两个并发的 task。您如同先前那样初始化会话,接着「设置两个 task:一个在响度结果传递进来时加以消费,另一个则开始进行分析」。1一个 task 从序列中等候取值并将其推送到您的动画;另一个则推动分析向前进行。生产者与消费者并肩运行,而非彼此阻塞。
要喂入实时音频,需要提供一个 AudioProvider。一个 AudioProvider「符合 AsyncSequence 并产出 AVReadOnlyAudioPCMBuffer 对象」。1Apple 明确点出了终止的约定:当该提供者「已送出所有音频缓冲区后,必须送出最后一个 nil 以发出完成的信号」。1忘了那个结尾的 nil,消费端的 task 便会永远等候那永不结束的音频。提供者本身就是一个 AsyncSequence,这正是优雅之处:您的音频来源与框架的响度输出,从头到尾说着同一套异步迭代的语言。
还有两项会话的能力使整幅图景更为完整。每一项 Music Understanding 的结果都是 codable,因此导出一份完整分析「只需创建一个 JSONEncoder 并将会话结果编码即可」。1而示例应用程序的 Video 图块展示了这些结果如何组合:它「运用结构与律动来制作一支与音乐同步的视频」,先识别出各区段的时间区间,再依每个区段的律动(一个以每分钟事件数除以 60 秒所得的速率)来决定有多少片段能塞进该区间——在有活力的部分用较短、较快的片段,在平静的部分用较长、较慢的片段。1
重点整理
对于音频与媒体应用程序开发者:
- 从
analyze(for:)着手,而非analyze():只指名您要呈现的分析类型,好让框架跳过其余;反正未经请求的结果返回的都是nil。1 - 在您的 UI 中将
beatsPerMinute视为货真价实的 optional;nil代表框架尚未看到两个节拍,因此请显示一个等候状态,而非一个虚构的速度。1 - 在创建会话之前,先将
AVURLAsset上的PreferPreciseDurationAndTimingKey设为true,因为 Apple 将准确的结果与这个标志绑在一起。1
对于实时与可视化工作:
- 在响度
AsyncSequence(每 100 毫秒一个值)以及乐器的activity属性之上,构建实时的音频反应式动画;后者会将每项乐器映射到一个随时间推移的强度TimedValue。1 - 并发运行一个消费者 task 与一个分析 task,并让您自定义的
AudioProvider在最后一个AVReadOnlyAudioPCMBuffer之后送出一个结尾的nil,好让流干净利落地终止。1
对于曲库与工具团队:
- 运用
KeyResult与RhythmResult,依调性或速度来排序或分群一座音乐曲库,并通过将 codable 的SessionResult编码为 JSON 来保存分析结果以供重复使用。1
FAQ
Apple 的 Music Understanding 框架会分析什么?
它会分析一首歌的六大领域:调性、节奏、结构、律动、乐器活动与响度。每一项都对应到一个结果类型(KeyResult、RhythmResult、StructureResult、PaceResult、InstrumentActivityResult 与 LoudnessResult),并返回在一个 SessionResult 之中。框架会处理信号处理与模型推理,因此不需要 DSP 或机器学习的专业知识。1
Music Understanding 是在设备端还是在云端运行?
在设备端。Apple 表示该框架「完全在设备端运行」,因此您所分析的音频得以保持私密,并可离线工作。这套分析可跨 Apple 平台运行,毫无网络依赖。1
我该如何只获取我需要的分析?
调用 analyze(for:),而非一般的 analyze()。一般调用会填满 SessionResult 的每一个字段;锁定式调用只返回您所请求的类型,并让其余保持 nil。Apple 建议「为求最高性能」而指定类型,以避免不必要的运算。1
TimedValue 与 RangedValue 有何差别?
TimedValue 将一个值与单一的 CMTime 瞬间相关联,而 RangedValue 则将一个值与一段 CMTimeRange 区间相关联。这两种类型都遍布整个框架:举例来说,调号是以 ranged value 的形式抵达,而逐乐器的活动则以 timed value 的形式抵达。1
我该如何用它打造一个实时的音频反应式可视化工具?
使用 MusicUnderstandingSession 上的流式响度 API,它每分析 100 毫秒的音频便通过 AsyncSequence 传递数值。运行两个并发的 task(一个消费结果,一个推动分析),并通过一个自定义的 AudioProvider 喂入实时音频;该提供者需符合 AsyncSequence、产出 AVReadOnlyAudioPCMBuffer 对象,并送出一个结尾的 nil 以发出完成的信号。1
设备端音频分析,与 Apple 今年推出的其他媒体智能并肩而立:看看 iOS 27 中设备端 AI 如何进入 Spotlight 与媒体,以及在同一问题的音频转文本这一面上,Speech 框架与 SFSpeechRecognizer 如何相较。当您完全超出了 Apple 内置模型的范畴,以 Core AI 在 Apple silicon 上运行您自己的模型便是下一步。整个系列的中枢是 Apple Ecosystem Series。
参考资料
-
Apple,WWDC 2026 议程 253,Meet the Music Understanding framework。本文以下内容的出处:设备端、隐私与离线的定位;Final Cut Pro 的节拍检测与 iPad 蒙太奇功能;六大分析领域(调性、节奏、结构、律动、乐器活动与响度)以及歌曲构成元件的定义;从
AVAsset或音频提供者初始化的MusicUnderstandingSession;analyze()与analyze(for:)之别,以及由 optional 字段构成的SessionResult;通过 SwiftUIfileImporter进行的AVURLAsset与PreferPreciseDurationAndTimingKey设置;TimedValue/CMTime与RangedValue/CMTimeRange类型;KeyResult/KeySignature(tonic 与 mode)、RhythmResult/beatsPerMinute(少于两个节拍时为 optional)、StructureResult(sections、segments、phrases)、PaceResult、InstrumentActivityResult(ranges 与 activity,activity 为 Floats 的TimedValue)以及LoudnessResult(LUFS,integrated/momentary/shortTerm 时间窗,peak 以分贝计)等类型;每 100 毫秒以两个并发 task 传递数值的流式响度AsyncSequence;符合AsyncSequence、产出AVReadOnlyAudioPCMBuffer对象并送出结尾nil的AudioProvider;codable 结果与JSONEncoder导出;以及结构与律动的 Video 图块算法。 ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩