Maybe I was a bit drastic there, but I still think these dupes all belong in a single dump entry.. if you search on a serial you can get 5 of the same entries.. that's just useless.. you could at least make it 1 entry and put all the different version in 1 main entry with sub entries..

This part is reasonable, btw.

I have checked some dupes and some different revisions ring codes in DB and it's impossible to determine real first SS master, so I was wrong.

Moreover there are some SS dumps (expecially 2 tracks ones) which end with full data (if you dump cd with a bigger offset you'll get zeros) and this is another score for offset right detection (if you dump with lower offset correction you lose data, if you dump with bigger offset you get zeros at the end). And dumps with different alternate pregaps in some tracks, we cannot resize even these to get same results.

Yes, they'll do; not shifted data as those are roms, but some bytes different. They archive also bootlegs that probably differs only of some bytes.

My final opinion is that every different dump has to be archived if possible. Moreover SS was not a system so "simple" like PSX, first all games has at least one audo track and we know disc are heavily protected for those times.
I think it's more important to identify alternates within ring codes or cover type like VFR (what's the conclusion about those dumps?). Another game that will have the same problem is Fighting Vipers and then probably Nights, Virtua Cop 1 & 2.
Returning on VFR, the one without spine was sold as bundle if I remember well.

@Dremora
I tested your mod px_d8 with my last dumps and it works fine even with offset detection > +588. Same results of normal px_d8.

We are not modifying anything — we are just reading the data correctly. Drive does correction for the data tracks, we do it for the rest of the image. No modifications.

The method works fine for PSX, but it's useless for saturn, because of the way they are mastered. PSX discs have a very strict mastering process where in most cases the first audio byte is allocated exactly after the pregap. Saturn and IBM discs don't have this, and as a result our offset correction method isn't of any use for these discs.. if you remove the write offset, you don't get the original image on these dupes.. you get the image that was obtained when it was extracted again (to create a new master).. so the dupe has an additional offset added to the image which can't be detected...
If this data shift is the only real difference, why not go a step further as now and store the information on how it differs from a certain parent copy? Assuming that it's in some way possible to determine which is the first generation copy of a game (perhaps using information that is printed somewhere on the disc).

Who says you won't? In a lot of cases it's perfectly clear which is the first version and which were copied and mastered (with new offset) from the original source.. at least with PSX Alt games like Tekken 3 and Sled Storm..

Maybe I was a bit drastic there, but I still think these dupes all belong in a single dump entry.. if you search on a serial you can get 5 of the same entries.. that's just useless.. you could at least make it 1 entry and put all the different version in 1 main entry with sub entries.. And perhaps work with parent/clones in the .dat so the .dat doesn't contain the same data track 5 times.

Do you think MAME would store 10 versions of a rom if they each had 4 bytes of shifted data? I really don't think so.

There's no real preservation value in having all these shifted dumps in the .dat..

There are dozens of versions of the standard audio warnings, every time shifted by a different amount of samples. Following your wicked logic, we should leave only one, but you won't be able to find 'the most correct' one to set it as a parent.

I think the question is if we should treat all these dupes as separate games if they have exactly the same data but only 1 or 2 samples offset difference on the audio tracks... since we're already shifting the audio data when dumping (and modifying it from the original cd by removing the write offset)

We are not modifying anything — we are just reading the data correctly. Drive does correction for the data tracks, we do it for the rest of the image. No modifications.

Take a look at the AccurateRip database — is has up to ten entries for the same disc (differing only by offset), and nobody complains. When someone dumps his disc, he wants to be sure his dump is correct, so he checks it against the AccurateRip database, so it should have all versions of the disc. The same applies to our DB.

Pokerom collectors -- those, who collect the entire dat sets (gotta leech'em all!), so a dozen of dupes is harmful for their hdd space.

I think the question is if we should treat all these dupes as separate games if they have exactly the same data but only 1 or 2 samples offset difference on the audio tracks... since we're already shifting the audio data when dumping (and modifying it from the original cd by removing the write offset), why not just store the write offset value as well as the relative write offset value (by comparing a clone to its parent after dumping and storing the offset difference) and put them in a single dump entry instead of creating all these unneccesary dupes?

There's no real preservation value in having all these shifted dumps in the .dat.. if there's a way to determine which saturn dump is the original (parent) and which ones were mastered again from that source (clones), we could combine all dupes into a single entry (each with their unique offset, ring, serial etc info) and thus remove redundant and irrelevant data from the db that currently exists in each separate entry. The same could be done with a couple psx dumps (e.g. Sled Storm and Tekken 3 PAL).

About parents-clones maybe we don't understand, I think we are saying quite the same (to make a parent-clone with Redump dumps you have to modify cue for clone, otherwise it's better to do nothing). By the way who are pokeroms collectors?

Parent-clone should be in the dat, I'm against the cue modifying.
Pokerom collectors -- those, who collect the entire dat sets (gotta leech'em all!), so a dozen of dupes is harmful for their hdd space.

About parents-clones maybe we don't understand, I think we are saying quite the same (to make a parent-clone with Redump dumps you have to modify cue for clone, otherwise it's better to do nothing). By the way who are pokeroms collectors?

About hybrid stuff, I have added a SS dump ages ago, the Win CD of Game Base for Sega Saturn, but it was not added. Can I add it and where, in SS games?

Yes, I've noticed it before, but forgot to ask you. For now, this one should be added into the Saturn section, because this one is useless without Saturn

As for parent-clone, I'd like to see the parent-clone relationships between different versions of the same title, for example, Metal Slug - Super Vehicle-
001 (J) (v1.005) should be a parent and Metal Slug - Super Vehicle-001 (J) (v1.002) should be a clone (like in MAME).

No way. I'll say more -- there should be an ability to assign multiple systems to a single dump, for example, a hybrid PC/Amiga/CD32 game CD should be in the 3 dats at the same time - in the PC dat, in the Amiga CD dat and in the CD32 dat. We aren't working for the pokerom collectors.

Ok, I understand.
About hybrid stuff, I have added a SS dump ages ago, the Win CD of Game Base for Sega Saturn, but it was not added. Can I add it and where, in SS games?

By the way Vigi is right to find a primary dump (or primary master), about this I think it has to be investigated the second part of ring code. For the ones P1K, P2K if differ it's simple to determine, but for 1M1, 1MM1, 2MC3, etc it has to be investigated.

All these dupes with same data track and different audio track are pretty useless imho.. maybe it would be good to use parent/clone in the .dat to avoid having the same data track in 5 different zips. Or maybe the dumping process just isn't optimal / offset isn't analyzed correctly.

No way. I'll say more -- there should be an ability to assign multiple systems to a single dump, for example, a hybrid PC/Amiga/CD32 game CD should be in the 3 dats at the same time - in the PC dat, in the Amiga CD dat and in the CD32 dat. We aren't working for the pokerom collectors.

***How can be calculated a checksum over non-zero data if some bytes are missing?

I think the saturn dupes only have an offset difference? (a shift in bytes with no non-zero data missing?).. if so, then a tool could ignore all zeroes before and after the non-zero data.. this chunk should be the same size for each Alt.

Anyway, I like your idea of a parent/clone structure.. I don't think it would be require a lot of modifications (hope Dremora can give us his opinion).

I guess the main question now is how we can determine which dump should be the parent and why? Maybe the one with the oldest (lowest) barcode or something like that?

All these dupes with same data track and different audio track are pretty useless imho.. maybe it would be good to use parent/clone in the .dat to avoid having the same data track in 5 different zips. Or maybe the dumping process just isn't optimal / offset isn't analyzed correctly.

No way. I'll say more -- there should be an ability to assign multiple systems to a single dump, for example, a hybrid PC/Amiga/CD32 game CD should be in the 3 dats at the same time - in the PC dat, in the Amiga CD dat and in the CD32 dat. We aren't working for the pokerom collectors.