※ 引述《mikemagic88 (Mikemagic88)》之銘言：
: 我認為在DAC以前的硬體設備沒有太大影響
: 主要是DAC端才是解碼 在這之前就是0101
: 0101最怕就是出錯 特別是到DAC的這段
: 你根本不知道問題會出在哪
: 到底是做封包就做錯了
: 還是中間訊號干擾 0101 反了
: 還是最後解碼端解錯了
關於0101出錯變成1010 在電腦科學上叫做flipping bits
看到這邊突然想到以前曾經讀過類似的paper
https://stackoverflow.com/a/23587649/5082722
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/35162.pdf
有興趣可以細讀他的內容
大意就是IBM, Google 和 Cisco等大公司都對CPU cache與DRAM做過Error rate的研究
結果發現一般沒有揪錯能力的DRAM, 在連續使用下 8G RAM在一小時內會有1-5 bit error
造成錯誤的原因有可能是內部元件的電磁波, 或者該篇連結提到的宇宙射線
製程越小的, 產生flipping bits機會較高.
當然宇宙射線這段個人覺得在地球上發生的機率"應該"非常低, 在太空才需要考慮
但不可否認CPU cache跟一般DRAM都有一定機率發生flipping bits.
而且不限於PC, 有處理器跟暫存能力的機器應該都有機會發生.
所以Datacenter等Server才會採用ECC RAM來揪錯, 保證處理程序是用到對的資料
至於一般PC有時候跳出BSOD藍色死亡, 並不一定是Windows的錯XDD
一點淺見

我用 Fedora / Ubuntu / FreeBSD XDDD (亂入 :p)

ECC一樣會有位元翻轉，只是一般的ECC能修正單位元錯誤

所以用伺服器主機板加ECC RAM是比較好的選擇嗎？

哎呦，就版友也集資辦一場挑戰賽就結束的事（誤

原PO，能否幫忙算一下，多少 MB 會錯一個bit？一張CD 740MB，就可以知道多少張CD會錯1個bit(音?)了。

這不是這樣吧...每次獨立事件而且他是寫8gb 連續使用一小錯1-5。....所以他hazard rate是1-5/hour. 他沒給distribution 是啥...如果不是直線呢。 資料根本不夠怎麼算

沒人願意自己開編譯器，手動改一下pcm編碼，製造data error聽起來是什麼情況嗎聽過就會知道平常在講的聽感差異跟隨機data error是兩回事

我原本想說來個手動算算，然後馬上發現到，有很多變數要考量，所以我才請原PO試算。像是DRAM頻率或是CPU FSB頻率之類，還有DRAM參數，都要考慮連續一小時的BURN-IN，我也想過；不過就當在最槽的環境吧

話說都會藍屏了 應該不會只是聲音有變一點而已吧

隨機error出現的頻率那麼低絕對不是造成聽感差異的主因吧

我也估不出來一張CD的錯誤率會是多少XD原文是利用ECC-correctable error rates得到錯誤率的要估的話請個大大Donate一台server+ECC RAM XD

現在是說就算是flip bit 結果也不會是聲音問題而已。 這就有點像是說會干擾但不會影響聽感 鞥。

嗯嗯 我也是想說其實bit錯誤每天有機會發生在這上面糾結也無法改變

解應該會被發現然後整個封包丟掉，實際聽到應該會是聲音斷掉一下

斷掉 爆音 無感，總之不是平常討論的聲音差異

改 PCM 而已幹嘛開 compiler

音響迷討論的聲音差異跟0101是不是出錯無關

音響迷討論的聲音差異跟資料是否錯誤無關+1

簡單的說康康線在要壞不壞的時候 音樂雖然還能撥但會不定時爆音喔 那個就應該是封包掉了

不定時爆音不一定是封包炸了，有可能是clocking出問題之前做aac編碼有處理過類似問題

就零件要壞了而已

hi 編譯器是指修改工具，不是拿去做編譯啦

有人能聽到bit loss那也是真的神了我想請神耳來幫我們處理hilllock 最近em解的很辛苦

所以這篇是對的話 那一般的RAM error rate是1/2^36~5/2^36嗎 雖然我本來就不意外那麼低

人耳聽得到數據就神了；至少我聽不出來

那應該叫編輯器吧

哈，sry 筆誤