Testing your program to dump certain PS1 discs for my personal archive and new PC Engine CD discs, standing the fucking heat of the Baetic Depression in the summer, I have noticed this:
It's the very same issue noticed by
gorelord4e two years ago: certain discs manufactured by Sony DADC in Japan (IFPI 45xx) have a weird pattern in the R-W subcodes, last byte of R-W frames are filled with 0x1, 0x2 or 0x3 values. This pattern dissapears when packed mode for subcodes is selected, -mode 2 for subdump.exe.
The selected subcode reading mode of your app is the raw one and this pattern is present and replaced with zeroes in the auto-cleaning process. Unfortunately, «_errorlog.txt» file gets so big due to this pattern and discimagecreator complaining about R-W subcodes with unexpected values.
In the detection process for CD+G data this pattern is observed for every track, seems feasible to implement a routine to detect it and switch to packed mode for these discs, in order to avoid these logs files with an insane size.
Two samples of discs with this pattern, SLPS 00504 and SLPS 00667:
─ Logs, cues, sub and whatnot created by discimagecreator.
─ Raw subcode extracted by CDTool without any cleaning. AMSF 00:02:26 is corrupted because drive used (a cheapo Hitachi-LG CD burner based on Mediatek chipset) accelerates crazily when reading a mode 2 data track, even overriding the selected read speed.
http://www.mediafire.com/?1256gaea45s62fc
==========
Can you post the future WIP releases of discimagecreator stored in a zip/7z/whatever archive? Mainly to preserve the original timestamp and whatnot.
