在燒影片或是資料時，常會有剩下一些空間沒有燒錄，
或是希望燒錄重要資料時可以減少損失，增加資料的安全性。
這時可以用ICE ECC建立偵錯還原檔，以減少資料毀損時的損失。
使用ICE ECC建立偵錯還原檔，儘管光碟有少量的讀取錯誤產生，
還是可以利用ICE ECC還原檔案出來，
這正符合了光碟毀損往往是先有部分毀損的狀況。
ICE ECC當然可以應用在光碟以外的地方，
像是資料在FTP傳輸時毀損，這個時候可以建立ECC檔傳輸過去，來復原資料。
而本文是以應用在光碟上面為主。
ICE ECC支援Unicode(內建瀏覽器不支援，但還是可以正常還原)。
支援多重目錄同時建立偵錯還原檔。
即使毀損偵錯還原檔，只要在許可範圍內，也是可以還原。
(詳細請看ICE ECC官網的偵錯還原機制，這必須使用Full test功能)
目前ICE ECC僅支援Microsoft Windows作業系統
ICE ECC官方網站
http://www.ice-graphics.com/ICEECC/IndexE.html
下載頁連結：
http://www.ice-graphics.com/ICEECC/DownloadE.html
============教學開始=======================
首先執行ICE ECC，並用內建的瀏覽器選取要建立還原偵錯檔的檔案
選取好要建立的檔案(目錄)按Create
輸入欲產生的ECC檔之檔名，並藉由調整Redundancy %(支援毀損多少%之毀損仍可還原)和Recovery Blocks的數量來調整ECC檔之大小。
最後Total size必須小於欲燒錄的光碟容量大小。
(視檔案數量多寡，有時還要縮小ECC檔案，以謄出空間在燒錄光碟時，製作檔案目錄等資料)
而Source Block Count會影響Redundancy%和Recovery Blocks的數量
Source Block Count越小，代表虛擬的ECC Block越大(下面的Block size就是一個ECC Block的大小)，
雖然Redundancy%會提升，但是因為一個ECC Block裡面有一個錯誤，就視同整個ECC Block錯誤，
所以ECC Block過大的話，會使得一個小錯誤，造成ICE ECC在還原時的困難。
個人習慣設定Source Block Count為4096，此時一個ECC Block約1MB大。
而還原檔案分割為6個的理由在於增加header的抗損性。
如果懶的計算容量大小的，可以使用右下角的Fit to,bytes，
有CD 650M、CD 700M、DVD和DVD Dual layer四個選項。
這邊要注意DVD是以DVD-R為容量來計算，使用DVD+R的必需減少一些Recovery Blocks的數量。
而DVD Dual layer則是以DVD+R DL為容量來計算，使用DVD-R DL的也必須減少Recovery Blocks的數量。
計算好後按OK就會開始執行，會顯示剩下約多少時間完成此任務。
此時可以按Pause暫停此任務，重複前面的動作來增加任務。
這樣就可以利用PC空閒的時間執行多個任務。
執行完畢後把要燒的檔案和ECC檔一起燒錄就可以了。
而要檢查光碟裡面的檔案是否完好，直接執行光碟裡面的ECC檔會直接啟動ICE ECC的Verify Only功能
若發現有錯誤時，執行ICE ECC後，使用Verify功能來還原錯誤，此時要指定ECC檔
之後要指定ECC檔的資料標的資料夾
然後指定還原檔案要放置的地方
然後就會開始執行
Full test和Fast test的使用流程和Verify相同，就不再加以說明了。
關於ICE ECC的4項檢查功能Verify、Verify Only、Full test和Fast test的差異
Verify：檢查並還原資料(如果資料有錯誤的話)，但是如果ECC檔有錯誤的話，會跳過ECC檔。
Verify Only：只有Verify的檢查資料功能
Full test：會根據ECC檔裡面所有的資料來檢查資料並還原資料，速度是這4種中最慢的。
Fast test：用CRC演算法的方式來偵錯還原資料，不會利用ICE ECC之前運算的內部資料來偵錯還原。
========欲轉貼請先通知作者================
光儲存相關 (3)
您好，先感謝您的文章讓我有更好保存資料的方式。 想與您請教的是，今日在光碟燒入完成後，立即使用Verify Only檢查，出現了 "Total bad blocks- 7"，請問這是在正常範圍內，還是因我的光碟品質或燒入環境較差的影響？
正常是不會出現Bad blocks，用CD Speed跑掃描光碟看看有沒有損壞的點... 有時是剛燒完沒有Close之類誤判所致，先檢查一下吧...
謝謝，測試後發現原來剛好那片是地雷= =
請問若是要燒BD-R那麼需要更改哪些設定？還是照你上面的設定就好？
就Total size拉高到近25G... 目前ICE ECC 2.7還沒有幫你計算到BD-R容量....SO....
Source Block Count 和Redundancy% 和Recovery Blocks 上面這三個參數也要拉高嗎？
Source Block Count <=這是看自己想要多大去設定的，動不動都無所謂 Redundancy%和Recovery Blocks這兩個是會連動 拉高以後Total size會變大，不要超過BD-R容量即可
請問有沒有較新的替代軟體呢？ ICE ECC 感覺好久沒有更新了
沒有，ICE ECC在Win7 x64下也可以正常運作，沒必要更新吧...
您好！ 請問要燒錄BD-R的話 Total size要如何調整呢？ 是在Fit to, bytes填上BD-R的容量大小嗎？ 程式裡Total size的容量單位是byte嗎？ 謝謝！
調整至25 020 000 000左右 是Byte沒錯
http://hp.vector.co.jp/authors/VA021385/ MultiPar也可以做到類似功能，目前還有更新 有內建藍光的選項
MultiPar沒記錯的話，是跟QuickPar一樣屬於Par/Par2這類的分支 Par/Par2的優勢Par是公開格式，所以今天QuickPar or MultiPar不支援了， 換另一個Par/Par2的程式照樣可以跑，不同平台都有支援Par/Par2的程式。 ICE ECC的ECC檔則非公開格式，ECC檔只能用ICE ECC去讀取，ICE ECC也僅支援Windows 劣勢則是Par/Par2檔本身毀損的話，其毀損部分對應的Blocks就沒辦法還原 ICE ECC即使ECC檔有部分毀損，只要在許可範圍內，也是可以還原。 這點是個人偏好ICE ECC的主因。 另外就是ICE ECC個人測試，比測過的Par程式如QuickPar運算來的快， 同樣時間內，ICE ECC可以跑較多的偵錯還原檔。
那你有用過dvdisaster來當燒錄軟體嗎？ http://dvdisaster.net/en/index.html https://www.livebusinesschat.com/smf/index.php?topic=5339.0 看起來multipar是有在改善速度
之前用dvdisaster他是從光碟映像檔去做偵錯還原檔， 所以要燒在同一片光碟，要先做好光碟映像檔，然後再去做糾錯還原檔，之後再燒在一起 這樣要用的時候就必須先用虛擬光碟軟體掛載，增加一道手續。 如果不拘泥在同一片光碟，就變成A光碟的偵錯還原檔燒在B光碟，B光碟的偵錯還原檔燒在C光碟..... 這樣用光碟內容時是跟平常一樣，但是碟片有毀損要救援時就必須找到下一片，也是一種麻煩。 而記得那時看討論是說，dvdisaster的偵錯還原檔的抗毀損能力弱，建議是無損下使用， 所以原廠是建議使用後者的方式。 dvdisaster的優點是可以針對已有毀損的光碟做映像檔，方便救援。 multipar個人是還沒有測速度過，就如同前面所說，ICE ECC可以允許偵錯還原檔有毀損(或者說抗毀損能力較強)，所以目前仍使用ICE ECC。
我自己做測試，3.1g data ,207個檔 redundancy=7% ICE ECC要花1min 50s phpar2 要花2min 10s multipar 要花3min 40s
謝謝測試~~
http://www.quickpar.org.uk/AboutPAR2.htm 裡面有提到Damaged PAR files will still be useable. PAR 2.0 can use the undamaged parts of a PAR file par1.0確實是壞了就沒了
Par2毀損以後仍可以使用沒錯，之前看過的Par2抗毀損限制如下： 假設資料Block有B001~B100 而現在將Par2的偵錯還原檔分為10個部分，A01~A10 A01對應B001~B010，A02對應B011~B020...依此類推 今天光碟毀損，造成A05全部毀損， 毀損的資料如果在B041~B050的，就無法修復。 毀損的資料如果不在B041~B050的，假設在B022， 只要在設定的還原比率之內，那就可以救出。 ICE ECC則是用較複雜的運算，來避過這個問題。
http://www.harley.com/usenet/file-sharing/11-understanding-par2-files.html 以這個網頁來看，所需要的par file不是一對一的，是可以選的，加起來大於需要回復的即可
嗯~~以前測試時確實有掉檔就不能回復的問題...Orz 是演算法又改了嗎? 很久以前的討論也是這樣.. http://www.ptt.cc/bbs/CD-R/M.1189887084.A.E05.html
您好！有幾個問題想請教： 1. Source block count照著設4096，不過Block size不是1064390，是哪裡弄錯了嗎？ 2. Source block count設4096，Redundancy%自動帶入6點多，這個值有必要再拉高嗎？ 3. 燒錄時要把ICE ECC主程式燒進光碟嗎？沒有的話會不會沒辦法還原？ 4. 在製作時勾選Full test的意思是製作完ecc檔後馬上Full test嗎？
1.正常 2.我習慣都是燒滿該片 3.還原是用Windows下的ICE ECC程式 4.YES
不好意思，請問Source block count設4096但Block size不是1064390的原因是什麼呢？ L大都燒滿整片喔！可是碰到檔案只有12GB的話，ecc檔會是原檔整整一倍多耶！（BD25）
1.你嘗試用不同大小的檔案去做ECC看看就知道 2.我是想辦法塞相關東西進去
燒完後使用 Verify 檢測： File read error - E:\xxx\desktop.ini Damaged block - 78 都是 desktop.ini 出現這樣的訊息 然後 ICE ECC 居然就開始在指定的資料夾重建光碟內“所有的”檔案…囧rz 請問 L 大，這樣是正常的嗎？ 謝謝您！
文章中有 Verify：檢查並還原資料(如果資料有錯誤的話)，但是如果ECC檔有錯誤的話，會跳過ECC檔。 Verify Only：只有Verify的檢查資料功能 因為你已經有Damaged block - 78(desktop.ini系統檔你沒略過之故吧)，所以這很正常
L 大的意思是說那些 desktop.ini 是做 ECC 檔時一併做了 但燒錄的時候 desktop.ini 沒燒進去 所以才會 File read error 嗎？ 然後在 Verify 時才會復原所有資料 即使只是因為 desktop.ini 導致的 File read error（Damaged block）？ 看您的文章真的學到好多！ 謝謝您！
YES
也想請問 desktop.ini 和 Thumbs.db 之類的系統檔有辦法全部一起略過嗎？ 一個一個手動略過有難度…
去修改成不顯示隱藏檔/系統檔就可以了吧...? 我自己是做一個bat檔，要做壓縮檔或是燒錄之類動作前， 執行bat，把該資料匣下的所有Thumbs.db、 desktop.ini 砍掉...
請問要連ECC檔一起燒入BDR，那要怎麼預估ECC會佔用多大？ 常常產生ECC後發現超過25G一點點 Fit to byte 我是用25020000000
25020000000差不多，如果檔案數過多(例如都是小的圖檔) 那樣要降到25000000000...
您好 可問Total size 50gb 100gb大概要填多少了 感溫
上面的X2 & X4啊... 小擋多的話要縮點