昨天，我得到第一個本人比較結果：在固定九個外部帳號加上我的十份紀錄集合中，我的八月 YOASOBI 已確認紀錄日數是30天，觀測排序第3／10。

這是一個很窄的結果。它沒有告訴我真正播放多久，也沒有回答全球排名。

今天想往前走兩步：把比較對象擴大，再讓這些計算變成我能直接使用的功能。

先補上一個重要更正

昨天曾出現「完整歷史第1～3位」的推論，這個區間必須撤回。

當時只考慮我的紀錄可能漏了一天，卻把外部帳號的日期數當成完整；但外部帳號也可能漏記，不能只讓我的數字變動。

所以可以保留的是「當時十份可見紀錄中的觀測第3／10」。完整歷史的順位和區間仍然未知。這個修正也成為今天擴大比較的前提。

35個候選帳號，25個有八月紀錄

我沿用當天已取得的官方資料與執行產物，重新核對整條選取與擷取流程。

這次候選集合來自幾個事先指定的 ListenBrainz 官方時間範圍返回名單，再加上先前保存的固定名單。先固定候選帳號，才取得各帳號在八月的紀錄，沒有看完分數再挑人。

最後一共有35個候選帳號。

其中三個帳號最初因逾時或分頁預算而沒抓完。這些帳號不能當成零，也不能偷偷刪掉。補抓後，整個候選集合才完成可見期間的掃描與核對。

按同一個 UTC 八月窗口、同一套外部藝人識別規則重新計算：

「觀測零值」只表示這份保存紀錄裡沒有符合條件的日期，不代表那個人實際完全没聽。

我的結果變成多少？

我這邊也從原始 Takeout 重新經過匯入和已保存的藝人署名證據計算，沒有直接把昨天報表的30寫進畫面。

八月仍是：

• 2,215筆音樂活動。
• 136筆依現有證據確認歸屬 YOASOBI。
• 2,079筆歸屬未決。
• 30個已確認日期。

把我放進25個外部正值帳號之中，結果是 觀測第3／26。

如果保留全部35個候選帳號，包括十個觀測零值，則是 第3／36。

兩個結果使用不同集合，所以必須同時交代分母，不能挑比較好看的那個數字。這次比我30天更多的仍然只有兩個帳號，各31天。比較對象增加了，觀測名次沒有改變。

這25個帳號也不能直接除以先前來源回報的2,189，就稱為全站覆蓋率。多期間返回名單的聯集，與那份歷史月度統計母體的精確交集尚未證明；它更不是全球聽眾的隨機樣本。

把這些結果接成能操作的工作室

到這裡，如果只多一份表格，使用上仍然要依賴聊天裡的附件和說明。

今天我把開發接到本機 Codex，沿用既有 Python 核心，做出第一版瀏覽器工作室。ChatGPT 先前保存的原始輸入與查證檔案也搬回本機，讓後續工作有可以重現的起點。

現在可以：

1. 匯入 YouTube Music 的 Takeout HTML，或 Spotify 的 ZIP／JSON。
2. 指定這份資料屬於誰，選擇 UTC 月份。
3. 查看來源活動、日期分布、曲目與藝人歸屬比例。
4. 切換正值群體或完整候選集合，查看比較範圍。
5. 打開某個曲目的判定說明，查看保存的署名與證據參照。
6. 匯出同一份計算結果的 HTML、JSON 或 CSV。

目前已覆核的目標藝人是 YOASOBI。「全部音樂」可以看來源活動回顧，但我沒有把它寫成已完成全藝人辨識。

來源曲目也仍依平台識別碼分開。兩首都叫同一個名字，不會因此被自動當成同一段錄音。

新檔案、錯月份和朋友的資料，也要能正確處理

我實際在瀏覽器匯入另一份合成資料，確認畫面會切換到新結果，並且明確標示合成性質，不讓它參與真實外部比較。

切到七月時，程式會說明目前外部快照只適用八月，而不是沿用八月的第3名。

朋友的 Spotify 也實際走過相同匯入與分析流程。它仍是朋友的資料，即使有來源提供的播放毫秒，也不會填進我的 YouTube Music 缺值裡。

這些操作讓我看見幾個純看報表不容易發現的問題。例如，最初 CSV 匯出把外部帳號的來源欄位沿用了個人的平台；還有覆蓋率物件在介面轉換時被顯示成未知。它們都需要修正，否則畫面上的數字正確，帶走的資料仍可能讓人誤解。

今天完成的範圍

現在有一個可以在本機打開的第一版：自己的原件、藝人證據、統計、外部快照與操作介面已接在一起。資料留在本機，核心計算不依賴外部 AI 呼叫。

但30個紀錄日，仍不能回答我真正聽了多少分鐘。同一天出現一筆與一百筆，都可能只計成一天。擴大帳號集合，改善的是比較對象，不能自動補足測量本身。

接下來要讓這個流程更好用、更容易重現，同時繼續檢查能否取得更有意義且相容的測量。第一版工作室已經能操作；完整聆聽量與全球位置，仍是必須分開追蹤的研究問題。