← 所有文章

認識 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:) 則讓其餘欄位保持 nil1
  • 兩種具時間感知的型別貫穿整個 API:TimedValue 將一個值與一個 CMTime 配對,而 RangedValue 則將一個值與一個 CMTimeRange 配對。1
  • MusicUnderstandingSession 還提供一套串流響度 API,每分析 100 毫秒的音訊便透過 AsyncSequence 傳遞數值,這正是驅動即時音訊反應式動畫的基礎。1

為何裝置端的音樂智慧如此重要

Watch on Apple Developer ↗

來自 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():只指名您要呈現的分析類型,好讓框架略過其餘;反正未經要求的結果回傳的都是 nil1
  • 在您的 UI 中將 beatsPerMinute 視為貨真價實的 optional;nil 代表框架尚未看到兩個節拍,因此請顯示一個等候狀態,而非一個虛構的速度。1
  • 在建立工作階段之前,先將 AVURLAsset 上的 PreferPreciseDurationAndTimingKey 設為 true,因為 Apple 將準確的結果與這個旗標綁在一起。1

對於即時與視覺化工作:

  • 在響度 AsyncSequence(每 100 毫秒一個值)以及樂器的 activity 屬性之上,建構即時的音訊反應式動畫;後者會將每項樂器對應到一個隨時間推移的強度 TimedValue1
  • 並行運行一個消費者 task 與一個分析 task,並讓您自訂的 AudioProvider 在最後一個 AVReadOnlyAudioPCMBuffer 之後送出一個結尾的 nil,好讓串流乾淨俐落地終止。1

對於曲庫與工具團隊:

  • 運用 KeyResultRhythmResult,依調性或速度來排序或分群一座音樂曲庫,並透過將 codable 的 SessionResult 編碼為 JSON 來保存分析結果以供重複使用。1

FAQ

Apple 的 Music Understanding 框架會分析什麼?

它會分析一首歌的六大領域:調性、節奏、結構、律動、樂器活動與響度。每一項都對應到一個結果型別(KeyResultRhythmResultStructureResultPaceResultInstrumentActivityResultLoudnessResult),並回傳在一個 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

參考資料


  1. Apple,WWDC 2026 議程 253,Meet the Music Understanding framework。本文以下內容的出處:裝置端、隱私與離線的定位;Final Cut Pro 的節拍偵測與 iPad 蒙太奇功能;六大分析領域(調性、節奏、結構、律動、樂器活動與響度)以及歌曲構成元件的定義;從 AVAsset 或音訊提供者初始化的 MusicUnderstandingSessionanalyze()analyze(for:) 之別,以及由 optional 欄位構成的 SessionResult;透過 SwiftUI fileImporter 進行的 AVURLAssetPreferPreciseDurationAndTimingKey 設定;TimedValue/CMTimeRangedValue/CMTimeRange 型別;KeyResult/KeySignature(tonic 與 mode)、RhythmResult/beatsPerMinute(少於兩個節拍時為 optional)、StructureResult(sections、segments、phrases)、PaceResultInstrumentActivityResult(ranges 與 activity,activity 為 Floats 的 TimedValue)以及 LoudnessResult(LUFS,integrated/momentary/shortTerm 時間窗,peak 以分貝計)等型別;每 100 毫秒以兩個並行 task 傳遞數值的串流響度 AsyncSequence;符合 AsyncSequence、產出 AVReadOnlyAudioPCMBuffer 物件並送出結尾 nilAudioProvider;codable 結果與 JSONEncoder 匯出;以及結構與律動的 Video 圖磚演算法。 

相關文章

Apple Swift 團隊在 WWDC26 實驗室裡說了什麼

Apple 的 WWDC26 Swift Group Lab 沒有字幕,我們在本機完成轉錄。工程師針對並行處理、~Sendable 與技術藍圖的坦率回答。

4 分鐘閱讀

Swift 新功能總覽(2026):WWDC26 更新

來自 WWDC26 的 Swift 6.3 與 6.4:anyAppleOS 可用性、模組選擇器、borrow/mutate 存取器、Iterable 協定、Swift Testing 互通,以及 MLX。

5 分鐘閱讀

The Robots Are Taking Exams in My Search Console

First-party GSC data: 91% of 3.8M impressions fail a human-query filter. Exam questions, pasted errors, and agent sweeps…

10 分鐘閱讀