Re: [閒聊] 關於黑膠跟CD的差別

看板Headphone作者 (囧b)時間11年前 (2012/10/31 00:22), 編輯推噓43(43推 0噓 167→)
留言210則, 22人參與, 最新討論串4/5 (看更多)
※ 引述《Tosca (hi)》之銘言： : : → tsukie2887:要說CD直接放有差我相信，rip出來會有差只能說見鬼... 10/29 11:44 : : → tsukie2887:只要是同一份數位檔案壓出來的片子 rip下來的東西絕對 10/29 11:50 : : → tsukie2887:是一樣的 除非壓片瑕疵或讀取錯誤又沒校對... 10/29 11:51 : 關於這個話題其實以前我就想解釋一下 : 後來忘了 現在剛好順便一起討論 : 我並不是理工背景 : 所以只能簡單的就門外漢的認知來解釋 : 1.CD裡面真的是同一份數位檔案? : 讓我們來看個奇怪的事實 : 找一片"正統"的CD : 沒有附加檔案 CD-text等有的沒的 就最原始符合紅皮書的純音樂CD : 然後把他放進電腦光碟機 請問電腦會show甚麼?? : *.wav : or : *.aif : 答案是都對 看你是放進Windows還是Mac OS的電腦 : 所以奇妙的地方就來了 : 為什麼同一個檔案 放進不同作業系統卻是出現不同副檔名??? 我看不出來這個跟rip出來的結果有什麼關係 : 2.CD誕生於1982年 : 遠早於個人電腦 CD-ROM 還有windows作業系統 : 簡單的說 我們現在視之理所當然的數位檔案模式 除錯偵錯方式等 : 在CD上是根本不存在的 : CD是設計給CDP讀的 不是給電腦讀的!! : 這就是為什麼會有rip的問題 : 你只單純的把rip想成是copy 就太小看EAC等專業CD rip軟體的努力了 : 如果只是單純的把檔案複製 你用複製貼上就好 為什麼還要用EAC??? CD怎麼會只是設計給CDP讀，那我用這麼久的電腦CD-ROM都是假的? 如果你把rip想像的很強大、很玄，可以rip出什麼神奇的不同，那我真的要說R.I.P? : 3.就算是EAC 正確設定使用 也難保你rip出來的檔案是"正確"的 : 所以才會有AccurateRip資料庫 : 把你rip出來的CD資料跟全世界別人rip的比對 : 來確定你rip出來是正確的 : 總之CD rip的準確度遠比大家以為的不精準 : 所以才有這麼多努力希望可以更佳的rip出CD : 說到底還是CD本來就不是要給電腦讀的.... 什麼是正確，跟一群人一樣就是正確?正確這名詞也未免太狹隘了 AccurateRip這東西只能確保你跟大家都一樣 EAC只能說是一個比較嚴謹的tool，rip出來一整段錯了一個bit，會發生什麼事情 這問題跟你的手機上網錯了一個bit，會造成你網頁整片變成亂碼嗎? 我是理工人，這事情很難跟你解釋 老實說 以理工人的觀點看起來，你用這幾個觀點來判斷事情，是逾越了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.34.60.240
→
10/31 00:26, , 1F
EAC RIP出來的 0 1 ，不就和從光碟讀到的一樣?
10/31 00:26, 1F
推
10/31 00:27, , 2F
只能推了
10/31 00:27, 2F
推
10/31 00:30, , 3F
數位訊源端的差異鳩竟是怎麼來的真的很有趣啊....
10/31 00:30, 3F
推
10/31 00:31, , 4F
對電腦而言 會有一定的容錯性 所以真的有可能讀出來的
10/31 00:31, 4F
→
10/31 00:31, , 5F
不一樣
10/31 00:31, 5F
→
10/31 00:32, , 6F
我想不透為什麼Apollo CDP跟三爽牌藍光撥放器當轉盤
10/31 00:32, 6F
→
10/31 00:32, , 7F
聲音會不一樣 但他真的發生了...
10/31 00:32, 7F
推
10/31 00:36, , 8F
對電腦而言 3.9999999(不一定多少位 = 4 但是對聲音
10/31 00:36, 8F
→
10/31 00:36, , 9F
不是這麼一回事
10/31 00:36, 9F
→
10/31 00:37, , 10F
但是如果從 檔案 來看是可以被視為一樣 但是訊號就不行
10/31 00:37, 10F
→
10/31 00:38, , 11F
所以萬一EAC讀錯一個BIT 有可能他會判定成沒有讀錯
10/31 00:38, 11F
→
10/31 00:38, , 12F
跟網路上其他人比較出來如果一樣 其實微觀來說可能
10/31 00:38, 12F
→
10/31 00:39, , 13F
是不一樣的 端看那個檢查碼到底有多強
10/31 00:39, 13F
推
10/31 00:39, , 14F
但是數位邏輯電路對noise的recover能力很強 理論上在達到
10/31 00:39, 14F
→
10/31 00:39, , 15F
輸出時影響應該會降到最低
10/31 00:39, 15F
→
10/31 00:39, , 16F
再強都不是100%......
10/31 00:39, 16F
→
10/31 00:40, , 17F
對他而言 沒錯 = 邏輯無衝突 =/= 跟最初一樣
10/31 00:40, 17F
→
10/31 00:41, , 18F
CMOS電路可以將訊號recover到幾乎理想值... 搞不好比最初
10/31 00:41, 18F
→
10/31 00:41, , 19F
輸出還乾淨
10/31 00:41, 19F
推
10/31 00:42, , 20F
偏偏乾淨可能是失真XDDD 說不定原始檔案就是那樣髒髒的
10/31 00:42, 20F
→
10/31 00:43, , 21F
理想值也只是定義而已 再聲音這種很難給定義的東西上
10/31 00:43, 21F
→
10/31 00:43, , 22F
基本上可能還是有極限的
10/31 00:43, 22F
推
10/31 00:45, , 23F
有點不懂樓上說甚麼XD
10/31 00:45, 23F
→
10/31 00:46, , 24F
我怎麼想都不會是"髒"與"乾淨"的分別
10/31 00:46, 24F
→
10/31 00:47, , 25F
noise對電平的影響幾乎是0 我覺得比較有可能的是jitter,
10/31 00:47, 25F
推
10/31 00:48, , 26F
我講的是 對於正確 的定義問題
10/31 00:48, 26F
→
10/31 00:48, , 27F
propagation slew rate, 混和訊號資料轉換器(DAC)中的
10/31 00:48, 27F
→
10/31 00:48, , 28F
電源處理
10/31 00:48, 28F
推
10/31 00:51, , 29F
我贊同d大的看法..數位訊源聽起來不同的原因是jitter、機器
10/31 00:51, 29F
→
10/31 00:52, , 30F
運作產生的雜訊影響數類轉換的類比訊號..與01序列的正確性
10/31 00:52, 30F
→
10/31 00:52, , 31F
無關..
10/31 00:52, 31F
→
10/31 00:53, , 32F
那在硬碟中的磁氣訊號是接近完美的0 和 1 ???
10/31 00:53, 32F
→
10/31 00:54, , 33F
正確性應該是沒什麼好爭論的問題了 我覺得
10/31 00:54, 33F
→
10/31 00:55, , 34F
講到完美的0跟1 的確沒甚麼好爭論 硬碟讀出來的訊號 最後
10/31 00:55, 34F
→
10/31 00:56, , 35F
也會被復原 要講正確性 絕對不是縱軸的電壓magnitude
10/31 00:56, 35F
推
10/31 00:56, , 36F
基本上訊號原本身絕對就是01的改變沒錯 但實際上輸出是
10/31 00:56, 36F
→
10/31 00:57, , 37F
管你傳播過程中是邏輯0.000001還是邏輯0.9999999
10/31 00:57, 37F
→
10/31 00:57, , 38F
電壓 那就一定會有time delay、amplitude的微小變動
10/31 00:57, 38F
→
10/31 00:58, , 39F
既然電壓都有微微的改變 那在推動耳機音圈確實可能造成
10/31 00:58, 39F
還有 131 則推文
→
10/31 15:17, , 171F
高頻清晰，低頻模糊，聽起來就是虛? 請問虛跟模糊的關係
10/31 15:17, 171F
推
10/31 15:36, , 172F
10/31 15:36, 172F
→
10/31 15:36, , 173F
這個網站寫的好像不錯，比較有實作的樣式。
10/31 15:36, 173F
→
10/31 15:36, , 174F
一般來說使用外接word clock目的就是降低jitter
10/31 15:36, 174F
→
10/31 15:37, , 175F
幾乎毫無例外的比較好的方向都是背景變黑，音色便真實飽滿
10/31 15:37, 175F
→
10/31 15:37, , 176F
毛邊變少，音場變大，頻寬拉開。所以說是整體性的變化
10/31 15:37, 176F
→
10/31 15:38, , 177F
所以要說Jitter聽起來怎樣?因為是整體性的變化也很難說明
10/31 15:38, 177F
→
10/31 15:39, , 178F
至於頻段削弱是一種聽覺的遮蔽效應
10/31 15:39, 178F
→
10/31 15:40, , 179F
至於Noise對聲音的影響除了Jitter之外，P900是說會造成
10/31 15:40, 179F
→
10/31 15:40, , 180F
noise margin容許內可辨識的可用信號比例降低
10/31 15:40, 180F
→
10/31 15:40, , 181F
此時偵錯運算或重傳介入。不知道您是否同意?
10/31 15:40, 181F
推
10/31 15:45, , 182F
偵錯運算或重傳介入在data是沒問題，在audio stream就慘
10/31 15:45, 182F
→
10/31 16:01, , 183F
同意 完全同意 不過我是在講Data的部分
10/31 16:01, 183F
→
10/31 16:02, , 184F
頻段削弱我還是不懂怎麼回事 聽覺遮蔽跟我想得似乎不一樣
10/31 16:02, 184F
→
10/31 16:03, , 185F
即時的audio streaming思考是比較接近類比的
10/31 16:03, 185F
→
10/31 16:05, , 186F
Jitter這種東西是大江東去不復返 如同我前述audio CD能
10/31 16:05, 186F
→
10/31 16:05, , 187F
保證的就是讀到的stream而已 你硬要給他一個external clock
10/31 16:05, 187F
→
10/31 16:06, , 188F
聽感變好是真的，但是否為原意，這有待討論
10/31 16:06, 188F
→
10/31 16:07, , 189F
Again，回到一句老話，CD能保證的就是bit stream而已
10/31 16:07, 189F
→
10/31 16:08, , 190F
jitter只要在可讀取範圍內，你後續要怎麼修正這個bit strea
10/31 16:08, 190F
→
10/31 16:09, , 191F
m的波形，當然可以去修正，大家開心就
10/31 16:09, 191F
推
10/31 16:09, , 192F
另外關於Jitter之前那個playback design 的老闆來台灣受訪
10/31 16:09, 192F
→
10/31 16:09, , 193F
還講到Jitter有分好的跟壞的，應該是在講高斯跟非高斯
10/31 16:09, 193F
推
10/31 16:31, , 194F
Jitter都是壞的，只是有些是設計上可避免的，有些是不可避
10/31 16:31, 194F
→
10/31 16:31, , 195F
高斯是指高斯分布，是指熱雜訊造成的Jitter
10/31 16:31, 195F
推
10/31 16:37, , 196F
說真的我也很好其他的理論，他說ADC留下來的Jitter DAC
10/31 16:37, 196F
→
10/31 16:38, , 197F
可以用她的Jitter抵銷，看了還真的覺得太誇張
10/31 16:38, 197F
推
10/31 16:58, , 198F
外接word clock基本上是錄音室產品，原本不是用在家用
10/31 16:58, 198F
→
10/31 16:59, , 199F
可以接在任何數位介面，只是後來大家覺得可以用在CDP
10/31 16:59, 199F
→
10/31 20:21, , 200F
數位傳輸是調變過的類比信號，只要在接收端允許的容許範圍
10/31 20:21, 200F
→
10/31 20:21, , 201F
內，資料都可以解回來，但是這之中如果線材很爛，阻抗不匹
10/31 20:21, 201F
→
10/31 20:23, , 202F
配，信號可能就變很爛，輕則BER提高，重則產生輻射干擾
10/31 20:23, 202F
→
10/31 20:24, , 203F
再者，信號有data內含clk的，也有額外傳輸ref clk的，
10/31 20:24, 203F
→
10/31 20:24, , 204F
後段數位解調是基於哪一種也有差別，串列型的通常是編碼
10/31 20:24, 204F
→
10/31 20:25, , 205F
內含clk，傳輸中若是信號爛，還原的clk可能也跟著爛，
10/31 20:25, 205F
→
10/31 20:25, , 206F
至於結果...一樣輕則BER提高，重則一路汙染到後面去
10/31 20:25, 206F
→
10/31 20:27, , 207F
信號直接傳輸01對應的都是早期很慢速的界面了...
10/31 20:27, 207F
→
11/01 16:04, , 208F
看到用『理工人』來教訓人的口氣就要噓你了
11/01 16:04, 208F
→
11/01 16:05, , 209F
拿出真本事來把你認為對的邏輯講清楚一點吧
11/01 16:05, 209F
→
11/01 23:33, , 210F
謝謝指教
11/01 23:33, 210F
‣ 更多 orzguy 的文章
文章代碼(AID): #1GZ_xAPy (Headphone)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 4 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 orzguy 的文章
文章代碼(AID): #1GZ_xAPy (Headphone)