本文將以實戰方式探討基于Spotify公司的開源音樂大模型Llark并聯合阿里巴巴的語音多模態大模型Qwen2-AudioQwen2-Audio將音樂轉錄成樂譜的完整過程。

自動音樂轉錄是將MP3和WAV等音頻文件轉換為樂譜、吉他指法譜以及音樂家可能想要用樂器學習歌曲的任何格式的過程。

本文中，我們將介紹目前用于執行上述操作的最佳工具，這些工具恰好是基于深度學習的，并采用了一種新穎的方法。

當前最先進的技術

這項任務的當前最先進的技術來自??Magenta??，這是一個開源研究項目，由現已解散（截至2023年4月）的Google Brain團隊開發。

這個開發團隊在2021年發表了一篇論文《??使用轉換器進行序列到序列鋼琴轉錄??》，該論文使用了受T5啟發的轉換器模型（類似于“t5-small”），該模型具有5400萬個參數和??Maestro數據集??，取得了很好的效果。使用編碼器-解碼器轉換器架構將問題作為序列到序列任務來解決。編碼器將梅爾頻譜圖幀作為輸入處理并生成嵌入，而解碼器通過交叉注意力機制使用這些嵌入以自回歸方式生成一系列類似MIDI的標記。這個開發團隊使用的詞匯表由四種類型的標記組成：

• 音符標記（MIDI音高的128個值）
• 速度標記（128個值，包括零表示音符關閉）
• 時間標記（用于絕對計時的10毫秒bin格式文件中有6000個值）
• EOS標記（用于標記序列結束）

請參見下圖，了解這種架構的可視化形式以及其自定義MIDI標記的示例序列：

圖1.來自使用轉換器進行序列到序列鋼琴轉錄的論文

說明：我們的模型是一個通用的編碼器-解碼器轉換器架構，其中每個輸入位置包含一個頻譜圖幀，每個輸出位置包含來自我們類似MIDI的詞匯表的事件。輸出標記是從解碼器自回歸采樣的，每一步都以最大概率獲取標記。

2022年，開發團隊發表了一篇論文《??MT3：多任務多軌音樂轉錄??》。該實驗使用了與上一個實驗相同的方法，但添加了額外的樂器標記來表示不同的樂器。同樣，他們使用了類似的T5模型，并在許多訓練過的數據集上取得了出色的表現，尤其是??Slakh??、Maestro和??MusicNet??數據集。

??MR-MT3??于次年發布，作為MT3的輕微改進版本出現。

為什么要使用語言模型而不是繼續使用這些SOTA模型？

計算/GPU資源

盡管與最小的語言模型相比，其規模要小得多，但從頭開始訓練此模型仍然需要大量資源。2021年的論文指出：

“我們在32個TPUv3核心上訓練了所有模型，每個核心的訓練批次大小為8。根據驗證集結果，過度擬合似乎不是問題，因此我們允許訓練進行400K步，這對于我們的基線模型來說大約需要2.5天。”

此MT3論文沒有提供關于訓練的具體細節，只是說他們訓練了100萬步。

其他限制

這些模型在輸出靈活性方面有一些固有的限制。雖然語言模型通常具有大量詞匯（通常超過30,000個標記），并且已在各種自然語言數據上進行了廣泛的預訓練，但MT3和類似的音樂轉錄模型使用小得多的專門標記詞匯（只有幾千個標記），僅專注于音樂事件。這種專業化意味著添加新標記（例如新樂器或演奏技巧，如吉他上的手掌靜音或小提琴上的撥弦）可能并不容易——需要進行大量的再訓練才能將這些新標記有效地與現有詞匯結合起來，并且通常需要大量的訓練數據來展示這些技巧。這與大型語言模型不同，大型語言模型通常可以在不進行修改的情況下用自然語言描述這些音樂細微差別，因為它們在廣泛的預訓練中遇到了這些概念。

遷移學習和零樣本

我們可以利用大型開源預訓練音頻和語言模型的遷移學習。音樂生成模型的示例包括OpenAI的??Jukebox??和Meta的??MusicGen??。

現代多模態模型架構

??GPT-4o??旨在以“原生”方式處理文本、音頻和圖像。盡管OpenAI尚未公布這方面的技術細節，但假設網絡中的某些權重數據集能夠處理所有各種模態。該模型可能使用僅解碼器架構（如僅語言的GPT模型），而無需編碼器組件先將不同模態轉換為密集表示。這種設計允許模型無縫地處理和解釋文本和圖像等輸入，從而可能在計算和模型理解方面提供性能優勢。

許多多模態模型采用一種更簡單的方法，讓人聯想到編碼器-解碼器架構：它們結合了兩個預訓練模型——一個用于特定輸入模態的編碼器（如用于視覺的ViT或用于聲音的音頻編碼器）和一個大型語言模型（如LLaMA、Gemma或Qwen）。這些模型通過投影層連接起來，投影層將它們的表示對齊到共享的潛在空間中，通常只使用一個線性層。這些投影層學習將編碼器的輸出轉換為與LLM的預期輸入維度和特征相匹配的格式。投影從輸入模態創建新的嵌入/標記，然后可以將其注入到LLM的輸入序列中。??LLaVA??是這種架構在視覺語言任務中的典型示例，而Spotify的??Llark??和??Qwen-Audio??則使用音頻編碼器而不是視覺編碼器應用了相同的原理。

以下是一些關于如何將模型拼接在一起的偽代碼：

#從音頻編碼器的最后一層中提取特征
#形狀: [batch_size, audio_seq_len, encoder_dim=1024]
audio_features = audio_model(audio_input)

#投影音頻特征，以匹配LLM的嵌入維度
# 形狀: [batch_size, audio_seq_len, llm_embed_dim=4096]
audio_embeddings = projection_layer(audio_features)

#從LLM的嵌入層中獲取文本嵌入
# 形狀: [batch_size, text_seq_len, llm_embed_dim=4096]
text_embeddings = llm.embed_text(text_input)

#沿著序列長度方向進行連接
# 形狀: [batch_size, audio_seq_len + text_seq_len, llm_embed_dim=4096]
combined_input = concatenate([audio_embeddings, text_embeddings], dim=1)

# 將它們正常送入LLM進行生成
output = llm(combined_input)

Spotify的Llark和Qwen2-Audio

架構概述

Llark使用OpenAI的Jukebox，Qwen2-Audio使用OpenAI的??Whisper??作為音頻塔。Jukebox是一種音樂生成模型，但它也可以接收音頻片段作為輸入并輸出音頻片段的延續。Whisper用于將語音轉錄為文本。

考慮到它們的用途，音頻模塊的選擇很明確：Llark專注于音樂分析，而Qwen2Audio主要專注于通過一些基本的音頻和音樂分析功能響應語音指令。

確定從大型預訓練模型中提取嵌入的最佳來源需要研究和實驗。此外，決定是否微調整個模塊或凍結部分模塊是一個至關重要的設計選擇。例如，LlaVa的訓練策略包括凍結視覺塔并專注于微調投影層和語言模型。我們將在接下來介紹每個模型的這一特征。

Llark：為什么是Jukebox？截至2024年9月，這些嵌入是否是最好的？

確定從大型模型中提取嵌入的最佳位置通常需要進行大量探索。這涉及通過反復試驗的過程在不同的分類任務上測試模型的各種激活或提取層。對于音樂生成模型，這可能包括流派識別、樂器檢測、情緒檢測以及和聲結構和時間模式分析等任務。許多商業嵌入模型（如OpenAI的嵌入模型）都是專門為嵌入生成而訓練的，具有專門的架構和訓練目標，而不是現有語言模型的微調版本。

兩個最大的公開可用的音樂生成和音樂延續（即：能夠將音頻作為輸入）模型是Jukebox和MusicGen。其中，MusicGen模型的更新更快，對我來說似乎是顯而易見的選擇。然而，根據關于探索??MusicGen的論文??，從Jukebox中提取的嵌入似乎在分類任務中平均表現優于MusicGen。這篇論文的研究結果促使Llark的作者使用以下方法提取嵌入：

嵌入來自Jukebox編碼器第36層的輸出，遵循Castellon等人（2021）中描述的方法。

原始Jukebox編碼：

• 345Hz的4800維向量。
• 對于25秒的剪輯：超過4.14*10?個浮點值。

作者使用下采樣方法：在100ms幀內進行均值池化，結果：

• 下采樣頻率：10Hz。
• 嵌入大小：25秒音頻剪輯的1.2×10?。這意味著使用一個形狀為[240,4800]的二維數組。
• 保留時間信息（與Castellon等人在時間維度上取平均值的方案有所不同）。

（下采樣嵌入大小大約是許多多模態視覺模型中使用的CLIPViT-L14模型的6倍）

Qwen2Audio：Whisper

本文未詳細提及Qwen2Audio的嵌入提取。Whisper是一種編碼器-解碼器架構；其中，編碼器負責生成音頻的深度學習表示，解碼器則負責將表示解碼為文本（轉錄）。在Qwen2Audio中，他們似乎從Whisper編碼器的最后一層提取嵌入，盡管他們沒有提到他們是否在訓練期間凍結它。

預訓練權重、訓練數據和數據集

不幸的是，Spotify尚未向公眾提供任何數據集或其訓練過的模型權重，并指出：

“關于輸入：我們模型的輸入是公開的、開源的、知識共享許可的音頻和相關注釋。但是，每個音頻文件都有自己的、可能更嚴格的許可證。許多音頻文件都包含“禁止衍生”許可證。我們鼓勵數據集的用戶熟悉這些許可證的限制；為了遵守這些許可證，我們不會發布本文中訓練數據的任何衍生品（包括查詢-響應對或訓練模型權重）。”

訓練過程中，他們使用了以下數據集：

• MusicCaps（Agostinelli等人，2023年）
• YouTube8M-MusicTextClips（McKee等人，2023年）
• MusicNet（Thickstun等人，2017年）
• FMA（Defferrard等人，2017年）
• MTG-Jamendo（Bogdanov等人，2019年）
• MagnaTagATune（Law等人，2009年）

Llark在以下摘錄中詳細介紹了其訓練數據生成過程：

“我們使用ChatGPT的變體來提取所有實驗的指令調整數據。但是，所使用的確切語言模型因數據集而異。我們選擇OpenAI模型如下：我們對所有推理任務都使用GPT-4。我們發現GPT-4更擅長遵循推理任務系列中的復雜指令。對于樣本超過25k的數據集，我們將推理數據限制為25k個軌道的隨機子樣本。”

這會產生如下問答數據：

LLark的示例文本輸入和輸出，用于提供的音頻

用于訓練Qwen2Audio的數據集也沒有共享，但經過訓練的模型廣泛可用，并且也在轉換器庫中實現：

• Qwen2-Audio官方??github代碼倉庫??
• Qwen2-Audio轉換器??文檔??

對于這個項目，微調預先訓練的Llark模型將是最佳選擇，因為它在Spotify論文中所述的評估基準方面表現良好。

但是，鑒于他們沒有發布它的權重，如果沒有相當多的專業知識和資金，從頭開始訓練這樣的模型是不可行的。Spotify對其進行了訓練：

我們的模型在4個80GB NVIDIA A100 GPU上進行訓練。訓練大約需要54小時。

如果使用LambdaLabs等提供商提供的云服務的話，這將花費大約700美元。

由于上述原因，我選擇了Qwen。然而，Qwen2-Audio在節奏和樂器檢測等基本音樂任務中表現不佳。我將在下面的評估部分詳細說明這一點。這意味著，該模型可能不夠大或預訓練不足，無法完成這項任務，但我希望至少可以為將來微調這項任務設定一個起點和框架。正如阿里巴巴在其Qwen2-Audio??博客文章??中所述：

“我們還計劃構建更大的Qwen2-Audio模型，以探索音頻語言模型的縮放規律”。

不過，為了我自己的學習，我確實嘗試使用torch和帶有轉換器庫的預訓練模型重新創建模型。

我還為問答數據和嵌入創建了數據集。我為URMP數據集生成了簡短形式的問答數據，例如：“這首曲子的節奏是多少”、“這段音頻中演奏的樂器是什么”。

在Colab環境中運行Jukebox的筆記本源文件地址是https://colab.research.google.com/drive/1jdR5w-XlJQFog47ZJ36ckEVMW0F5qIpl，使用的是廉價的T4GPU。我在鏈接https://huggingface.co/jonflynn處將問答和嵌入數據集上傳到HuggingFace。

?復制有Llark的筆記本源文件的地址是：??https://colab.research.google.com/drive/1_V5B9ZrwrKtom-N4r-Om3mqlXKPacUBh#scrollTo=72Gv5raTIPqi??。?

訓練音樂轉錄數據

轉錄格式

我選擇??ABC音樂符號??作為語言模型轉錄音樂的輸出格式。以下是一個例子：

X:1
M:4/4
L:1/16
K:none
Q:67

V:1 name="Electric Bass (finger)"
%%octave-default C4
GAA^2E3A2<A^2 | D^D^2E2A2A^4 A^2E2 | A2A^4A^2E2 A2A^4 | A^2E2A2A^4A^2E2A2 |
A^4 A^2E2 A2A^4A^2 E2 | A2A^4 |

V:2 name="Bright Acoustic Piano"
%%octave-default C5
[E3C3][E3C3][E3C3] [E3C3][A^,2E2A^2] | [E3A^3][E3A^3][E3A^3][E3A^3][E3A^3] |
[E3A^3][E3A^3][E3A^3] [E3A^3][E3A^3] | [E3A^3][E3A^3][E3A^3][E3A^3][E3A^3] |
[E3A^3][E3A^3][E3A^3] [E3A^3][E3A^3] | [E3A^3] |

V:3 name="Electric Guitar (jazz)"
%%octave-default C5
E'3C'3A^4E'3C'3 | A^4E'3 C'3A^4E'3C'3 | A^4 E'3C'3A^4 E'3C'3 | A^4E'3C'3A^4E'3C'3 |
A^4E'3C'3 A^4E'3C'3 | A^4 |

在上面的符號中，我們在頂部定義了拍號和節奏，用“M”和“Q”表示。“L”表示符號的默認音符長度，在本例中是十六分音符，這是常態。然后，我們定義每個樂器，以及在為每個樂器寫音符時它們應該遵循的默認八度。以下是ABC音樂符號中寫音符的關鍵句法要點的總結：

• 音符用字母A-G表示，小寫字母表示高八度
• 升號用音符前的^表示，降號用_表示
• 還原符號用=表示
• 音符長度用音符后的數字表示（C2是C的兩倍長）
• 音符后附點音符使用a.（C.是附點四分音符）
• 休止符用z表示，數字表示持續時間（z2是半休止符）
• 和弦用方括號[CEG]括起來
• 連音符用連字符-表示
• 小節線用|表示
• 斷奏節奏在音符之間使用>或<（C>D表示附點C八分音符后跟D十六分音符）

為什么使用ABC音樂符號？

選擇這種符號的原因是：

• 這是一種極簡主義的音樂創作格式。
• 它被廣泛使用且很受歡迎；語言模型已經對ABC符號進行了廣泛的預訓練，因此已經很好地理解了它。
• 它很靈活，可以輕松擴展以包括節奏變化、拍號變化、如上所述的其他演奏風格等……

我使用庫https://github.com/sshlien/abcmidi將數據集提供的MIDI文件轉換為ABC符號。創建數據集的筆記本文件位于鏈接https://colab.research.google.com/drive/1CdQ_PUjhCvCR2VjGt3ya1hNowPrr0Xun處。

評估

為了評估原始模型以及此后執行的每個微調階段，我從URMP數據集中隨機選擇了30個復雜程度不同的樣本，并在每個樣本上運行模型三次，手動檢查所有響應。

通過手動測試，我發現最佳解碼參數是溫度為0.7，top_p為1.2。返回的最大標記數上限為2048。調整最大值似乎對性能影響不大。

原始模型在此評估集上表現不佳。雖然它偶爾能正確預測節奏和樂器，但大多數時候都做不到。評估結果的文本文件可在??此處??獲取。

鑒于這個起點，如果沒有強大的預訓練模型，我們不太可能從這個實驗中看到強勁的結果。然而，目標是制定可以在未來隨著更先進的預訓練模型的出現而應用的策略。

微調策略

我首先嘗試使用基本的交叉熵損失進行微調。使用交叉熵損失進行監督微調是一種快速開始教授模型的方法，但像這樣的基本損失函數有局限性，我們將在下面看到。這個訓練階段背后的直覺是，它會將模型推向正確的方向，并會拾取數據集中可能存在的任何模式或任何自定義的ABC符號，而模型可能以前從未見過。

使用教師強制型交叉熵損失

首先，我們以典型的監督微調方式對語言模型進行訓練。我為此使用了trl庫中的SFTtrainer，它使用交叉熵損失和教師強制機制，具體定義如下：

• 模型預測序列中的下一個標記。
• 損失是根據預測概率（logits）和實際下一個標記之間的差異計算的。
• 對于下一個預測，模型被賦予實際正確的標記（真實數據），而不是它自己的預測。這被稱為“教師強制”，它有助于穩定訓練并顯著加快訓練速度，尤其是在早期階段。

此訓練階段的結果很差，它降低了原始模型的性能。該模型以前可以很好地處理節奏和樂器識別，但現在大部分都出錯了。它還開始產生無休止重復的亂碼文本輸出。即使在設置低學習率、應用梯度裁剪和使用低LoRA等級來減輕對模型的重大更改時，也會發生這種情況。總體而言，該模型似乎對所應用的訓練非常敏感。

然而，雖然這個訓練階段可能會帶來一些改進，但由于我們的基本損失函數的限制，它不會帶來最佳性能。該函數很難完全捕捉模型的性能細微差別。例如，當使用教師強制時，樂器預測可能會在某些標記部分產生看似較低的損失。如果樂器名稱以“V”開頭，無論準確度如何，模型都可以根據我們的數據集自信地預測“小提琴”或“中提琴”。此外，損失函數可能無法準確反映近乎失敗的情況，例如預測節奏為195而不是200——這是一個相當準確的小差異，但可能會受到懲罰，這在很大程度上取決于logit之間的概率分布。相鄰數字也可能具有較高的概率。

結合近端策略優化（PPO）的RLHF模型

由于這些限制，我們可以創建自己的自定義損失函數，可以更準確地對模型的響應進行評分。也就是說，給定模型的預測序列，損失函數可以給出0到1之間的分數來表示其好壞。

然而，將這個自定義損失函數集成到監督微調中是一項重大挑戰。問題源于自定義損失函數引入的非線性，這阻礙了梯度的直接計算。讓我們來分析一下：

在具有交叉熵損失的傳統SFT中：

• 模型輸出詞匯表中每個標記的logit（原始分數）
• 這些logit直接表示模型的預測概率
• 損失函數將這些概率與基本事實進行比較
• 可以通過此比較直接計算梯度
• 微積分的鏈式法則允許我們將這些梯度傳播回模型

使用我們的自定義損失函數：

• 模型必須首先生成完整的文本輸出
• 此生成過程涉及從概率分布中進行采樣
• 然后，我們的損失函數分析此文本輸出（檢查節奏、音符等）
• 這在模型的logit和我們的損失計算之間創建了一個不可微分的步驟
• 采樣和文本分析步驟打破了反向傳播所需的梯度鏈

為了克服這個問題，可以采用強化學習技術，例如近端策略優化（PPO）。PPO專門用于處理不可微分損失函數，可以通過考慮整個策略（模型的輸出分布）來優化模型，而不是依賴來自logits的梯度信息。

PPO的關鍵思想是，它不是試圖直接通過不可微分步驟進行反向傳播，而是：

• 將模型的輸出視為強化學習框架中的動作
• 使用自定義損失函數作為獎勵信號
• 更新模型的策略（其在標記上的概率分布）以最大化預期獎勵
• 同時確保更新后的策略不會偏離當前策略太遠

這種方法使我們能夠使用自定義損失函數有效地訓練模型，確保性能改進而不會破壞核心訓練動態。PPO算法的保守更新策略有助于在訓練期間保持穩定性，這在使用大型語言模型時尤為重要。

此評分函數將以“獎勵模型”的形式作為單獨的LLM實現，通常用于通過RLHF微調模型，這是ChatGPT問世時首次引入的一項突破。由于此任務的性質，我們可以手動編寫代碼來對響應進行評分，這樣使用的資源更少，速度更快。

對于拍號和節奏識別，這很容易計算。我們使用正則表達式提取所有預測項，例如提取節拍：

def extract_metre(self, abc_string):
return re.search(r'M:(\S+)', abc_string).group(1)

模型應該學習我們希望它在SFT階段輸出的語法和結構。如果它輸出的內容會導致我們的正則表達式找不到任何內容或出現錯誤，我們可以跳過該樣本，假設它只是數據集中的一小部分。

我們提取預測的節奏并編寫一個函數，該函數對小錯誤更寬容，但對大錯誤懲罰更嚴厲：

• 對于小差異（≤10BPM），它使用線性縮放。
• 對于較大的差異，它會切換到指數縮放。
• 最終損失上限在0和1之間。

讓我們分解一下這個自定義損失的關鍵組成部分：

自定義損失的代碼在鏈接??https://colab.research.google.com/drive/1lpPfn9EFE2rBsasIJNv8Cy9qTvtfXzq-#scrollTo=mOs_gWcjrBgv處提供，您可以自行參考。???

1. 節拍損失

節拍損失關注作品的拍號。它將預測的節拍與基本事實進行比較，分別考慮分子和分母以及它們的比率。這種方法允許進行細致入微的評估，可以準確處理各種拍號。

節拍損失使用線性和指數縮放的組合來懲罰差異。小差異會導致損失線性增加，而較大的差異會導致指數增加，最大值為1。

2. 節奏損失

節奏損失評估預測的每分鐘節拍數（BPM）的準確性。與節拍損失類似，它使用線性和指數縮放的組合。

對于小節奏差異（≤10BPM），該函數應用線性縮放。較大的差異會觸發指數縮放，確保顯著的節奏不匹配受到更嚴重的懲罰。

3. 音高損失

音高損失可能是最重要的組成部分，因為它評估轉錄音符的準確性。此函數使用Levenshtein距離來比較每個聲音中的音符序列。

音高損失計算考慮了多個聲音，將每個預測聲音與最接近的真實聲音進行匹配。這種方法允許靈活地對聲音進行排序，同時仍保持整體音調內容的準確性。

4. 樂器損失

樂器損失評估每個聲音的樂器選擇的準確性。

此函數考慮精確匹配、來自同一家族的樂器，并使用字符串相似性進行更細致的比較。它全面評估了模型識別和為每個聲音分配樂器的能力。

5. 合并損失

最終損失是這些單個組件的加權組合：

total_loss = (0.5 * pitch_loss +
0.15 * metre_loss +
0.15 * tempo_loss +
0.2 * instrument_loss)

這種加權方案優先考慮音高準確性，同時仍考慮音樂轉錄的其他重要方面。

訓練和超參數

PPO訓練通常需要比SFT多得多的內存，原因如下：

• 多個策略評估：PPO需要維護當前策略（模型權重）和“舊”策略來計算它們之間的概率比。這實際上使內存中的模型參數翻倍。
• 經驗緩沖區：PO存儲經驗緩沖區（狀態、動作、獎勵等），以在小批量中執行更新。這個緩沖區可能非常大，占用大量內存。
• 優勢估計：計算優勢需要跟蹤軌跡中的值估計和回報，這又增加了一層內存開銷。
• 額外的優化目標：PPO跟蹤多個損失成分（策略損失、值損失、熵獎勵）及其梯度，而SFT只有一個損失。

由于上述原因，我們在可以訓練的模型大小和成本方面比SFT更受限制。雖然我可以在Colab中的A100 40GB上進行上述訓練，但對于PPO訓練，我需要更多內存。我在H100 80GB上進行訓練，它可以訓練等級為128且批處理大小為8的LoRA。

我的超參數范圍很窄，我選擇了最直觀的方法，使用批處理大小從1到16，學習率從2e-5到2e-4。

該模型對任務沒有改進。包含結果的文本文件在鏈接http://asdf/處提供。

我使用權重和偏差（WandB）跟蹤了各種訓練指標。關鍵指標包括策略損失、價值損失、總損失、KL散度和獎勵模型的分數。

對于所有超參數運行，記錄的獎勵和損失隨時間推移的計算沒有改善。KL散度保持在預定義的閾值內。

總結

雖然本文中的初步實驗在音樂轉錄方面沒有達到預期的效果，但我們為該領域的未來發展奠定了一些基礎。所遇到的挑戰為解決這一復雜任務的技術要求和潛在方法提供了寶貴的見解。未來的工作可以探索以下幾個有希望的方向：

• 在更大的預訓練模型可用時進行實驗
• 使用更多樣化的音樂示例擴展訓練數據集
• 進一步完善獎勵函數以捕捉更細微的音樂關系
• 探索將傳統音樂處理技術與語言模型功能相結合的混合方法

我使用Qwen2-Audio運行本文中這些實驗的筆記本文件位于下面鏈接處：??https://colab.research.google.com/drive/1lpPfn9EFE2rBsasIJNv8Cy9qTvtfXzq-???

譯者介紹

朱先忠，51CTO社區編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

原文標題：??Exploring Music Transcription with Multi-Modal Language Models??，作者：Jon Flynn