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

New upstream version 0.79.5

Browse Source
This commit is contained in:
TANIGUCHI Takaki
2017-02-02 22:24:37 +09:00
parent 2f23ea4b4a
commit 9ad5d25d65
1931 changed files with 104660 additions and 254637 deletions
Download Patch File Download Diff File Expand all files Collapse all files

843
documentation/codec-specs/rs02.tex Normal file
View File

@@ -0,0 +1,843 @@
\newpage
\section{The RS02 codec}
This section describes the dvdisaster RS02 Reed-Solomon codec.
It was developed during the winter of 2005/2006 in order to facilitate
augmenting iso images directly with error correction data.
RS02 is based on the Reed-Solomon encoders and decoders
introduced with RS01, but focuses exclusively on augmenting
iso images. The allocation of data sectors within an ecc block
follows a similar scheme as in RS01. However the layout of the
parity bytes is vastly different between RS01 and RS02, as the codec must
cope with any parity sector being damaged or unreadable.
Consequently a RS02 image can lose as many sectors as
allowed by the redundancy of
the error correction data, and the lost sectors can be any
combination of data and parity sectors, as it is expected from
a Reed-Solomon scheme.
\smallskip
Unlike RS01, which will be completely superseded by RS03 soon,
the case of RS02 vs. RS03 still remains open, as both codecs
have their individual strengths. RS02 is slightly more space
efficient than RS03, so on CD media RS02 might provide
slightly more redundancy (typically one additional root) than RS03.
This effect will be less
pronounced on larger media like DVD and BD.
RS02 images can be augmented to an arbitrary size which may
be smaller than the maximum medium size, while RS03 requires
augmenting the image to the full medium size.
This might favour RS02 for working on images which are only
30\% or less of the medium size, as they can be encoded with
less than the maximum of 170 roots
(the maximum redundancy requires lots of time to compute, producing
a three-fold redundancy which may not be needed in all cases).
On the other hand RS03 will counter
the performance argument since it can encode at least
20 times faster than RS02 on multi-core architectures,
because RS02 encoding can not be parallelized.
See the end of section \ref{rs01} for a speed comparison of RS01 vs. RS03;
RS01 and RS02 are very similar performance-wise.
Finally, the data layout of RS03 does not depend on interspersed
ecc headers which gives it a better robustness over RS02;
see subsection \ref{layout-logical-two} for details.
\subsection{Physical layout}
\begin{figure}
\begin{center}
\includegraphics[width=10cm]{spiral-rs02.eps}
\caption{Physical RS02 layout}
\label{layout-phy-two}
\end{center}
\end{figure}
RS02 must be applied to the .iso image before it is written to
the medium. Additional sectors are appended to the .iso image
containing the parity data. The data structures of the .iso image
are not changed to reflect the new image size, so the original
part of the augmented .iso image remains untouched. The parity
sectors can be removed from the augmented image by simply
truncating the .iso image to its original sector size; the resulting
image file will have the same contents as prior to the augmentation.
As a side effect, the parity data is invisible to applications reading
the medium at the filesystem level, including most hardware media
players. If you find a player which gets confused by media containing
RS02 (or RS03) parity, please consider telling the dvdisaster project about it. As of this writing,
not a single device has been reported to run into problems with
the RS02 data scheme. The RS02 augmented image might conflict with
optical media writing software, though. If the writing software
decides the image length by looking at the iso filesystem structures,
the parity data portion of the image might not be written to the medium.
Most current writing programs do however measure the .iso image by examining
its file size, and will transfer the parity data correctly. To be sure you
should follow the steps described under ``Testing image compatibility''
at the dvdisaster site (\url{http://dvdisaster.net/en/howtos92.html}) once
before using each version of your optical media authoring software.
Like the other dvdisaster codecs, RS02 is based on a RS(255,k) Reed-Solomon code
with each ecc block being comprised of $n$ data bytes and $k$ parity bytes, and
$n+k=255$. The $n$ data bytes comprise the .iso image which will be
written to the medium, and the additional ecc header and CRC checksums added
by dvdisaster. Reed-Solomon encoding works best when errors are
distributed evenly over all ecc blocks. Therefore we must strive to distribute
the ecc blocks evenly over the medium surface. To facilitate such mapping,
dvdisaster logically divides the medium into 255 logical units which are called
``layers'' for historical reasons.
Figure \ref{layout-phy-two} shows how the medium is divided into $n$ data layers
and $k$ ecc layers, with $n + k = 255$. Ecc blocks are
created by taking on byte from each layer as shown in fig. \ref{layout-logical-two}
on the following page. This distributes the ecc block reasonably good over
the medium surface.
All layers have the same length in bytes, with the possible exception of
data layer $n$. As the .iso image size plus the size of one ecc header and the CRC data
is usually not a multiple of the layer size, the $n$-th data layer may be shorter
than the layer size and considered to be filled up with a virtual zero padding.
The zero padding is not written out to the augmented image (note that data layer $n$
is intentionally drawn shorter in fig. \ref{layout-phy-two}), but it is used in the
calculation of the respective parity bytes.
\newpage
\subsection{Logical layout}
\label{sec-layout-logical-two}
\begin{figure}
\begin{center}
\includegraphics[width=\textwidth]{rs02-layout.eps}
\caption{Logical RS02 layout}
\label{layout-logical-two}
\end{center}
\end{figure}
The data layout in the augmented image is shown in figure \ref{layout-logical-two}.
Note that in this figure the data is byte-indexed; e.g. $d_{1,1}$ denotes the
first data byte in the augmented image. Each layer has a length of
$ls$ bytes, with the exception of data layer $n$ which may be shortened (see subsection \ref{calc-two} for an exact calculation of its size).
Some ecc layers my be interleaved with redundant copies of the ecc header.
The ecc header size is not included in the respective ecc layer size.
\paragraph{Data layers.} A data layer index $d_{i,j}$ refers to the $i$-th byte in the $j$-th data layer.
The $n$ data layers are mapped in a linear fashion to the original iso image.
$d_{1,1}$ maps to the first .iso image byte, and $d_{ns,n}$ maps to the last .iso image
byte ($ns$ is the number of remaining iso image bytes in the $n$-th data layer).
The last data layer is special because it does not only contain the rest of the iso image,
but also the ecc header and the CRC checksums. These extensions
are logically treated as a part of the iso image; their contents are used in the
ecc data calculation and are therefore protected by the ecc data.
The ecc header follows immediately after byte $d_{ns,n}$ and is 4096 bytes long.
Its format is described in appendix \ref{eh}. For RS02, only the data fields
marked with ``all'' or ``RS02'' are relevant; all other fields should be set to zero.
Data layer $n$ does also contain the CRC32 checksums of each data sector
upto the ecc header. If the .iso image contains $s$ sectors,
then the CRC field contains $4s$ bytes, rounded up
to the nearest multiple of 2048.
CRC32 checksums are calculated over a whole CD sector comprising 2048 bytes.
Let $c_{y,j}$ be the 4-byte checksum of the $y$-th sector in the $j$-th layer
and $lss$ be the number of sectors in each layer.
Then $c_{y,j}$ = CRC32($d_{2048*y,j}$, $d_{2048*y+1,j}$, \dots, $d_{2048*y+2047,j}$).
$y_1$ is usually not the first sector in the layer, but a later sector.
In general, $y_i$ = $(i+offset)$ mod $lss$. The offset is introduced to restore
the CRC32 sums of ecc block $i+1$ during the correction of ecc block $i$.
This helps if the data portion of the image is corrupted with wrong byte values and
the sectors containing the CRC32 sums have been lost.
The error correction will start at the ecc block $i$ which is determined
by the offset, and whose CRC32 checksums are stored in the ecc header (at least one
ecc header will be recovered before any error correction can begin). Correcting
ecc block $i$ will recover the CRC32 checksums for ecc block $i+1$ in the image
(and possibly some more in advance, as less than 2048 bytes are required for
one set of checksums). This makes it possible to detect corrupted bytes by the
checksums and flag them as erasures which effectively doubles the error correction
capabilities of the Reed-Solomon code.
\paragraph{Ecc layers.} For an image augmented with $k$ roots, the parity bytes
will be spread over $k$ ecc layers. In order to calculate the first ecc block,
bytes $d_{1,1}$ to $d_{1,n}$ are taken from the $n$ data layers. The RS(255,k) code
is calculated (see appendix \ref{rs} for its parameters) and the resulting $k$
parity bytes $e_{1,1}$ to $e_{1,k}$ are stored in the $k$ ecc layers.
The next ecc blocks are calculated and stored accordingly; ecc block $i$
is marked grey in the figure.
Care must be taken to honour the non-linear mapping of
ecc layer bytes as the ecc area is interleaved with 20-40 copies of the ecc header.
The ecc header copies are placed at sector addresses whose numbers
are large powers of two. This makes it possible to heuristically search for them
during the decoding boot-strap process
when no other information (image size, layer size, etc.) is yet available.
See section \ref{search-two} on the search heuristics and section \ref{addressing-two}
on calculating ecc bytes positions from the non-linear mapping.
\subsection{Calculating the image layout for encoding}
The image layout can be either computed automatically to fill up
the medium as much as possible, or by user selected criteria such
as a maximum image size or a specified redundancy.
\subsubsection{Automatic layout calculation}
\label{calc-two}
The only available inputs to automatic layout detection are
the .iso image size and a table of maximum media sizes (see
tab. \ref{layout-size-table} in the RS03 section for the
respective values). From the media size table the smallest
possible medium is chosen which can contain the .iso image.
In some border cases, with e.g. the .iso image being only
100 sectors smaller than the medium capacity, the automatic
layout calculation will fail later due to insufficient space
on the medium. In such cases, the user must decide between
choosing the next larger medium size or splitting the image
contents onto two media by himself (splitting a 700MiB CD image
onto two CDs may be better than writing it to a DVD).
\smallskip
From now on, all calculations are given in numbers of 2048K
sectors or sectors addresses
unless noted otherwise. The number of sectors required for the
CRC checksums can be directly computed from the .iso image size:
\[
crc\; sectors = \left\lceil\frac{4 * iso\; image\; sectors}{2048}\right\rceil
\]
The total accumulated size of all data layers is the sum of the
.iso image size, the number of crc sectors and the two sectors required
for the ecc header. Since these sectors are protected by the parity,
they are called {\em protected sectors}:
\[protected\; sectors = iso\; image\; size + 2 + crc\; sectors\]
These calculations also produce two important sector addresses within
the augmented image:
\begin{itemize}
\item The sector with address {\em iso image size} marks the location
of the ecc header; and
\item The sector at address $iso\; image\; size + 2$ marks the beginning
of the CRC checksum data.
\end{itemize}
The next step is to partition the {\em protected sectors} and the remaining
medium space into an optimal layer size. It is carried out iteratively.
\smallskip
For an approximate start, we determine the free space on the medium:
\[free\; space = medium\; capacity - protected\; sectors\]
and estimate a preliminary value for the number of roots and data layers:
\[k\; roots = min\left(170, \quad\left\lfloor\frac{255 * free\; space}{medium\; capacity}\right\rfloor\right)\]
\[n\; data = 255 - k\; roots\]
The maximum number of roots is capped at 170 which is approximately a three-fold
redundancy. Larger values would get too computationally expensive.
\smallskip
The preliminary layer size is then:
\[preliminary\; layer\; size = \left\lceil\frac{protected\; sectors}{n\; data}\right\rceil\]
and the expected size of the parity layers is:
\[preliminary\; ecc\; size = k\; roots * preliminary\; layer\; size\]
\smallskip
From these values we iteratively compute a $2^p$ which has about 20-40 multiples
in the {\em preliminary ecc size} address space. This value will be used
for interleaving the ecc header copies with the ecc layers:
\smallskip
{\tt
p := 5
while($\frac{preliminary\;ecc\;size}{2^p} > 40$)
\quad p := p + 1}
\smallskip
Now the chosen values might be actually too big since we haven't taken
the ecc header copies into account.
So the final task is to add up the number pf parity sectors and ecc header
copies. If these fit into the free medium space, we are done; otherwise
the calculations are done again with one root less.
\newpage
\bigskip
while($n\; roots > 7$)
\smallskip
\quad $layer\; size := \left\lceil\frac{protected\; sectors}{n\; data}\right\rceil$
\smallskip
\quad $ecc\; size := n\; roots * layer\; size$
\smallskip
\quad $first\; ecc\; header\; repeat\; addr := \left\lceil\frac{protected\; sectors}{2^p}\right\rceil * 2^p$
\smallskip
\quad $space\; for\; interleaved\; sectors := protected\; sectors + ecc\; size - first\; ecc\; header\; repeat\; addr$
\smallskip
\quad $number\; of\; ecc\; copies := \left\lfloor\frac{space\; for\; interleaved\; sectors}{2^p - 2}\right\rfloor + 1$
\smallskip
\quad $total\; added\; sectors := 2 + crc\; sectors + ecc\; size + 2 * number\; of\; ecc\; copies$
\medskip
\quad If $iso\; image\; sectors + total\; added\; sectors < medium\; size$,
we have a valid layout: STOP.
\smallskip
\quad Otherwise, set $n\; roots := n\; roots - 1$ and $n\; data := 255 - n\; roots$
and do another iteration.
\medskip
The iteration will either terminate with a valid layout or fail when
$n\; roots$ drops below the minimum redundancy of 8 roots.
\subsubsection{Layout calculation by user selected criteria}
The user has several means of specifying a certain redundancy:
\paragraph{Specifying the maximum number of sectors for the augmented image.}
This case is simply handled by setting {\em medium capacity} to the user
selected sector size rather than using the maximum medium size from the
built-in table. Afterwards, calculations continue as described in
section \ref{calc-two}.
\paragraph{Specifying the number of roots to use.}
In this case we can skip the calculations for {\em free space} and
{\em k roots} as described in section \ref{calc-two}, and instead
set {\em k roots} directly to the user selected value. Then the
layout calculation proceeds as usual.
\paragraph{Specifying the percentage of redundancy to use.}
For a given number of {\em k roots}, the resulting redundancy in percent is:
\[\frac{k\; roots \cdot 100}{255 - k\; roots}\]
Pick a suitable value for {\em k roots} so that the user selected value
is met or slightly exceeded. Proceed with the given number of roots
as described in the previous paragraph.
\subsubsection{Layout calculation from ecc header information}
\label{recalc-layout-header-two}
In a given ecc header struct {\em eh}, the number of sectors in the .iso
image is recorded as \mbox{\em eh-$>$sectors}
and the number of roots is contained in \mbox{\em eh-$>$eccBytes}.
Calculation of the layout is done as shown in section \ref{calc-two},
with the exception of omitting the calculation for {\em free space} and
setting {\em k roots} directly to \mbox{\em eh-$>$eccBytes}.
\subsection{Automatic layout calculation example}
\label{example-two}
Let's assume we are going to encode an .iso image of 295.000 sectors.
This is well below the CD medium capacity of 359.424 sectors, so we
start with:
\smallskip
$medium\; capacity = 359.424\; sectors$
$iso\; image\; size = 295.000\; sectors$
\medskip
The number of CRC sectors will be:
\smallskip
$crc\; sectors = \left\lfloor\frac{4 * 295.000}{2.048}\right\rfloor = 577\; sectors$
\medskip
The total size of all data layers is:
$protected\; sectors = 295.000 + 2 + 577 = 295.579\; sectors$
\bigskip
The next step is creating some preliminary starting values:
\smallskip
$free\; space = 359.424 - 295.579 = 63.845\; sectors$
\smallskip
$k\; roots = min\left(170, \left\lfloor\frac{255* 63.845}{359.424}\right\rfloor\right) = min(170, 45) = 45\; roots\; (or\; layers)$
\smallskip
$n\; data = 255 - 45 = 210\; layers$
\bigskip
Now some more preliminary values can be computed:
\smallskip
$preliminary\; layer\; size = \left\lceil\frac{295.579}{210}\right\rceil = 1.408\; sectors$
\smallskip
$preliminary\; ecc\; size = 45 * 1.408 = 63.360\; sectors$
\bigskip
Finally, we compute $p = 11$ since $\frac{63360}{2^{11}} = 30,9$.
\bigskip
Now the chosen values must be verified to produce a layout which is
still smaller than the image size. We compute (the first two values are already known):
\medskip
$layer\; size = \left\lceil\frac{295.579}{210}\right\rceil = 1.408\; sectors$
\smallskip
$ecc\; size = 45 * 1.408 = 63.360\; sectors$
\smallskip
$first\; ecc\; header\; repeat\; addr = \left\lceil\frac{295.579}{2048}\right\rceil * 2048 = 296.960$
\smallskip
$space\; for\; interleaved\; sectors = 295.579 + 63.360 - 296.960 = 61.979\; sectors$
\smallskip
$number\; of\; ecc\; copies = \left\lfloor\frac{61.979}{2048-2}\right\rfloor + 1 = 31\; header\; repeats$
\smallskip
$total\; added\; sectors = 2 + 577 + 63.360 + 2 * 31 = 64.001\; sectors$
\medskip
This layout will generate an augmented image containing
$295.000 + 64.001 = 359.001$ sectors which is
less than the medium capacity of 359.424 sectors
and therefore accepted.
\subsection{Re-calculating the layout from defective media}
\label{search-two}
In order to recover a defective medium, at least one ecc header must
remain readable and be located by the following heuristic. This
is a major difference to RS03, which has more and different means
for bootstrapping the recovery (see section \ref{recover} for details).
Once one ecc header has been recovered, the ecc data layout can be
calculated as described in section \ref{recalc-layout-header-two}.
From this point, the error correction is done using the parameters
and data described in section \ref{encoding-two}.
\smallskip
If the medium is not damaged or only slightly damaged, the following
short cut might work: The size of the .iso image can be determined
from the iso file system header. Then the ecc header immediately
following the .iso image part of the augmented image is either
located at sector number $iso\;image\;size$ or $iso\;image\;size + 150$.
The latter case arises because some popular CD authoring software
appends 150 padding sectors to any .iso image it creates.
\smallskip
If the short cut does not work due to the required sectors being damaged,
the following strategy is employed. The size of the augmented image
can always be determined; it can either be queried from the drive or
it is the file size of a file-based image. Then apply the following
algorithm:
\bigskip
$p = \left\lfloor log_2(image\; size)\right\rfloor$
while $p > 32$
\quad $pos = \left\lfloor\frac{image\; size}{2^p}\right\rfloor \cdot 2^p$
\smallskip
\quad while $pos > 0$
\qquad if {\em sector at pos} is a valid ecc header: STOP.
\qquad if {\em sector at pos} is unreadable, set $pos := pos - 2^p$ .
\hspace*{13mm} Continue with inner while loop.
\qquad if {\em sector at pos} is readable and not a ecc header, set $p := p -1$ .
\hspace*{13mm} Continue with outer while loop.
\bigskip
In order to test for a valid ecc header, check that {\em ec-$>$cookie}
equals the 16-byte string ``*dvdisaster*RS02''. Then check that the
CRC32 sum of the ecc header matches the value recorded in {\em eh-$>$selfCRC},
with {\em eh-$>$selfCRC} set to the byte sequence 0x47,0x50,0x4c,0x00
for the purpose of calculating the CRC32 sum.
\medskip
Please notice that during testing of the sectors at multiples of $2^{(p-1)}$,
all sectors previously tested for $2^p$ will be examined again. It is therefore
highly recommended to cache results from previous iterations of the outer
while loop, especially when reading sectors from the optical medium.
\subsection{Sector addressing and initialization scheme}
\label{addressing-two}
For encoding and decoding purposes it is required to retrieve the
{\em i-th} sector from the {\em j-th} data or ecc layers, e.g. to calculate
the corresponding sector number in the augmented image.
The reverse calculation is also needed, e.g. to calculate the
corresponding layer and sector index for a given sector number
in the augmented image.
\smallskip
Bear in mind that as shown in figure \ref{layout-logical-two}, an augmented image
is divided into two logical parts. There is a data area containing
the .iso image contents, the first ecc header and the CRC checksums.
The data area is protected by the parity in the ecc area, which contains
the parity data interleaved with copies of the ecc header.
\smallskip
In order to carry out the calculations described below, the following
values from the layout calculation (see section \ref{calc-two} are required:
\bigskip
\begin{tabular}{lp{10cm}}
{\em protected sectors} & the size of the data part in sectors \\
{\em layer size} & the number of sectors per layer \\
{\em $2^p$} & the modulo value for locating ecc header copies \\
\end{tabular}
\paragraph{Converting (layer, sector index) pairs into image sector numbers.}
The {\em i-th} sector of data layer {\em j} has the following address $s$ in the image:
\[s = j \cdot layer\; size + i\]
If $s >= protected\; sectors$, $s$ is a padding sector which must not be read
from the image file, but created in memory (see the paragraph on initialization below).
\bigskip
To calculate the sector address $es$ of the {\em i-th} sector from the {\em j-th}
ecc layer, the non-linear mapping of the ecc sectors has to be taken into account.
The index of the first interleaved ecc header is:
\[ first\; interleaved = \left\lceil\frac{protected\; sectors}{2^p}\right\rceil \cdot 2^p\]
Since {\em protected sectors} is equal to the address of the first ecc sector in the image,
the amount of ecc sectors before the first interleaved ecc header is:
\[ base\; ecc\; sectors = first\; interleaved - protected\; sectors\]
The ecc sector we are looking for would have the following index if ecc
sectors were linearly mapped:
\[ ecc\; index = j \cdot layer\; size + i\]
If {\em ecc index $<$ base ecc sectors}, $es$ = {\em protected sectors} + {\em ecc index}.
Otherwise, the non-linear mapping must be taken into account. The number of interleaved
ecc headers before the (currently unknown) sector position $es$ is:
\[ interleaved\; headers = \left\lfloor\frac{ecc\; index - base\; ecc\; sectors}{2^p - 2}\right\rfloor \]
Therfore the position of the ecc sector in the augmented image is:
\[ es = protected\; sectors + ecc\; index + 2 \cdot interleaved\; headers + 2 \]
\paragraph{Example.} To continue the example from section \ref{example-two}, the
position of the 17th ecc sector in the 3rd ecc layer shall be computed. The relevant
layout values are:
\smallskip
\begin{center}
\begin{tabular}{rll}
{\em protected sectors} & = & 295.579 \\
{\em layer size} & = & 1.408 \\
{\em $2^p$} & = & 2.048 \\
\end{tabular}
\end{center}
The first interleaved ecc header is at position:
\[ first\; interleaved = \left\lceil\frac{295.579}{2.048}\right\rceil \cdot 2.048 = 296.960 \]
Before the first interleaved ecc header,
\[ base\; ecc\; sectors = 296.960 - 295.579 = 1.381 \]
ecc sectors have been stored. The linear index of the sought ecc sector is:
\[ ecc\; index = 3 \cdot 1.408 + 17 = 4.241 \]
Since 4.241 $\ge$ 1.381, the embedded ecc headers must be taken into account. There are
\[ interleaved \; headers = \left\lfloor\frac{4.241 - 1.381}{2.048-2}\right\rfloor = 1 \]
interleaved ecc headers, each containing 2 physical sectors. Therefore the position
of the sought ecc sector in the image is:
\[ es = 295.579 + 4.241 + 2 + 2 = 299.824 \]
\bigskip
{\bf Converting image sector numbers into (layer, sector index pairs).}
\smallskip
If the sector number $s$ $<$ {\em protected sectors}, the sector will map to the data part
as follows:
\[layer = \left\lfloor s\; /\; layer\;size \right\rfloor\]
\[i = s \bmod layer\;size\]
Otherwise, the mapping to the ecc part is calculated as follows. The index of the first interleaved ecc header is:
\[ first\; interleaved = \left\lceil\frac{protected\; sectors}{2^p}\right\rceil \cdot 2^p\]
If $s\; mod\; 2^p \le 1$, the sector maps to the {\em n-th} interleaved ecc header, with:
\[n = \left\lfloor\frac{s - first\; interleaved}{2^p}\right\rfloor\]
If $s < first\; interleaved$, the sector is an ecc parity sector with the following mapping:
\[ layer = \left\lfloor(s - protected\; sectors)\; /\; layer\; size\right\rfloor\]
\[ i = (s - protected\; sectors)\; mod\; layer\;size\]
If $s \ge first\; interleaved$, the mapping of the ecc parity sector is calculated as follows:
The amount of ecc sectors before the first interleaved ecc header is:
\[ base\; ecc\; sectors = first\; interleaved - protected\; sectors\]
The number of interleaved ecc headers before sector $s$ is:
\[ interleaved\; headers = \left\lfloor\frac{s - first\; interleaved - 2}{2^p}\right\rfloor \]
If ecc sectors were mapped linearly, then $s$ had the linear index:
\[ ecc\; index = s - protected\; sectors - 2 \cdot interleaved\; headers - 2\]
Finally, this means that $s$ maps to the following parity sector:
\[ layer = \left\lfloor ecc\; index\; /\; layer\; size\right\rfloor \]
\[ i = ecc\;index \bmod layer\; size \]
\paragraph{Padding sectors.} Let {\em iso image size} be the size of the
.iso image prior to augmenting it with error correction data. In order
to augment the image with error correction sectors, the following
sectors are treated as padding sectors which are filled with zeroes:
\begin{itemize}
\item All sectors $s$ $>$ {\em protected sectors}.
\item The first ecc header (sectors $iso\; image\; size$ and $iso\; image\; size+1$).
\end{itemize}
The first ecc header sectors must be treated as padding to break a circular
dependency with the parity bytes; as the ecc header contains a md5 sum over
all parity bytes, it can not be used as input for the parity generation.
\subsection{Encoding the checksums}
\label{crc-two}
For each sector of the .iso image a CRC32 checksum is calculated and stored in the
data part of the augmented image (see fig. \ref{layout-logical-two}). By using the
conventions of section \ref{sec-layout-logical-two}, let $d_{i,j}$ be the $i$-th byte
of the $j$-th data layer and $c(y,j)$ the 4-byte checksum of the $y$-th sector
in the $j$-th data layer. Then $c(y,j)$ = CRC32($d_{2048*y,j}$, $d_{2048*y+1,j}$, \dots, $d_{2048*y+2047,j}$).
\smallskip
Let $first\; layer\; crc\; idx = (iso\; image\; size + 2) \bmod layer\; size$.
$n$ is the number of data layers.
\smallskip
A total of $\left\lceil\frac{iso\; image\; size}{512}\right\rceil$ sectors holding the
CRC32 checksums must be generated. The checksums are sorted by the layer sector $y$ first,
then by layer number $i$. So for each layer sector $y$, there is a block of $n$ checksums generated,
and there are $layer\; size$ blocks of checksums total. Checksum generation does not start with
layer sector $0$, but rather with layer sector $first\; layer\; crc\; idx$. Subsequent blocks
are generated in ascending layer sector order {\em modulo layer size} so that all
{\em layer size} layer sector positions are eventually covered.
This scheme produces the following
sequence of checksums:
\medskip
\begin{tabular}{l}
$c((first\; layer\; crc\; idx + 1) \bmod layer\; size, \quad 1)$\\
$c((first\; layer\; crc\; idx + 1) \bmod layer\; size, \quad 2)$\\
\dots\\
$c((first\; layer\; crc\; idx + 1) \bmod layer\; size, \quad n)$\\
\hline
\end{tabular}
\begin{tabular}{l}
$c((first\; layer\; crc\; idx + 2) \bmod layer\; size, \quad 1)$\\
$c((first\; layer\; crc\; idx + 2) \bmod layer\; size, \quad 2)$\\
\dots\\
$c((first\; layer\; crc\; idx + 2) \bmod layer\; size, \quad n)$\\
\hline
\end{tabular}
\begin{tabular}{l}
\dots\hspace*{81mm}\\[1mm]
\hline
\end{tabular}
\begin{tabular}{l}
$c((first\; layer\; crc\; idx + layer\; size -1) \bmod layer\; size, \quad 1)$\\
$c((first\; layer\; crc\; idx + layer\; size -1) \bmod layer\; size, \quad 2)$\\
\dots\\
$c(first\; layer\; crc\; idx \bmod layer\; size, \quad n-1^*)$\\
\hline
\end{tabular}
\begin{tabular}{l}
$c(first\; layer\; crc\; idx \bmod layer\; size, \quad 1)$\\
$c(first\; layer\; crc\; idx \bmod layer\; size, \quad 2)$\\
\dots\\
$c(first\; layer\; crc\; idx \bmod layer\; size, \quad n-1^*)$\\
\end{tabular}
\bigskip
$^{*)}$ The last sectors of each data layer may be padding sectors. For those padding
sectors, {\em no} CRC32 checksums are generated and stored (e.g. the number of
generated checksums is always exactly {\em iso image size}).
Since {\em iso image size} is usually not a multiple of 512, the last sector in
the data part may only be partially filled with checksum data. The remaining
bytes of this sector must be filled with the repeated byte sequence
0x47,0x50,0x4c,0x00 which is the ASCII string representation of the text ``GPL''.
\smallskip
A copy of the CRC32 sums for the layer sectors at position ($first\; layer\; crc\; idx \bmod layer\; size$)
is stored in the ecc header, starting there at byte position 2048. This has the advantage that
the CRC checksums are already available for the {\em first layer crc}-th sectors
of data layers $1,\ldots,n$. Any corrupted bytes in those sectors are
detected by the CRC32 and can be handled by the error correction in erasure mode,
saving precious parity bytes. When the error correction has restored all sectors
of the {\em first layer crc}-th ecc block, note that the {\em first layer crc}-th
sector of data layer $n$ will contain the CRC32 checksums for the data sectors
in the next ecc block ({\em first layer crc + 1}). Therefore the layout is robust
against loss of CRC sectors as they are restored by the error correction just
before they are actually needed.
\subsection{Encoding the ecc layers}
\label{encoding-two}
Encoding the ecc layers requires the following steps:
\medskip
First the image must be examined whether it does already contain
augmented ecc data (either RS02 or RS03). If ecc data is found, the
image must be stripped to the original size of the .iso image.
Nesting ecc data is not supported by the current codecs and it
might derail the heuristics for detecting the augmented data
properly. From a technical point, nesting ecc data does not
make sense either.
\medskip
Next the image must be checked for missing sectors, and be rejected
if it is incomplete. Producing and
writing images with missing sectors to a medium is
confusing to the user as dvdisaster will always report
the medium as partially readable even though it does not contain
any physical defects. Also the error correction will never
succeed for such media as it is just restoring the sector
in its missing state.
During the check for missing sectors the CRC32 checksums
of each sector can be computed as described in section \ref{crc-two} and,
after writing a placeholder for the first ecc header, be appended to the image.
Also, the MD5 sum of the .iso image can be calculated at this time and
kept for insertion into the ecc header field {\em ec-$>$mediumSum}.
As another step of preparation, enough space should be appended
to the image to store the ecc layer sectors. This makes sure
that the encoder does not run out of disk space during
its potentially lenghty work, and minimizes the impact of
fragmentation due to random writes into the appended
image area under most file systems.
\medskip
Finally, the error correction information needs to be encoded.
Please refer to fig. \ref{layout-logical-two} on the location
of the bytes comprising an error correction block.
Although the ecc blocks could be encoded by a byte-wise scheme,
a possible encoding algorithm would preferably buffer at least the
255 sectors holding the required data for 2048 subsequent ecc
blocks, and process those in bulk. From the first $n$ data layers,
the required bytes are retrieved and fed into the RS(255,k)
Reed-Solomon encoder, with $k = 255 -n$. The RS(255,k) encoder
is the same for RS01, RS02 and RS03. See
appendix \ref{rs} for the parameters used in the encoder.
Please refer to
the previous section on information about zeroed-out and
zero-padded data sectors. The resulting $k$ parity bytes
are distributed into the $k$ ecc layers. When writing out
the ecc data into the image, free gaps must be left for
the interleaved ecc headers; see section
\ref{addressing-two} for information on calculating the
interleaved ecc header positions. At this time, the MD5
sums of each ecc layer can be updated incrementally.
\medskip
When all parity sectors have been calculated, the ecc headers
can be completed by filling in their {\em eh-$>$eccSum} field.
This field contains the MD5 sum calculated over the MD5 sums
over each of the $k$ ecc layers. In contrast to a single MD5
sum spanning the ecc layers in a linear fashion, this
approach allows for an incremental calculation of the MD5 sum
while the ecc data is generated and written out.