no, no, Dremora had most of it done in psxt001z for a long time - there is SUB generator, it just doesn't take TOC as an input
i guess he had his reasons not to make it or really is very busy
and so did i - i had written very similar program recently, to make .SUBs for those saturn ring tests
so just had to make few little changes here and there - it's not a big deal
thanks though

did few more tests - i've masked first one MSF column, then 2nd in Crash Bash
and it didn't pass both of the times, no matter the CRC value
so it isn't threshold (any CRCs pass, but moded MSFs do not)
it's strange - i really thought this would be it
maybe there really is nothing more to this?

and so far all records in db belong to one of those two patterns, afaict,
so it's 50:50 for about 100 records,
not that bad if somebody wants to just burn some CDs

but for sake of preservation SBI, as it is now do not fit, imho
belonging to exact pattern is lost, so if there would be no more DB
guessing would be all that's left and still even if both values would pass on PSX
this information itself would be lost

batch reading from db is possible, cHrI8l3 would know better than i
but i think it wouldn't be good to to that - ther's no simple way, imho
it would retrive those 100 records whole, every time
things like that basically could kill server

one single reading to save manual labour making a backup in .txt or so - for later processing,
on the other hand, would do no harm

Usage:  sbi2sub file.cue file.sbi XOR [file.dat]

Where:  XOR is either $0080 or $8001

Example:
        sbi2sub Game.cue Game.sbi $8001
        sbi2sub Game.cue Game.sbi $0080 PSX.dat

What's that?

So the sbi format is missing relevant data that cannot be generated again? How about a tool which loads the libcrypt sectors from the database instead of using the sbi file?

processed following images with it:
Crash Bash
Speed Freaks

and tested with ePSXE 1.70

plugins that do not appear to read subcode at all (they crashed @LC):
SaPu's CD-ROM
Xeven's Cdr
plugins that would have to work but didn't (both games hanged prior LC with those):
P.E.Op.S. CDR
Pete's CDR
plugins that did worked:
ePSXe CDR <- only one that passed and would run actual CDs instead of images
Moby2 cd disk image driver
and additionaly ePSXe's Run ISO command

without subcode:
Crash Bash would crash on loading screen after character select & intro, before stage select
Speed Freaks hangs while Neon City stage is loading

with subcode those parts passed on both XOR patterns ($8001 & $0080)
i didn't test further though:
maybe there are later checks that wouldn't
maybe there is certain threshold, so for example:
byte from each MSF + 2 CRC bytes = 4  - maybe half of them passing is sufficient
but CD-R recorded this way would degrade much faster
maybe hardware or even other emulators act different
so i didn't test all those things - i'll take a closer look later with debugger - it's quite interesting

but consider this:
if those CRCs are there for the kicks only - completely unneeded to pass LibCrypt
it's a huge flaw in protection then, imho - this pattern gives away those special blocks
so what if Sony removed it later?
what if there are LC versions without modified CRCs or at least without constant (maybe even for USA or Japan)?
we wouldn't pick those currently, right?
the only way would be to clear subchannel a lot - with multiple rereads
and compare it later on with the ones from different CD, made in a similar way
psxt001z is capable of doing this, afaik, but nobody would - it takes forever
it's such a drag, not everyone would even test CDs with fast option

i don't think SBI author did really understand how LibCrypt works,
since ther's that possiblility to include only one of MSFs (saving 7 bytes?) -
on LibCrypt this seems to never happen - it's always both or none, afaict
so CRC can even be sole value modified:
http://redump.org/disc/1128/
those sectors are known to be LC,
with them pattern looks complete: 32 total sectors divided in groups of 16
3rd entry is @offset 0x20 in SBI, containing only valid bytes
how can modified data be recreated from unmodified values?
btw such blocks would be skipped with original plugin - it only stores ones with modified MSFs

so this complexity of format - it appears completely irrational and quite useless,
it could have been just MSF+entire Q
overcomplication often is a result of lack of understanding

One thing I can suggest though is that we do need something added to the site to give us a list of the games that do have sbi files on them so that we can quickly know what games have been proven to have LibCrypt protection on them without having to look at each game separately.

http://redump.org/discs/system/psx/libcrypt/2/

btw, do those SBIs even work?

there appears to be no CRC stored within them,
so it's supposed to be recreated i guess
but since there are multiple patterns,
how would you tell whether to XOR with 0x0080 or with 0x8001?
if it's byte right after MSF, something's wrong then - it's never different from 0x01

for example:

same changes on CDs with different patterns:

                      C/A TNO IND M   S   F   Zro aM  aS  aF  CRC      Unmd   LC1    CRC      Real   LC2
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  ffb8 xor b838 = 4780 | ffb8 xor ff38 = 0080
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  3839 xor b838 = 8001 | 3839 xor ff38 = c701

in SBI CRC is lost:

                      C/A TNO IND M   S   F   Zro aM  aS  aF  CRC      Unmd   LC1    CRC      Real   LC2
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  ???? xor b838 = 4780 | ???? xor ff38 = 0080
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05  ???? xor b838 = 8001 | ???? xor ff38 = c701

so to recalculate CRC it could be either one of those algorithms:
a) Real XOR 0080
b) Unmd XOR 8001
but only one of them is valid for each CD

i.e.
this is as far as SBI goes:
MSF: 03:08:05 Q-Data: 41  01  01  07* 06  05  00 *23  08  05
those bytes are the same for both CDs
http://redump.org/disc/592/
http://redump.org/disc/798/
but each has different pattern in DB

it can't be right...

edit:
from what i can tell from cdr sources
0x01 following MSF indicate both time values being modified
and that's as much as SBI can hold
other options are 0x02 and 0x03 - for storing only relative or absolute MSFs
so i'd say ther's no way for SBI to hold CRCs - it's an unfortunate limitation of format

so what are those SBIs then good for at all?

SBI files are needed to actually preserve the digital data, so it should be included when replicating data. (Though it is bad that it is done in a binary format which is poorly documented)

for me having info about packiso images CRC or SBI info in a dat is not right, and it should be the responsibilities of the uploaders to download those SBI files and share them with the dumps. also if someone have some packiso images generating a new dat file for those take just few clicks, having that info and regularly update it when ever there is a change related to that image in redump.org DB will only make maintaining the DB hard.

PS: i would rather like the dat file to be updated so that the naming scheme of the files can be updated to reflect more proper game name then having these info.

Hm...ok now that I think about it a little more I guess it wouldn't hurt. I'm just seeing way too much stuff around here with people wanting to make this more "emulator friendly" when that was never what this started out to be in the first place but yes I guess a CRC of the sbi file is possible since the site generates the checksums for the cue files as well. I just wish Dremora (or someone here that can program) would make something that can inject the SBI data in to a generated CloneCD sub file for people like me who want to burn the images and run them on the real system.

Indeed,  directly onthefly injection of  the subchannel-data when mounting/burning a dump would be the best solution, but until someone comes up with way to use them, we are stuck to the sbi-files and therefor should be referenced in the dats.

Just like some MAME versions ago, where you need to use some special files (xor tables) to break protection of CPS3 games. Ofcourse MAME had references to those files in it's internal database. Now that MAME can emulate the protection itself without the need to 'crack' it, the xor-tables arn't needed anymore and has been removed from the rom-db.