Hi Eidolon, nice to see you're still around :-)
I disagree with the redump.org method on the following points
ripping RAW mode data for all SegaCD and Saturn games is not necessary. The Inn Method will concentrate on USER DATA only
MODE1/2048 for SegaCD games
MODE1/2048 and in some cases MODE2/2352 for Saturn games
Will the ripping contain a check that this data is superfluous ? I.e. even if data is saved in 2048 byte sectors, will a check be performed that verifies that the ECC information can be recreated in the standard way ? (I assume this will have to be done for Saturn games since you mention the possibility of them having to go RAW).
applying any audio data shift to the ripped binary files is not necessary to achieve comparability and maintain playability using virtual drives or emulators. The Inn ripping method will only take note of the drive read offset. Write offset can be calculated from that and the ripped image, but this is done solely to maintain comparability with redump.org database.
Given the case where the offset is not so far in the negative that most drives cannot detect it properly (this is an issue on PSX, no idea whether it comes up on Saturn or SegaCD). So long as this offset is known, however, the data layout on the CD can be recreated exactly as it was on the pressed version, so carrying this metadata is a good thing :-) There's also the issue of positive offsets and shifting of legitimate audio data into the leadout (which may be cut off), though you seem to opt for manual handling of these cases.
handling of separate files for data and audio tracks is unecessary. One single BIN file per CD is the right way to go
On this I'd disagree, but it's a contentious issue to debate. The single-file approach doesn't allow stuff like compressing audio tracks separately with more appropriate methods (i.e. flac vs. 7z), and checksum-verifications are harder on the entire image in some cases. But oh well