In the end it all seems to come down to keeping the first and last audio samples, which is what CDRWin appears to fail at (because there's no offset correction).
@Snake.. I understand from your posts on Eidolon's Inn how offsets aren't really important for your projects, but you have to understand why they are important to us.
First of all it's for documentation. We like the idea of having the audio tracks put back into the position they were before mastering. Even though in the end it only comes down to a few shifted bytes, if you split dumps into separate tracks and store them this way, there can be great benefits to it. For instance for 600mb games with 550mb of identical audio tracks, you can just get the data track and import the audio from another file, without even having to touch a patch tool.
If we would be using TOSEC's method we wouldn't be able to know if a 600 mb game has 550 mb of identical audio in the PAL version compared to the NTSC version (example: http://redump.org/disc/469/ + http://redump.org/disc/475/). Of course you could try to make a patch, but you loose some insight on how these dumps actually differ.
You could just assume that all dumps are different if the disc isn't exactly the same, but at the end that won't help you (at least not if you want to store the cd-images of the dumps somewhere), and here's why: There are plenty of games that only have one difference: the offset. If you would dump these games using TOSEC's method, you would have 2 separate dumps and need 2 dump entries. Using our method there's just 1 dump and 1 entry: http://redump.org/disc/447/ http://redump.org/disc/1777/
If you're planning to include 'intelligent checksums' for both data and audio in your database then I guess you will have the same advantages as our method for games where all audio tracks are identical, but there are also a lot of games where 1 or 2 audio don't match and all the others do. This is why we prefer offset correction and separate tracks. If you don't care about seeing the similarities between two dumps, you can just go ahead with your proposed method, but if you're planning on keeping the cd-images or spreading them around OR if you decide to care about showing people the similarities between dumps, you now know the advantages of our method.
It's not about good or bad. If you actually pay attention to the offsets instead of ignoring them, you are able to remove all the irrelevant differences between a dump and get an ideal dump. Let the offsets help you by separating them from the dump and by storing them as values, not by ignoring that they are there! (the factory write offset is a relevant piece of information about the CD that should be stored in the db).
All tracks have a factory write offset. The only difference is that you don't see them on data tracks, because data isn't read in audio mode (you can still do that and detect the write offset for information purposes using this method: http://forum.redump.org/viewtopic.php?id=2057). The point I'm trying to make here is that what we are really doing here is treating audio the same way the drives are treating data (by removing the offsets that aren't affecting the data track).