Skip to content

Commit

Permalink
add some info about RS03 in readme
Browse files Browse the repository at this point in the history
  • Loading branch information
@speed47
speed47 committed Jul 10, 2024
1 parent 3d1bf46 commit 8d4431c
Showing 1 changed file with 35 additions and 17 deletions.
52 changes: 35 additions & 17 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -50,31 +50,49 @@ The artefact is an **ecc** file, which must be stored on another media than the
:two: **RS02** creates error correction data which is added to the medium to protect, we call this *augmenting* the image we're protecting.
Damaged sectors in the error correction information reduce the data recovering capacity,
but do not make recovery impossible - a second medium for keeping or protecting the error correction information is not required.
Intelligent adaptive reading is also available when reading a damaged RS02-protected disc: dvdisaster will only attempt
to read the minimum amount of required sectors to be able to rebuild the image, using a so-called "divide and conquer"
seeking mechanism, cutting off up to 90% of the time required to read and recover a damaged media.

:three: **RS03** is a further development of RS01 and RS02. It can create both error correction files and
augmented images, with the following added features:

- RS03 can use multiple CPU cores and is therefore **much** faster than RS01/RS02 on modern hardware.
- RS03 error correction files are - contrary to RS01, and to a lesser extent RS02 - robust against damage.
- RS03 is more robust, but also more restrictive: The augmented image must completely fill the medium now while the size of augmented images can be freely chosen in RS02.
The changes for parallel computation and higher robustness make RS03 a bit less space efficient,
e.g. RS03 error correction data has slighly less (around -3%) error correction capacity than its RS01/RS02 counterparts on images with equal size.
- It can use multiple CPU cores and is therefore **WAY** faster than RS01/RS02 on modern hardware.
- RS03 augmented images and error correction files are - contrary to RS01, and to a lesser extent RS02 - robust against
damage of the dvdisaster-added recovery data itself

Rough comparison table:

| Codecs | RS01 | RS02 | RS03 |
|------------------|--------------------------------|--------------------------------|--------------------------------|
| Robustness\* | :star: | :star::star::star: | :star::star::star::star::star: |
| Speed | :star::star: | :star: | :star::star::star::star::star: |
| Space efficiency | :star::star::star::star::star: | :star::star::star::star::star: | :star::star::star::star: |
| Augmented images | :x: | :heavy_check_mark: | :heavy_check_mark: |
| Separate files | :heavy_check_mark: | :x: | :heavy_check_mark: |
There are, however, a few cons that must be noted:

\*Robustness against corruption of the dvdisaster-added ECC parts themselves
- In image mode, the RS03 augmented image file size will be picked up from a predefined list of well-known medium sizes,
while the size of augmented images can be freely chosen in RS02. This is the "price to pay" for the added robustness
of the correction data.
- In image mode, intelligent adaptive reading is not available for RS03-protected images. The "divide and conquer"
algorithm will still be used, but dvdisaster will not stop as soon as enough sectors have been recovered to rebuild
the image: it'll attempt to read them all until you stop it, or until it tried to read all the sectors. You can still
stop it manually and attempt a "verify" of the resulting image file, to see if enough data has been read for recovery,
otherwise resuming the adaptive reading until this is the case.
- The changes for parallel computation and higher robustness make RS03 a tiny bit less space efficient, e.g. RS03 error
correction data has slighly less (around -3%) error correction capacity than its RS01/RS02 counterparts on images with
equal size. This is usually considered a cheap price to pay for the added robustness against corruption.

A rough decision chart follows:
Rough comparison table:

![dvdisaster codec decision chart](https://i.imgur.com/QTgiack.png)
| Codecs | RS01 | RS02 | RS03 |
|------------------------------------------|--------------------------------|--------------------------------|--------------------------------|
| Create ECC-augmented images | :x: | :heavy_check_mark: | :heavy_check_mark: |
| Create separate ECC files | :heavy_check_mark: | :x: | :heavy_check_mark: |
| Robustness\* | :star: | :star::star::star: | :star::star::star::star::star: |
| Space efficiency | :star::star::star::star::star: | :star::star::star::star::star: | :star::star::star::star: |
| Computational generation speed\*\* | :star::star: | :star: | :star::star::star::star::star: |
| Computational repair speed\*\* | :star::star: | :star::star: | :star::star: |
| Badly damaged media recovery time\*\*\* | N/A\*\*\*\* | :star::star::star: | :star: |
| Adaptive reading | N/A\*\*\*\* | :heavy_check_mark: | :x: |
| Custom augmented image size | N/A\*\*\*\* | :heavy_check_mark: | :x: |

\*Robustness against corruption of the dvdisaster-added ECC parts themselves. The higher the ranking, the less it is likely than a few badly located damaged sectors render the whole correction impossible because they affect dvdisaster metadata on-disc. For example corruption of the first dozens of sectors of an image can make RS02 entirely unusable regardless of the redundancy.
\*\*When algorithm is CPU-bound, i.e. generating or repairing an image stored on a SSD/NVMe drive
\*\*\*Using adaptive reading, taking into account the time the drive takes to try to read damaged sectors
\*\*\*\*Only applicable for augmented images

# :bulb: Rationale

Expand Down

0 comments on commit 8d4431c

Please sign in to comment.