作者:
s25g5d4 (function(){})()
2025-05-09 00:42:59佩服你這麼無知還敢發文
: 音樂CD 的格式是 CDDA , 或許你不知道CDDA 的格式中, 資料或者稱frame,是包含
: checksum 的, 有checksum,就能檢測讀出來得資料是不是正確, 也能透過這個
: checksum 修復資料內容,這些不算什麼艱深的知識, wiki 查一下就有
: 我常用的ripper 是foobar 2000 , foobar 2000 有一個功能就是可以設定成
: 讀出來的frame 如果過不了checksum , 就重複再讀一次, 再錯,再讀, 如果一張
: 沒啥刮傷的光碟, 透過這個機制可以讀出正確無誤的光碟所有內容,我覺得EAC也是有
: 這個功能的
: 這也就是有正確設定此功能的網友, 讀出來的binrary 不論讀多少次都應該會是一模
: 一樣的, 用md5sum or sha256sum 去算會得到一樣的數位指紋
: wiki 很方便,你該多多使用
CD-DA 沒有檔案系統結構,只有一個接一個的 PCM 音訊流
開頭跟每一軌中間會有兩秒的靜音區間,用來標示曲目開頭與結束
CD-DA 只有有限的同步資訊
每個不同型號的 CD drive 都可能會有一點點時間讀取誤差
error correction 能力也比 CD-ROM 低非常多
就我看到的資料來說修正能力差了快兩倍
所以 CD-DA 至少會有以下幾個問題:
1. read offset jitter
由於沒有足夠的時間同步資訊,在維持定速讀取的情況下
同樣的時間應該有同樣大小的資料量,但現實世界是不完美的
如果讀取速度忽快忽慢、或是 DAC clock 有誤差,就會造成資料有多有少
那就必須砍掉或補假資料進去以滿足等速播放的需求
2. track offset
剛剛提到開頭、結尾跟曲目中間的靜音片段 lead in/out, gaps
每段大約兩秒鐘,而每個不同型號的 CD drive 讀取每一音軌時
可能會有一小段誤差,導致有些讀出來的音軌長一點、有些短一點
3. error detection
CDDA 原始用途根本不需要回報錯誤,只需 CD player 自行修正即可
所以早期的 CD drive 就是由韌體自動修正錯誤
無法修正就插值補假資料,再無法修正就乾脆靜音
軟體根本看不到錯誤的話,怎麼知道有讀取錯誤?
為了解決這些問題,較先進的光碟機會有一些額外功能:
1. Accurate Stream
針對 read offset/track offset 做修正,每次讀取都是固定的 offset
每個音軌開頭與結尾 offset 相同以解決 track offset
還有就像上面說的 CDDA 本身時間同步資訊有限
當軟體嘗試前後跳 n 個 frame 時,只有支援 Accurate Stream 的
CD drive 才能精準跳回同一個地方,從而保證重讀的 offset 都相同
2. C2 Error
當讀取發生不可修正錯誤時,透過 MMC 指令回報讀取錯誤
但是標準並沒有規定怎麼樣算是錯誤
所以這部分完全看各家韌體實作,有好有壞,不是一個可靠的指標
因此 EAC 的 secure mode 根本不看 C2 error
3. Cache Invalidation
不管是使用哪種軟體,只要是有強調 accurate rip 的軟體
他能做到精準讀取唯一的方法就是重讀幾次看看結果是否吻合
然而如果 CD drive 有做快取,那不管重讀幾次相同區塊都會是同樣的資料
就無從比對不同次讀取的資料是否都吻合
所以 CD drive 必須支援 cache invalidation,強制從 CD 重新讀取
EAC 當年會紅就是因為他的讀取演算法先進
對 CD drive 進階功能支援也完整
它可以做到沒有支援 Accrate Stream 的情況下修正 jitter
預設多次重讀以判斷是否有錯誤並修正
對於不支援 cache invalidation 的 CD drive
也可以透過把 buffer 寫滿強制清除原本要讀的區塊再重讀
就算 CD drive 都支援這些功能,也用了 EAC
仍然有可能遇到實體 CD 製作缺陷或刮傷或老化
所以才會有 AccurateRip 資料庫讓大家比對及上傳 rip hash
如果 rip 符合大部分人結果,那 rip 成功信心就越高
會把整件事情簡化成只要開 verify 就能做到 bit-to-bit perfect 讀取
完全是把十幾年前為了 rip CD 特挑光碟機
以及浪費時間開 EAC secure mode 慢慢讀追求完美
還有使用及貢獻 AccurateRip 資料庫的人當白癡