AudioMuse-AI：不靠標籤，用聲音本身重建你的播放清單
AudioMuse-AI uses sonic analysis to rediscover forgotten songs, uncover hidden connections in your music library, and generate intelligent playlists for Navidrome, Jellyfin, LMS, Lyrion, Emby and Plex: no metadata or external services required.
秒懂
- 它是什麼？
- 這個專案以 Docker 或 Kubernetes 自架，對音樂庫做聲學分析後產生聚類、相似歌曲與文字搜尋播放清單，可同時接上 Navidrome、Jellyfin、LMS、Lyrion、Emby 與 Plex。它的價值與風險都寫在同一份文件裡：分析是一次性的重活，但歌詞搜尋只覆蓋 72 種語言。
- 適合誰用？
- 如果你已經有一台常開的機器、音樂庫在數千首以上，而且願意接受第一次分析要等，AudioMuse-AI 值得先在自己的資料上跑一次完整分析再決定。若你的音樂庫只有幾百首、或你習慣把媒體伺服器放在效能很有限的 ARM 小主機上，先把分析工作與伺服器分開會比較實際。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
歌單工具的老問題：標籤不描述聲音
自架音樂庫的推薦功能長期卡在同一個地方。多數工具靠 ID3 標籤、流派欄位或外部 API 來判斷一首歌是什麼，但標籤是人工輸入的產物：同一張專輯在不同來源可能被標成三種流派，獨立發行的作品常常整批空白。AudioMuse-AI 選擇繞過這一層，README 的說法是「without relying on metadata or external APIs」，改為對音訊本身做聲學分析，再從分析結果產生播放清單。
它針對的是已經跑著 Navidrome、Jellyfin、LMS、Lyrion、Emby 或 Plex 的自架使用者，尤其是那種音樂庫累積多年、自己都記不清裡面有什麼的人。專案提供的功能清單圍繞同一個前提：先做一次初始分析，之後才有 Clustering、Music Map、Song Paths、Sonic Fingerprint、Song Alchemy 這些東西可用。分析不是可選的前置步驟，它是整個系統的地基。
分析管線：CLAP、Librosa 與 ONNX 各管一段
從 repository 的 topics 與 docs 目錄可以看出技術堆疊的分工。Librosa 負責訊號層的特徵抽取，也就是節奏、能量這類可量化的聲學屬性；CLAP 是對比式語言音訊預訓練模型，把音訊與文字映射到同一個向量空間，這是 Text Search 能接受「calm piano songs」這種描述的原因；ONNX 則是推論階段的執行格式，讓模型能在不同硬體上跑。docs 目錄下有獨立的 ALGORITHM.md 與 ARCHITECTURE.md，演算法細節以那裡為準，README 只給功能層的描述。
應用本身由 Flask 與 Worker 兩類容器組成，README 寫得很直接：「it run Flask and Worker containers to actually run all the feature」。這個切分意味著分析是背景工作，不是同步請求，你可以想成前端負責接指令與呈現，Worker 負責消化音訊。v3.2.0 把佇列搬到 PostgreSQL，release notes 的說法是「Redis is not needed anymore」，等於少了一個要維護的元件。
多伺服器支援從 v3.0.0 開始，同一個部署可以接上任意組合的六種伺服器。關鍵在內建的重复偵測：README 說「each track is analyzed only once and every server shares the result」。如果你的音樂庫同時餵給 Jellyfin 和 Navidrome，這個設計省下的不只是磁碟，還有好幾小時的 GPU 或 CPU 時間。
把服務跑起來：Docker Compose 與 PostgreSQL 佇列
README 給的入門路徑是 Docker Compose 或 Podman，另外也提供 macOS、Windows、Linux 的原生應用程式。Kubernetes 部署走獨立的 Helm chart repository（NeptuneHub/AudioMuse-AI-helm），映像同時支援 AMD64 與 ARM64。
設定值集中在 docs/PARAMETERS.md，認證相關在 docs/AUTH.md，錯誤碼對照在 docs/ERROR_CODES.md。這三份文件的拆分方式透露了一個現實：這個系統的可調參數不少，而且失敗時會回傳自訂錯誤碼，不是單純的 HTTP 狀態。部署前值得先把 ERROR_CODES.md 掃一遍，否則第一次分析卡住時你會不知道去哪裡看。
有兩個部署細節容易被忽略。第一，plugin 系統從 v2.6.0 開始支援，但 README 明確警告「requires a persistent volume mounted on both the Flask and worker containers, otherwise installed plugins are lost whenever the containers restart」，兩個容器都要掛，只掛一個沒用。第二，GPU 部署有獨立的 docs/GPU.md，而 v3.3.0 新增的 -nvidia-arm 映像針對 DGX Spark 與 GB10 這類硬體，release notes 自己標明這個映像「experimental」。實驗性標籤不是客套話，選它之前要有心理準備。
歌詞搜尋的 72 種語言邊界
Lyrics Search 是這份 README 裡唯一把限制寫成硬性清單的功能：它只支援列出的 72 種語言，從 Afrikaans 到 Yoruba。這不是模型品質問題，而是覆蓋範圍問題。如果你的音樂庫以台語、客語或任何不在清單上的語言為主，這個功能對你就是不存在的，Text Search 的聲學描述仍然可用，但「用故事或主題找歌」這條路走不通。
這個限制值得單獨拿出來講，因為它很容易在試用階段被忽略。多數人會先用英語或華語歌曲測試，功能正常，於是以為整個音樂庫都能用。實際上，覆蓋率取決於你的收藏語言分布，而這個分布只有你自己知道。
另一個容易被低估的成本是第一次分析。README 把它當成使用流程的第一步，但沒有給出時間估計，因為那取決於音樂庫大小、CPU 或 GPU 規格、以及模型選擇。文件沒有提供基準數字，任何聲稱「幾小時完成」的說法都不該當真。你能做的只有先拿一個子集試，量出自己環境的實際速度。
與 Essentia 加自寫腳本的路線差異
聲學分析不是新領域，Essentia 這類工具早就能抽出 BPM、調性、能量等特徵，很多人也確實自己寫過腳本，把特徵倒進資料庫再土砲做相似度查詢。這條路線的差別在於：你拿到的是原始特徵，不是可用的播放清單。
AudioMuse-AI 把整條鏈接起來：特徵抽取、向量化、聚類、與媒體伺服器的 API 對接、以及一組現成的介面（Music Map、Song Alchemy、Song Paths）。代價是你接受了它的架構決定，包含 Flask 加 Worker 的容器切分、PostgreSQL 佇列、以及 AGPL-3.0 的授權條款。
AGPL-3.0 的實際意義在於：如果你把修改後的版本當成網路服務提供給他人使用，你需要以相同授權釋出原始碼。純粹自用、不對外提供服務的情境不受影響。這不是法律意見，條款細節請看授權全文。相較之下，自己用 Essentia 寫腳本沒有這個顧慮，但你得自己維護整條管線，包含媒體伺服器的整合層。
版本演進透露的維護節奏
從 release 紀錄看，這個專案的推送頻率不低。v3.5.0 的代號是 Hyperbolic Path，v3.5.1 加了 DCLAP Text Search Concept Weights，v3.5.2 是維護版本，三個版本集中在 2026 年 8 月底到 9 月初。這種節奏對自架使用者是雙面刃：功能推進快，但升級時要留意的變動也多。
v3.2.0 移除 Redis 依賴就是一個典型例子。如果你照著舊教學部署，會多跑一個不必要的容器；如果你從更早版本升級，佇列資料的遷移方式需要自己確認，README 只說「Just check the new deployment/docker-compose example」，沒有提供遷移步驟。
專案另外拆出多個 repository：Helm chart、Navidrome 外掛、Jellyfin 外掛、以及一個開源訂閱式音樂伺服器 AudioMuse-AI-MusicServer。Lyrion 外掛則由社群成員 JameZUK 維護，README 標明為 unofficial。這個拆分意味著各元件的版本可能不同步，升級核心應用時要一併確認外掛的相容性。
誰該先跑一次完整分析
判斷標準不在功能清單，而在你的音樂庫規模與硬體配置。數千首以上的收藏、一台常開的機器、以及願意等第一次分析跑完的耐心，這三個條件同時成立時，這個專案解決的是真實痛點：你確實記不清庫裡有什麼，而標籤幫不上忙。
反過來說，幾百首歌的音樂庫不需要聲學分析來找相似歌曲，你自己就記得每一首。把媒體伺服器放在效能有限的 ARM 小主機上的人也要三思，分析工作與伺服器搶資源的結果不會好看，把 Worker 拆到另一台機器是比較合理的方向。
部署前該確認的具體事項：PostgreSQL 是否已就緒（v3.2.0 之後它是唯一的外部儲存依賴）、plugin 目錄是否在 Flask 與 Worker 兩個容器上都掛了持久化磁碟區、以及你的收藏語言是否落在歌詞搜尋支援的 72 種之內。這三項確認完，再決定要不要把整個音樂庫餵進去。
編輯結論
如果你已經有一台常開的機器、音樂庫在數千首以上，而且願意接受第一次分析要等，AudioMuse-AI 值得先在自己的資料上跑一次完整分析再決定。若你的音樂庫只有幾百首、或你習慣把媒體伺服器放在效能很有限的 ARM 小主機上，先把分析工作與伺服器分開會比較實際。若你依賴歌詞語意搜尋非英語或非列出的語言，先確認該語言是否在那 72 種之內，否則這個功能對你就是空的。部署前先確認 PostgreSQL 是唯一的外部儲存依賴（v3.2.0 之後 Redis 已不需要），並確認 plugin 目錄有掛載持久化磁碟區，否則容器重啟後外掛會消失。
社群筆記