Re: [心得] 分享我自己的示範測試曲目

看板Headphone作者 (吉爾摩)時間4年前 (2019/07/15 03:42), 4年前編輯推噓0(0推 0噓 1→)
留言1則, 1人參與, 4年前最新討論串2/2 (看更多)
前面這篇討論用youtube檔案做測試， https://www.ptt.cc/bbs/Headphone/M.1563032436.A.602.html 看到底下推文說「每次youtube下載的檔案都一樣」， 我基本上也是這樣認為的，畢竟我想不到為什麼需要改用戶的檔案， 無利可圖而且應該也沒有這樣的使用權利 （除非政府要求？呵呵） 但心血來潮想說找點證據，確定這個說法， 先附上一點結果好了， 雖然背後有很多的假設，當作拋磚引玉好惹， 求強者解釋各種container的差異，之類的 -- 測試影片：https://www.youtube.com/watch?v=ev3ZkXxf4QQ
題外話，這個頻道找來的樂手也很專業，medley都做的很不錯， 小弟不愛Queen都聽了好幾次Queen的Medley 我是用youtube-dl寫腳本選格式以及下載，以及各種設定， youtube-dl支援各大網站，又是open-source， 不太需要擔心後門，順手推薦一下呵呵 -- 格式列表：https://imgur.com/dwxeon2.jpg
以這部影片來說，音樂的格式最佳是160k Opus， 影片最佳是1080p+3.2M bitrate，如果沒有指定的話， youtube-dl會幫你合成mkv或是mp4 以今天的目的來說，就抓160k opus以及m4a，抓個15次， 看看會不會檔案長一樣。 -- 比較結果：https://imgur.com/c75oFSa.jpg
這裡看到下載15次算出來的md5 checksum都長一樣， 加上我有把每個檔案xxd後diff交叉比對， 可以確定15次抓出來的檔案都是一樣的內容。 （md5是一種hash，hash是什麼有點難解釋， 但如果hash一樣，很高的機率輸入的檔案是長一樣的） （分享md5 checksum也可以讓版友驗證） -- 對這樣的結果大概還是有一些疑慮， 一些變數探討一下： 1. 我有傳--no-cache-dir跟--rm-cache-dir給youtube-dl， 所以基本上local應該是沒有被cache起來， 但server端那裡我無從得知 2. 這邊我有指定要怎樣的格式跟怎樣品質的檔案， 但瀏覽器跟各種youtube app我相信有各種優化， 不一定同一段影片被串流的是同一個檔案 3. youtube-dl有沒有做error-correction我不知道， 裡頭用的api也不確定是不是跟串流一樣， 比如youtube-dl -F拉出來的清單是不是跟網頁看到的一樣 （可能有空翻翻source code或是哪位大神可以解釋一下ㄇ） -- 最後補充一下，即使上傳的人寫說是320k的檔案， 比如這個頻道宣稱上傳FLAC的無損檔案， https://www.youtube.com/watch?v=7zrtbG4ZJrE
先不討論container能不能放flac進去， 看看youtube-dl撈出來可以下載的選項： https://imgur.com/1EyCLT7.jpg
裡面聲音只有一個選項：m4a 128kbps， 即使是1080p也只能搭配這個檔案， 總之影片的標題參考就好～ （哈哈聽個歌這麼多要考證） 以上 -- -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 71.61.178.166 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1563133339.A.A1F.html ※ 編輯: iaminanl (71.61.178.166 美國), 07/15/2019 04:00:13
推
07/15 08:44, 4年前 , 1F
推實驗精神
07/15 08:44, 1F
推
07/15 10:34, 4年前 , 2F
讚喔，原來128k的音質就很好聽了，我今晚要把檔案
07/15 10:34, 2F
→
07/15 10:34, 4年前 , 3F
全轉成128
07/15 10:34, 3F
→
07/15 10:45, 4年前 , 4F
這玄學我不加入任何立場，但我想提醒樓上
07/15 10:45, 4F
→
07/15 10:45, 4年前 , 5F
直接轉128好像是不一樣的
07/15 10:45, 5F
→
07/15 10:46, 4年前 , 6F
上傳YOUTUBE會被YOUTUBE壓縮，怎個壓法我不知道
07/15 10:46, 6F
→
07/15 10:47, 4年前 , 7F
然後下載時，再將YOUTUBE影片的聲音以128壓縮
07/15 10:47, 7F
→
07/15 10:48, 4年前 , 8F
應該是這樣或更複雜的過程，不單單是原檔轉128
07/15 10:48, 8F
→
07/15 10:48, 4年前 , 9F
這是我的推測
07/15 10:48, 9F
→
07/15 10:55, 4年前 , 10F
應該是原始檔案上傳後，就被壓縮成128Kbps，觀看或
07/15 10:55, 10F
→
07/15 10:55, 4年前 , 11F
下載時，直接下載被壓縮的128Kbps檔案，伺服器資源
07/15 10:55, 11F
→
07/15 10:55, 4年前 , 12F
有限，沒必要壓兩次
07/15 10:55, 12F
推
07/15 11:30, 4年前 , 13F
客戶上傳給youtube，然後被youtube壓縮的那個音樂
07/15 11:30, 13F
→
07/15 11:30, 4年前 , 14F
以直接下載得到呀？
07/15 11:30, 14F
→
07/15 11:31, 4年前 , 15F
那個音樂檔可以直接下載得到呀? (我的字被手機APP吃
07/15 11:31, 15F
上傳後有沒有壓縮我不知道， 但通常data center裡面不會直接存原檔， 大量的dedup應該是基本的～ （deduplication簡單說就是把所有檔案中，重複的區塊算出來， 然後只存一份這樣，反正還原的時候找的到就好） 下載檔案的流程可能是這樣： 1. client先跟server要這隻影片各種品質的清單 2. client決定影片（無音樂）的品質 3. client決定音樂的品質 4. client拿到影片（無音樂）＋音樂 5. client本地合成 第4.步應該就是根據dedup的metadata拿到真正檔案的chunks， 然後把chunks還原成檔案，回傳給client這樣 但你可以拿到什麼品質的檔案是第1.步就決定的， 清單上沒有的你基本上拿不到， 畢竟有可能上傳時的品質就不是最好 另外這篇文章用到的兩個影片， 可以看到品質的清單不一樣， 清單在上傳時依據什麼生成， 應該就看youtube的設計吧 ※ 編輯: iaminanl (71.61.178.166 美國), 07/15/2019 12:31:09
推
07/15 13:16, 4年前 , 16F
所以client可拿到官方server直接提供的純音檔！！
07/15 13:16, 16F
→
07/15 13:18, 4年前 , 17F
純粹把官方server提供的純音檔交出來這樣
07/15 13:18, 17F
→
07/15 13:18, 4年前 , 18F
這樣的話，下載時就確實不用轉第二次囉
07/15 13:18, 18F
推
07/15 14:54, 4年前 , 19F
問題是純音檔也不見然是最初使用者上傳的那個檔案，
07/15 14:54, 19F
→
07/15 14:55, 4年前 , 20F
像你管這麼龐大的串流網站不可能不做壓縮的吧，只是
07/15 14:55, 20F
→
07/15 14:56, 4年前 , 21F
壓縮到什麼程度而已。
07/15 14:56, 21F
→
07/15 15:13, 4年前 , 22F
我本來只是想表達，恐怕壓縮不只一次
07/15 15:13, 22F
→
07/15 15:13, 4年前 , 23F
因為我本以為
07/15 15:13, 23F
→
07/15 15:13, 4年前 , 24F
1. 使用者上傳原檔
07/15 15:13, 24F
→
07/15 15:15, 4年前 , 25F
2. youtube壓縮後放進資料庫，變成壓縮檔1
07/15 15:15, 25F
→
07/15 15:17, 4年前 , 26F
這個壓縮檔1不是純音檔，是包裝給瀏覽器觀看用的
07/15 15:17, 26F
→
07/15 15:17, 4年前 , 27F
3. 第三方下載器拿到壓縮檔1，轉成MP3給client
07/15 15:17, 27F
→
07/15 15:18, 4年前 , 28F
我本來以為是這樣的流程，會至少轉2次檔
07/15 15:18, 28F
→
07/15 15:18, 4年前 , 29F
至於轉一次檔的音樂到底可不可以測設備，我不想探討
07/15 15:18, 29F
→
07/15 15:19, 4年前 , 30F
測試的人高興就好，我個人會想聽到CD以上的官方版本
07/15 15:19, 30F
→
07/15 15:19, 4年前 , 31F
至少是更接近發行者想給我們聽到的所有內容
07/15 15:19, 31F
→
07/15 15:22, 4年前 , 32F
不過就純測試兩個設備有沒有差異
07/15 15:22, 32F
→
07/15 15:22, 4年前 , 33F
我相信MP3 128是可以聽出兩套設備有差異的
07/15 15:22, 33F
→
07/15 15:23, 4年前 , 34F
但真的拿CD跟youtube比較，發現音色分離度都差蠻多
07/15 15:23, 34F
→
07/15 15:24, 4年前 , 35F
當然也不排除部份官方故意弄更爛的音質傳給youtube
07/15 15:24, 35F
推
07/15 17:09, 4年前 , 36F
4k呢
07/15 17:09, 36F
推
07/15 21:50, 4年前 , 37F
認真 推
07/15 21:50, 37F
4K，以這個影片來說：https://www.youtube.com/watch?v=93Sc4ekKcK8
可以下載的清單 https://imgur.com/pg3cw3o.jpg
-- 8K，以這個影片來說：https://www.youtube.com/watch?v=1La4QzGeaaQ
可以下載的清單： https://imgur.com/eydBerY.jpg
-- youtube本意是video hosting service， 要確保自己上傳的不會有任何更動， 那應該要找cloud storage service， 比如google drive或是onedrive 至於audio只是video的一部份， 根據youtube官方說明，可以上傳的container有這幾種 https://imgur.com/gR06Yao.jpg
就我對video container淺薄的認識， 不同的container會規範好audio的品質清單， 也就是說即使在Premiere之類的影片編輯軟體中， 你在project裡放入超高品質的音樂，做成影片， 輸出時還是只能選選那個container的audio格式， 所謂4K跟8K主要是說video裡每張frame的resolution， 跟audio沒有直接關連 而常見的container中， 應該只有MKV允許把自己想要的video跟audio打包， 不過風險就是client可能不認識MKV，或不認識MKV裡面的檔案， 我想這也是為什麼youtube不允許上傳MKV， 以免除server的安全疑慮 ※ 編輯: iaminanl (71.61.178.166 美國), 07/15/2019 22:34:07
→
07/16 10:12, 4年前 , 38F
mkv可以上傳的哦
07/16 10:12, 38F
‣ 更多 iaminanl 的文章
文章代碼(AID): #1TAuMReV (Headphone)
‣ 更多 iaminanl 的文章
文章代碼(AID): #1TAuMReV (Headphone)