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

[jjr90]

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]

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]

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

This is not caused by a user error.

[speed47]

Thanks for the report (and sorry for the delay, obviously).

You're right, the logic is clearly flawed here, nice catch. This should be easy to patch.

At some point however, I think I'll just implement what I tried in https://github.com/speed47/dvdisaster/issues/69#issuecomment-2237152317 and have a "really exhaustive search" option for RS03, that will just try either all known disc sizes seen in the wild (a few dozens) or simply ALL possible sizes, as with the CPUs of 2025, this could be quite fast and if your disc is so damaged that the RS03 metadata is unreadable and we have to resort into trying to look at RS03 roots in the image without requiring the metadata to be valid (which is the portion of the code we're talking about), you probably want to have that kind of option available.