speed47 / dvdisaster

A tool providing additional ECC protection for optical media (unofficial version)
https://dvdisaster.jcea.es
GNU General Public License v3.0
277 stars 20 forks source link

RS03 is using the wrong image size for exhaustive scan when the user correctly specifies no-DM, causing random failures #99

Open jjr90 opened 1 month ago

jjr90 commented 1 month ago

When the user correctly specifies --no-bdr-defect-management, in exhaustive scan mode (bypassing the "Easy shot: Locate the ecc header"), dvdisaster will determine the disc as the next size up (dual-layer instead of single-layer, etc).

This is causing the exhaustive scan to fail unpredictably, in cases when it's needed:

In rs03-recognize.c:

      else if(image_sectors < BD_SL_SIZE)
         layer_size = (Closure->noBdrDefectManagement ? BD_SL_SIZE_NODM : BD_SL_SIZE)/GF_FIELDMAX;
      else if(image_sectors < BD_DL_SIZE)
         layer_size = (Closure->noBdrDefectManagement ? BD_DL_SIZE_NODM : BD_DL_SIZE)/GF_FIELDMAX;

As you can see, an SL image that's been augmented with no defect management will have an image_sectors GREATER THAN BD_SL_SIZE, and will thus match the image_sectors < BD_DL_SIZE instead.

dvdisaster thus detects a single-layer disc as a dual-layer disc, etc. This causes the layer_size variable to be double what it should be, and the exhaustive scan MAY fail, depending on how the scan alignment works out.

I can provide a test case to reproduce the unpredictability, but the wrong logic is easy to see there.

Disclaimer: I haven't looked at any of the RS01/02 code, don't know what might be applicable there.

jjr90 commented 1 month ago

The quick fix would be to determine the thresholds the same way you're determining the image size in the statements below (i.e. with the ?: operator again, or perhaps factor that out..)

jjr90 commented 1 month ago

To clarify, this is a bug when the user correctly specifies --no-bdr-defect-management.

This is not caused by a user error.