前一天，我已經把「哪些紀錄真的屬於 YOASOBI」這件事拆成明確的藝人歸屬規則。
但真正把規則套到自己的資料後，問題才開始出現。
我的 YouTube Music 歷史紀錄有 15,403 筆音樂活動，朋友提供的 Spotify 資料則有 101,202 筆歌曲播放紀錄。
兩邊加起來一共有 116,605 筆音樂事件。
問題是，我不能看到名稱像 YOASOBI，就直接把它算成 YOASOBI。
所以 Day 12 的目標，是把前一天建立的藝人歸屬規則真正接到實際資料，開始處理 source ID、alias、合作藝人與版本判定需要的 evidence。
這次我直接使用先前已經取得的兩份原始資料：
重新執行 production importer 後，結果是：
YouTube：
26,900 張活動卡片
→ 15,403 筆 YouTube Music
→ 11,497 筆一般 YouTube
Spotify：
101,319 筆來源紀錄
→ 101,202 筆歌曲事件
→ 117 筆 Podcast / Episode
因此最後進入 matching 的音樂事件總數是：
116,605 筆
而且這次重新執行真的抓到了兩個問題。
第一個是 YouTube 的時間格式。
我的 Takeout 裡存在 CST 時區，而前面的程式其實已經確認這份資料中的 CST 要明確對應成 +08:00。
但是 Day 12 新增的入口沒有把這個設定傳給 YouTube importer。
結果就是原本有效的 15,403 筆 YouTube Music 紀錄全部會被拒絕。
修正後，15,403 筆可以正常進入後續流程。
第二個問題則出現在 Spotify。
原本的程式只讀：
Streaming_History_Audio_*.json
但實際檢查朋友的 Extended Streaming History 後發現：
Streaming_History_Video_*.json
裡面也存在合法的歌曲播放紀錄。
最後發現一共有 453 筆 track event 來自 Video history。
所以 Spotify 的正確結果仍然是：
101,202 筆歌曲事件。
這也是我這次重新用真實資料執行，而不是只靠測試資料驗證的重要原因。
接下來才是 Day 12 真正的核心。
Spotify 每首歌曲本身有 track ID。
YouTube Music 的活動也可以取得 video ID。
所以這次 matching 不直接使用：
「歌名看起來一樣」
或：
「頻道名稱看起來像 YOASOBI」
來決定歸屬。
而是以實際來源 ID 作為查證單位。
例如 Spotify：
spotify + track ID
YouTube Music：
youtube_music + video ID
然後針對 exact source item 保存對應的 metadata evidence。
這樣同名歌曲、翻唱、Live、其他歌手演唱版本，就不會因為標題相似而直接被合併。
這次沒有繼續找任意公開歌曲當測試案例。
我直接從實際聆聽資料產生的 review queue 裡，挑出影響事件數較高的 source ID。
最後查證了 13 個 exact source items：
Spotify 10 個
YouTube Music 3 個
這 10 個 Spotify source item 一共影響：
422 筆播放事件
3 個 YouTube Music source item則影響：
302 筆活動事件
也就是說，一次 source-item review 可以套用到所有具有相同來源 ID 的重複聆聽事件。
但這不代表把它們去重。
例如某個 track ID 在歷史紀錄出現 73 次，它仍然是 73 筆播放事件。
source ID 只是讓這 73 筆事件共用同一份藝人歸屬證據。
在後續驗收時，我還發現一個很重要的問題。
假設某個來源真正的 recording artist 是：
YOASOBI + Guest Artist
如果 review 只保存：
Guest Artist
然後系統又把這份資料當成「完整藝人名單」，就可能得到：
「沒有 YOASOBI，所以 excluded」
這會直接造成錯誤判定。
因此現在 review 會區分：
complete_for_policy
partial
unknown
而且保存的 artist credits 必須和來源中保存的 recording artist labels 完整、順序一致。
不能只取其中一部分。
這次恢復並重新檢查原本 13 筆 review 後，13 筆保存的 recording artist label 都明確包含 YOASOBI。
但是當時保存的 metadata evidence 並不足以證明「這一定是來源提供的完整合作藝人名單」。
因此這 13 筆現在全部標記為：
recording_artist_credit_scope = unknown
這個 unknown 很重要。
它代表：
「目前保存的證據有看到 YOASOBI，但不能額外宣稱已經證明完整 artist credits。」
只要證據明確包含 YOASOBI，仍然可以判定 included。
但是如果想用「名單裡沒有 YOASOBI」作為 excluded 的理由，就必須先證明名單是 complete_for_policy。
另外還有一個之前遇到的真實案例。
Spotify 資料裡有：
Lilas Ikuta
而 catalog 裡保存的名稱是：
Lilas
如果只是名稱不同，可能需要 alias。
但即使確認兩個名稱指的是同一位藝人，也不能進一步推論：
Lilas Ikuta 是 YOASOBI 成員
→ 所以她的個人作品全部算 YOASOBI
這是不成立的。
所以目前規則仍然是：
個人藝人不自動 roll up 成所屬團體。
重新執行後，這個案例共有 6 筆 Spotify event 被判定為 excluded。
這 6 筆也沒有因為 Day 12 新增 exact-ID review 而被錯誤改成 included。
把 13 筆 exact source-item evidence 套回完整的 116,605 筆音樂事件後：
我的 YouTube Music：
15,403 筆輸入
302 included
0 excluded
15,101 unresolved
目前 resolved coverage 約為：
1.96%
朋友的 Spotify：
101,202 筆輸入
422 included
6 excluded
100,774 unresolved
目前 resolved coverage 約為：
0.42%
這裡最容易誤解的是 unresolved。
unresolved 不代表：
「這不是 YOASOBI。」
它真正代表的是：
「目前沒有足夠 evidence 可以判定。」
所以我不能把 15,101 筆 YouTube unresolved 全部當成非 YOASOBI。
同樣也不能把 100,774 筆 Spotify unresolved 當成其他藝人。
有。
後續我把 Day 12 當時使用的 13 筆 exact source-item review 與 metadata evidence 重新恢復，並建立可以重新執行的 evidence handoff。
重新套用目前的規則後：
YouTube：
302 → 302
Spotify：
422 → 422
included 數量都沒有改變。
而且 116,605 筆事件重新執行後，included、excluded、unresolved 的數量都和原結果一致。
但這次我也保留了一個限制。
當時保存的是 metadata evidence 的人工投影，不是完整保存的 HTTP response。
因此目前可以驗證：
「當時保存的 metadata 明確包含 YOASOBI。」
但不能進一步宣稱：
「已經由上游資料證明這 13 筆的完整合作藝人名單只有這些人。」
這也是為什麼它們的 completeness scope 現在保持 unknown。
原本看到同名、翻唱、Live、不同版本這些問題，很容易一路做成完整的 Track Identity 系統。
例如：
ISRC
錄音版本
Live / Studio
Remaster
MV / Audio
跨平台 recording mapping
但目前的目標其實不需要先完成這些。
Day 12 真正需要回答的是：
「這筆實際聆聽紀錄，有沒有足夠證據判斷 recording artist 是否包含 YOASOBI？」
因此 ISRC 仍然採按需使用。
只有某個實際 source item 發生錄音或版本歧義，而且這個歧義真的會改變判定結果時，才需要繼續查 ISRC。
這可以避免花大量時間建立一套目前還用不到的通用歌曲辨識系統。
目前最大的限制其實已經不是：
「能不能辨認 YOASOBI？」
而是：
「就算我知道自己有多少 YOASOBI activity，我要拿什麼和其他平台的人比較？」
YouTube Music Takeout 沒有提供每筆實際播放秒數，所以我的 302 筆目前仍然是 activity event。
不能偷偷把它改稱：
302 次完整播放。
也不能拿歌曲完整長度補成播放時間。
更不能直接把：
YouTube activity count
和：
ListenBrainz listen count
Last.fm scrobble count
假設成完全相同的東西。
所以 Day 13 要開始處理真正會決定這個專案能不能走到「跨平台排名」的問題：
把外部比較資料真正接進程式，並確認我的 YouTube Music activity 到底能不能和外部 listen / scrobble 放在同一個比較尺度上。
如果尺度根本不相容，那就算把剩下十幾萬筆紀錄全部辨認完成，也不會自動得到可信的跨平台排名。
這也是下一步真正需要先回答的問題。
iThome鐵人賽
看影片追技術