xgiovio/dvdisaster
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Imported Upstream version 0.79.2

Browse Source
This commit is contained in:
Rogério Brito
2010-11-06 20:36:40 -02:00
parent 294f8623c4
commit 555c0daf7d
855 changed files with 28909 additions and 12770 deletions
Download Patch File Download Diff File Expand all files Collapse all files

129
documentation/en/qa_pipo.html
View File

@@ -1,7 +1,7 @@
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>dvdisaster</title>
<title>Questions and Answers</title>
<link rel="stylesheet" type="text/css" href="../include/dvdisaster.css">
</head>
<body>
@@ -11,7 +11,7 @@
<tr>
<td align="left">
<font size="+3"><b>dvdisaster</b></font>
<i>Version 0.72 (pl1)</i>
<i>Version 0.72.1 / 0.79 (devel-2)</i>
</td>
<td align="right">
<font size="+3">&nbsp;</font><a href="http://dvdisaster.net/en/">To the Internet version</a>
@@ -48,7 +48,6 @@
</table><p>
<table width="100%">
<tr><td colspan=3><font size="-1"><a href="news.html">News</a></font></td></tr>
<tr><td></td><td></td><td height="10"></td></tr>
<tr><td colspan=3><font size="-1"><a href="index.html">Overview</a></font></td></tr>
@@ -79,6 +78,8 @@
<a href="qa_pipo.html#pronounce">1.1 How is "dvdisaster" pronounced?</a><p>
<a href="qa_pipo.html#pipo">1.2 What are quality scans and why don't you support more?</a><p>
<a href="qa_pipo.html#compat">1.3 Is dvdisaster compatible with future releases?</a><p>
<a href="qa_pipo.html#eccpos">1.4 Augmented images have the error correction data appended at the end of the medium. Isn't that a bad choice?</a><p>
<a href="qa_pipo.html#recovery">1.5 What's the difference between image based and file based data recovery?</a><p>
<hr><p>
@@ -114,22 +115,138 @@ Yes, dvdisaster files are intended for an archival time of many years.
When upgrading to a newer version of dvdisaster you can continue using
images and error correction data created from previous versions.
There is <i>no</i> need to recreate them again.
<div align=right><a href="qa_pipo.html#top">&uarr;</a></div><p>
<b><a name="eccpos">1.4 Augmented images have the error correction data appended at the end of the medium. Isn't that a bad choice?</a></b><p>
No. First a bit of terminology:
If we augment 80 bytes of user data with 20 bytes of error correction
data, we get an "ecc block" comprised of 100 bytes.
Now take the following into consideration about the ecc block:
<ol>
<li>The position of the error correction data within the ecc block
does not matter.<p>
The RS decoder does not differentiate between
user data and error correction data. In the view of the RS decoder
our ecc block is a sequence of 100 bytes from which an arbitrary
subset of 20 bytes can be recovered. It can recover
the first 20 bytes, the last 20 bytes, or any
combination from within as long as the remaining 80 bytes
are still intact.
From this it follows that the position of the
ecc data within the ecc block does not matter; whether it is appended
at one end of the user data or is interleaved with it
has no influence on the error correcting capability.</li>
<li>Properly distributing the ecc block offsets influence of bad media spots.<p>
Optical media have a higher probability of failing in the outer area;
for technical reasons this is
the only place where the error correction data can be stored.
However this effect is offset
by distributing the ecc block content over the medium. Let's assume that our
medium is filled 80% with user data, leaving the remaining 20% free for
error correction data. Now consider the 100 byte ecc block again.
We need to pick 80 bytes from the user data for it and require 20
additional byte positions in the error correction data area.
Even under these constraints it is possible to evenly distribute the
100 bytes over the medium, from the
inside to the outside, each having a maximum distance to its neighbors.
Together with point (1), this negates the influence of bad spots on the
medium. Symmetry implies that for each error correction byte
stored in the (bad) outer region there will
be a user data byte located in the (good) inner medium region.
<p>
(If you do not already see the point, imagine putting the ecc data into
the inner medium region and the user data in the outer region. Consider
point (1) again to see that nothing changes with respect to the error
correction.)
</li>
</ol>
<div align=right><a href="qa_pipo.html#top">&uarr;</a></div><p>
<b><a name="recovery">1.5 What's the difference between image based and file based data recovery?</a></b><p>
Optical media are comprised of 2048 byte-wide sectors. Most of those sectors
are used to store file data, but some of them hold so-called "meta data",
e.g. information on directory folders.<br>
In figure 1.5.1 (below) there is
a directory "Pics" holding three files "forest.jpg", "rock.jpg" and
"protect.par"<a href="qa_pipo.html#note1"><sup>1)</sup></a>.
Note how these files are mapped onto physical sectors
(green/blue squares) on the medium,
and that an additional meta data sector (red square) is needed
for storing the "Pics" directory structure.<p>
<table width="100%"><tr><td align="center"><img src="images/metadata1.png"></td></tr></table><p>
<b>Shortcoming of file based recovery on optical media.</b><br>
Now let's assume that we are working with file based error correction.
The file "protect.par" holds error correction information which can be used
to recover unreadable sectors within the files "forest.jpg" and "rock.jpg".
This will only work as long as we need to recover sectors which are part
of a file. But if meta data sectors become unreadable, the
file based protection will collapse. Consider figure 1.5.2. When the
red directory sector becomes unreadable, not only the directory "Pics"
but also all files under "Pics" become inaccessible.
This is due to the logical structure of the ISO/UDF file system,
as there is no way to tell how the green and blue sectors relate
to files anymore when the directory is lost. So we have
a complete data loss although all sectors comprising the files
are still physically readable.<p>
<table width="100%"><tr><td align="center"><img src="images/metadata2.png"></td></tr></table><p>
<p>Please note that moving "protect.par" to a separate medium does not
rectify the problem - the directory block is still not recoverable as
it is not protected by the error correction data in "protect.par".<p>
<b>Advantages of image level recovery on optical media.</b><br>
dvdisaster applies an image level approach to error recovery.
The medium is read and processed as an ISO image.
The ISO image contains a sequence of all sectors found on
the medium, including those which are meta data for the file system.
Since the dvdisaster error correction data protects <i>all sectors</i> in the
ISO image, file contents as well as meta data sectors (e.g. directories)
can be restored. See fig. 1.5.3 for the different range of protection.
<table width="100%"><tr><td align="center"><img src="images/metadata3.png"></td></tr></table><p>
In addition, neither reading the damaged ISO image nor applying the
error correction requires any information from the file system
contained on the medium. As long as the
drive is still able to recognize the medium, dvdisaster will be able
to recover the still readable sectors from it. Therefore
there are no "single sectors of failure" as in the file based approach.
<table width="30%" cellpadding="0">
<tr bgcolor="#000000"><td><img width=1 height=1 alt=""></td></tr>
</table>
<a name="note1"><sup>1)</sup>
No offense intended against the PAR/PAR2 project.
Carsten is just confident that file based protection does not work
on optical media :-)</a>
<div align=right><a href="qa_pipo.html#top">&uarr;</a></div><p>
<!--- do not change below --->
</td> <!--- end of page contents --->
</tr>
<!---
<tr valign="bottom">
<td bgcolor="#f0f0f0">
<table cellpadding="10"><tr><td><a href="http://dvdisaster.net/legacy/en/index.html"><font size="-1">Old documentation (V0.70)</font></a></td></tr></table>
<table cellpadding="10"><tr><td><a href="http://dvdisaster.net/legacy/en/index.html"><font size="-1"></font></a></td></tr></table>
</td>
<td></td>
<td></td>
</tr>
--->
</table> <!--- end of main body table --->
@@ -142,7 +259,7 @@ There is <i>no</i> need to recreate them again.
<tr>
<td align="center">
<font size="-1">
<i> Copyright 2004-2009 Carsten Gnörlich.<br>
<i> Copyright 2004-2010 Carsten Gnörlich.<br>
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</i>
</font>