Re: [閒聊] 聊聊音樂格式

看板Headphone作者 (我是一隻小笨狗)時間11年前 (2013/03/18 12:05), 編輯推噓27(27推 0噓 96→)
留言123則, 15人參與, 最新討論串4/4 (看更多)
※ 引述《aegisty (桃型潛水艇)》之銘言： : ※ 引述《CeeLoGreen (希洛格林伊森)》之銘言： : : 大家應該都很注重音樂的品質吧 : : 現行除了無損之外 : : 大家都是聽哪些音樂格式呢？ : : 因為無損擋案真的好大喔XD : : 我現在大概都是320kbps mp3 : : 和一些在iTunes 買的AAC : : 想順便問一下哪種比較能有好的品質 : : 或是有推薦的新格式呢？ 其實聊到這個問題我也想藉題發問一下 有關數位rip的問題 大家都知道CD轉成的wav檔基本上是最好的，但先姑且不去討論到底wav、Flac 、APE 哪一種無損好，而是從CD讀取數位檔的問題 玩CDP的也會講求CD頭的型號，及裡面對於時差及震動的設計(即使不是價格太高昂的CDP) 還有很多細節，總之也是很厚功，而電腦的CD讀取機有Hi-fi到這種程度嗎? 假設不討論訊號經過電腦內部電路時造成的損害，光從電腦CD讀取成數位檔 到DAC進行播放，這樣不就等於用電腦的光碟盤當作CDT，就從這點音質可相信嗎? 不然討論什麼樣的數位檔，不就有點沒意義，就看誰變化的比較好聽罷了 還是音樂就是這一回事。 但也有人說，電腦也是可以用的發燒(弄得只能聽音樂的那種CAT玩家) 但這個成本也是不少，應該不會比一台中價位CDP便宜，且也不一定比較方便 以上就是我的疑惑，不知大家有沒有人這樣想過 以下個人看法關於 mp3 320K Vs Wav等無損 聽說在數位轉類比時(44.1khz,16bit)，在高頻區(20K以上) 會有邊際效應? 人耳亦有邊際效應 所以高頻衰減的很厲害，所以即使是mp3 320K 因為被截在20K 基本上就跟無損聽起來 應該不會有太大差異，但有些DAC會有演算法或軟體可以re-sampling 降低此邊界效應 那是否在人耳聽覺下會有差就不太清楚了.....印象中是有顯著差異的。 那wav 應該又比APE 此種來的好? 我想大概WAV電腦在讀取時應該耗用比較少的資源 (I Guess....) 因為APE用foobar Monkey 播放的時後也是要先轉碼成WAV才播放，但可能電腦夠好就不 顯著了 所以可能蘋果的器材播放AIFF ALAC 等他們自己弄得編碼也會比較好 吧(?) -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.195.216.164
推
03/18 12:19, , 1F
呃...前半段你可以查看看eac做了哪些努力
03/18 12:19, 1F
→
03/18 12:20, , 2F
後半段..這些無損格式聽起來就算差也不會是資料的差異
03/18 12:20, 2F
→
03/18 12:21, , 3F
無損壓縮就是還原時會完全相同 這跟mp3/aac是兩回事
03/18 12:21, 3F
→
03/18 12:22, , 4F
另外，聽力上你說的現象好像也不叫邊際效應..
03/18 12:22, 4F
推
03/18 12:38, , 5F
推一下本版#1Bqor-_d 當rip出來大家結果都一樣應該就ok了吧
03/18 12:38, 5F
→
03/18 12:44, , 6F
回樓上兩位大大，所以認為軟體可以解決硬體上不足的部分?
03/18 12:44, 6F
→
03/18 12:45, , 7F
回J大，我想強調的是，號用電腦資源較多這個部分
03/18 12:45, 7F
→
03/18 12:46, , 8F
不是還原後一不一樣的問題，在聽的時候她是邊聽就編轉換，
03/18 12:46, 8F
→
03/18 12:46, , 9F
不知道這樣會不會有差異，所以我也只是說,我猜
03/18 12:46, 9F
→
03/18 12:47, , 10F
可能不太會用專有名詞 抱歉，因為人耳雖設定在20-20K
03/18 12:47, 10F
→
03/18 12:48, , 11F
但在接近20K實並不是迅速delta function 掉落 而是在17k就
03/18 12:48, 11F
→
03/18 12:48, , 12F
已緩緩遞減，這我的意思
03/18 12:48, 12F
推
03/18 13:10, , 13F
這其實在各個不同領域的論壇戰過很多次…- -
03/18 13:10, 13F
推
03/18 13:15, , 14F
用EAC去rip 同一片每次rip出來的東西都會不一樣 用不同的電
03/18 13:15, 14F
→
03/18 13:16, , 15F
供RIP出來尤其顯著
03/18 13:16, 15F
推
03/18 14:10, , 16F
可以請問一下樓上是哪裡不一樣嗎?聽感?或是hash值?
03/18 14:10, 16F
推
03/18 14:32, , 17F
握聽到最明顯的是 MP3動態會被壓縮 尤其是錄音很好的
03/18 14:32, 17F
推
03/18 15:15, , 18F
只要accurate rip出來100%就代表你跟別人都一樣
03/18 15:15, 18F
→
03/18 15:15, , 19F
這樣應該就不太會有錯了 每一次都不一樣是你的CDP
03/18 15:15, 19F
→
03/18 15:16, , 20F
很可能有問題.......
03/18 15:16, 20F
推
03/18 17:07, , 21F
CD儲存的是數位資料 如果無法重現完整且正確的數位資料
03/18 17:07, 21F
→
03/18 17:07, , 22F
那是軟硬體的瑕疵
03/18 17:07, 22F
→
03/18 17:10, , 23F
要質疑(數位)無損格式的話 麻煩順便去質疑一下zip之類的
03/18 17:10, 23F
→
03/18 17:13, , 24F
當然真要探究的話 儲存成數位格式就已經是lossy
03/18 17:13, 24F
→
03/18 20:49, , 25F
所以我的疑惑就是在數位儲存的"過程"，我當然知道數位資料
03/18 20:49, 25F
→
03/18 20:50, , 26F
的正確性，但在讀取時的正確性才是我想了解的
03/18 20:50, 26F
→
03/18 20:50, , 27F
就像ispv大講的，不同設備同樣用EAC抓每一次其實都不大相
03/18 20:50, 27F
→
03/18 20:50, , 28F
同，難道要說是CD裡面儲存的檔案每次都不同?
03/18 20:50, 28F
→
03/18 20:54, , 29F
更不用講到如果用不同的CD雷射頭去讀會有什麼不同了
03/18 20:54, 29F
→
03/18 20:54, , 30F
難道我們也要怪說這是硬體設備上的....缺失?
03/18 20:54, 30F
推
03/18 21:02, , 31F
你試了沒? EAC每次抓每次data結果不同??
03/18 21:02, 31F
推
03/18 21:03, , 32F
樓上前提好像怪怪的XD hash這東西只要錯一個位元結果就不同了
03/18 21:03, 32F
→
03/18 21:03, , 33F
被搶先了 樓樓上才對
03/18 21:03, 33F
推
03/18 21:05, , 34F
我覺得他應該沒試過 他轉述的說法 我想對方是在講聽感
03/18 21:05, 34F
→
03/18 21:06, , 35F
心情不一樣
03/18 21:06, 35F
→
03/18 22:37, , 36F
這是信仰問題，管他別人怎麼說，我自己是認為EAC出來就沒有
03/18 22:37, 36F
→
03/18 22:38, , 37F
差別，那些什麼不同電腦rip出來聽感不同、上傳到網路再下載
03/18 22:38, 37F
→
03/18 22:39, , 38F
回來聽起來會不一樣、那些什麼數位資料相同轉成類比訊號後
03/18 22:39, 38F
→
03/18 22:40, , 39F
會不同之類的，對哥來說如浮雲~ 如浮雲啊~
03/18 22:40, 39F
還有 44 則推文
→
03/19 23:12, , 84F
直接破音 輕微的就是逼波一聲 嚴重的就是直接不能聽
03/19 23:12, 84F
→
03/19 23:13, , 85F
那實際上破音的情況多嗎? 最後 不要一直擴張解釋
03/19 23:13, 85F
→
03/19 23:14, , 86F
要討論的究竟是聽感還是data請先想清楚
03/19 23:14, 86F
推
03/20 02:08, , 87F
我想我要講的部分應該是不是DATA 我說容錯率高想表達
03/20 02:08, 87F
→
03/20 02:08, , 88F
的就是DATA層級的話其實都會正確
03/20 02:08, 88F
→
03/20 02:08, , 89F
可是即時撥放(REALTIME??) 就不能保證
03/20 02:08, 89F
→
03/20 02:09, , 90F
至於實際RIP出來幾次的問題 我手邊只有筆電CDR 倒是可
03/20 02:09, 90F
推
03/20 02:27, , 91F
以玩玩看 不過我倒是沒有器材就是了
03/20 02:27, 91F
→
03/20 06:31, , 92F
我無法理解什麼叫做不是Data？光碟讀出來的就是0101訊號
03/20 06:31, 92F
→
03/20 06:32, , 93F
除此之外沒有別的 這就是Data 而從灌程式來看Data的讀取
03/20 06:32, 93F
→
03/20 06:32, , 94F
準確度是非常非常非常高的 也就是光碟壞掉前 那個讀取頭
03/20 06:32, 94F
→
03/20 06:34, , 95F
讀出來的結果都會一模一樣 所以到底容錯率是只誰
03/20 06:34, 95F
推
03/20 09:38, , 96F
在我的理解中0101到data是有經過轉換的
03/20 09:38, 96F
→
03/20 09:39, , 97F
只是不輕處這關念對或錯
03/20 09:39, 97F
推
03/20 19:24, , 98F
所以你現在想討論的是data? 那EAC secure mode rip幾次
03/20 19:24, 98F
→
03/20 19:25, , 99F
看是不是真的每次都不同
03/20 19:25, 99F
推
03/20 19:37, , 100F
痾 應該說我認為DATA面是OK沒問題的 但是在串流撥放的
03/20 19:37, 100F
→
03/20 19:37, , 101F
時候可能會有變數
03/20 19:37, 101F
→
03/20 19:38, , 102F
痾 我不太清楚該怎麼表達 應該說 我覺得RIP起來對"DATA
03/20 19:38, 102F
→
03/20 19:38, , 103F
"可能真的可以一成不變 都是一模一樣
03/20 19:38, 103F
→
03/20 19:39, , 104F
就是CDT或CD-R讀出來的東西可能有超微小誤差
03/20 19:39, 104F
→
03/20 19:39, , 105F
這誤差對於電腦而言可以被CORRECT 所以RIP起來HASH都一
03/20 19:39, 105F
→
03/20 19:39, , 106F
樣
03/20 19:39, 106F
→
03/20 19:39, , 107F
可是對於直接送進DAC晶片而言就不一樣這樣
03/20 19:39, 107F
→
03/20 19:40, , 108F
恩 (連我自己都看不懂我在講啥) 我有空再研究看看
03/20 19:40, 108F
推
03/20 20:59, , 109F
你把手邊的wave用wordpad之類的硬開 再隨機亂改資料
03/20 20:59, 109F
→
03/20 20:59, , 110F
存回去聽看看 你就知道data error造成的結果有多嚴重
03/20 20:59, 110F
→
03/20 21:00, , 111F
那不是好不好聽的問題 是明顯的異常聲響
03/20 21:00, 111F
→
03/20 21:01, , 112F
更正 "notepad"
03/20 21:01, 112F
推
03/20 21:10, , 113F
如果你下個問題是 "那只要沒爆音 用捨麼當轉盤都沒差嗎"
03/20 21:10, 113F
→
03/20 21:11, , 114F
0101就是Data的最基本元素阿 任何的電腦Data都可以轉成0101
03/20 21:11, 114F
→
03/20 21:11, , 115F
我會跟你說 自己聽看看吧 看是不是都沒差
03/20 21:11, 115F
→
03/20 21:12, , 116F
因為電腦只懂0101 所以沒有什麼0101到data或data到0101
03/20 21:12, 116F
→
03/20 21:12, , 117F
剛發現用notepad硬開它會試圖組字 所以不能直接看機械碼
03/20 21:12, 117F
→
03/20 21:13, , 118F
也許他想講高階語言到機械碼的過程
03/20 21:13, 118F
推
03/21 00:16, , 119F
恩 我想等我想好我的疑問點在哪再來發文請益會比較有
03/21 00:16, 119F
→
03/21 00:16, , 120F
效率
03/21 00:16, 120F
→
03/21 00:16, , 121F
先感謝兩位
03/21 00:16, 121F
→
08/18 07:01, , 122F
我記得MSB還是哪家老 https://noxiv.com
08/18 07:01, 122F
→
10/05 05:58, , 123F
這是信仰問題，管他別人 https://daxiv.com
10/05 05:58, 123F
‣ 更多 max8201 的文章
文章代碼(AID): #1HHf9nCs (Headphone)
‣ 更多 max8201 的文章
文章代碼(AID): #1HHf9nCs (Headphone)