first of all, thanks for this amazing application and the hard work behind it!
i have also had issues regarding the small size files (rescene process failed), especially .cue files of older game iso releases, but i have gathered a little experience that might be helpful for fixing this annoying bug in the future.
the older game iso releases contain a cd image file (.bin) and a cue sheet (.cue), the trick is the place of the .cue file within archive.
when the .cue was placed in the first rar fragment (.001), the pysrr (0.6, win) wanted to find proper rar version for it without any success, regardless of trying the final retail versions only, or the full scale rar folder containing the betas too. in both cases "no good rar version found".
i have also tried to use older versions of srr.exe (0.4 win, 0.5 win). strangely, these were able to find a "proper" rar version (2.6), but it seemed to be odd due its overdated version for a f.e. 2003 release like Harbinger-FLT. after matching the .cue with the "proper" rar version, the software continued to look for proper rar version for the .bin file without success, just like before: "no good rar version found".
i wanted to rescene the followings:
their common thing is that all of these games were released by FAiRLiGHT, having the same approach: placing the .cue into the first fragment (.001), thus the rescene process failed everytime due to the lack of proper rar version for the .cue file.
i have also tried to remove the .cue file and fill up its presence with fake files (-f), but the result was the same: the process moved on to the .bin file, but "no good rar version found".
in parallel, i had some DEViANCE and RELOADED releases to rescene, and the process worked every time:
again, the difference between these releases and the FLT releases is the position of the .cue files within the archive. the last rar fragment contained the .cue file, thus the rescene process started to look for proper rar version for the .bin file first. after detecting the proper version, the archive was created up until the last fragment, into which the .cue file should have been inserted. the rar version detection was started for the .cue file, trying out every single rar version (betas too, so it took for ages…) without success ("no good rar version found"). however, the process moved on: it created the archive fragments up until the last one, and added the .cue file into the last fragment probably "as it is". this resulted in a proper final fragment with proper CRC number, the rescene was successful. (i can upload some pics about the process, if needed.)
i am not an IT guy, so i am just guessing, but maybe the .cue file was inserted into the last rar archive file without any compression or manipulation.
in case of the FLT releases, the pysrr process wants to compress the .cue files the same the .bin files are compressed. this compression alters the first rar volume by altering the cut-point of the .bin arhive, and the rar detection process fails.
is it possible to leave the .cue file out of the rar detection process, by inserting it as it is (unchanged, uncompressed, unmanipulated) into the first volume, and look for proper rar version for the .bin file afterwards up to the rest of the arhive fragment size?
i hope these case studies help you anyhow, and thank you again for everything.
rescene is amazing!