Re: [轉錄][問卦] 有沒有玻璃 CD 的八卦 ??

看板CD-R (光碟燒錄)作者dewenhsu (dewen)時間17年前 (2008/11/03 20:25)推噓0(0推 0噓 1→)

留言1則, 1人參與討論串1/1

※ [本文轉錄自 clmusic 看板] 作者: dewenhsu (dewen) 看板: clmusic 標題: Re: [轉錄][問卦] 有沒有玻璃 CD 的八卦 ?? 時間: Thu Oct 30 10:04:42 2008 ※ 引述《Volodos (Volodos)》之銘言： : 至於有人會問, "為什麼光碟存資料只能存比較少 (我也忘了幾 MB) : 可是存音樂比較多, 所以是不是音樂 CD 有錯比較不能檢察出來, : 因為音樂 CD 的檢查碼會比較少" : 基本上這是個錯誤的前設, 音樂 CD 的規格上, 錯誤檢查碼還比較多 : 會有這個結果是因為, 一般資料的存法跟音樂 CD 的存法不同 : 簡單的說是, 一般資料的存法上, 需要比較多空間去寫一堆跟資料無關的訊息 : 這部份要看 fat32 之類的檔案儲存格式 : 一般作業系統的書都會有 : 如果覺得全台大專院校用的作業系統的聖經恐龍書內容不夠 (也是真的不夠 @@) : Bach 有寫一本白色硬皮的書 (呃...此 Bach 非彼 Bach) : 雖然他裡面是說 unix-like OS 的檔案結構 (就是一堆 i-node 的規格) : 不過道理差不多, 至少可以解釋為什麼 CD 中 : 音樂格式可以存比較多資料, 一般資料只能存比較少, 的這個問題有興趣可以看一下這篇, 講的還蠻清楚的 http://www.pepo.cn/page/info/info.aspx?id=56083&pages=1 Audio CD 是依照 Red Book 的規範, 每個 Block ( Sector ) 是 2352 byte, 裡面儲存的全是 PCM 編碼的音頻數據. Data CD ( CD-ROM ) 則是依照黃皮書的規範 ( ISO 9660 ), 在每個 Sector 裡面的 2352 byte 裡面, 有加入 Sync, ECC, CRC ( 同步, 揪錯, 校驗 ) 的額外資料, 所以對資料的存取會比 Audio CD 來的精準, 但是相對的每個 Sector 能放的資料會比 Audio CD 來的少. 每個 Block 有 92 個 Frame, 也就是每個 Frame 有 24 byte, 這些 byte 要轉變成 CD 上實體的 pit & land ( 坑洞 ) 時, 必須經過兩種編碼的過程 : CIRC編碼 : 保證信息的邏輯正確性 ( 含 C1 & C2 各 4 byte 的糾錯碼, 1 byte 的 sub-code 控制碼 ) EFM編碼 : 提供物理讀取/寫入的信號識別可靠性因為 Audio CD 也有用到這兩種編碼機制, 所以它其實也是有糾錯機制, 只是沒有像 Data CD 在每個 Sector 又加入 ECC CRC 那樣的嚴謹, 所以 Audio CD 發生讀取錯誤的機率會比 Data CD 來的高, : 所以才會有說, 如果什麼穿透率高會讀取的比較正確之類 : 但我記得現在有的 cd-player 會有 buffer : 所以這種情形下, 不管用什麼燒錄片或什麼片, 應該是一樣的 : 也就是說 : CD 要播放, 分為 : 1. 將 CD 的資料讀出來, 以及 : 2. 將數位轉成類比 : 2 的部份不討論下, 我覺得 1 的問題要處理是沒那麼複雜 : 這年頭 ram 那麼便宜, 做個 1G 的 ram 也不是什麼難事與播放 Audio CD rip ( 抓音軌 ) 遇到錯誤可以利用上述 C1 C2 編碼糾錯方式來重複讀取, 直到確定資料 100% 正確,. Rip 到硬碟的儲存格式 ( eg. NTFS ) 會比 Audio CD 紅皮書更加嚴謹, 所以對數位資料的保存而言, 是更好的方式, 將來有一天可能會取代 CD 也說不定 ? CD Player 因為是即時播放, 只有一次讀取機會, 明明知道讀錯了, 也沒有機會重來, 高級的 CD Player 就是在電路方面下功夫, 盡量把這種讀取錯誤的機率降低或是掩蓋掉. 玻璃 CD 應該是一種商業噱頭, ( 穿透性佳也許對降低 jitter 有幫助 ? 有人用 CDSpeed 實測過嗎 ? ) 不過保存性佳是事實, 拿來當展示品也不錯, 比較擔心的是不慎打破了會不會 "心碎" ? ( 有錢人也許沒差 ) 用防彈玻璃或是施華洛士奇水晶來做會不會更好 ? 據說這種 CD 還是手工弄出來的 ? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.134.119.141 ※ 編輯: dewenhsu 來自: 220.134.119.141 (10/30 10:24)