Redump Forum

Posted: **Fri Nov 29, 2019 10:27 am**

This is a continuation of /viewtopic.php?p=55587#p55587

F1ReB4LL wrote:Because 2 different prints are known, the first was dumped as 0 (as usual), another needs the -294 offset to match the entry (it's pointless to add different prints of the same disc as separate entries, since the whole disc contents is shifted).

Aren't these pointless?

Vampire Hunter: Darkstalkers' Revenge (Japan) (1M)
Vampire Hunter: Darkstalkers' Revenge (Japan) (2M, 4M)
Vampire Hunter: Darkstalkers' Revenge (Japan) (3M)

Code: Select all

e:\tmp>fff -crc=$9921da39 "Vampire Hunter - Darkstalkers' Revenge (Japan) (2M, 4M) (Track 2).bin"
FindFileFragment @20100709 / themabus@inbox.lv
----------------------------------------------
Input: Vampire Hunter - Darkstalkers' Revenge (Japan) (2M, 4M) (Track 2).bin
Offset: 0
Size: 3880800
CRC: 9921da39
Shift: both
Step: 4
Range: 20000

Offset correction 0 bytes, CRC-32 ea2afe21
Offset correction 4 bytes, CRC-32 9921da39

Fragment found!

Code: Select all

e:\tmp>fff -crc=$9921da39 -shift=r "Vampire Hunter - Darkstalkers' Revenge (Japan) (3M) (Track 2).bin"
FindFileFragment @20100709 / themabus@inbox.lv
----------------------------------------------
Input: Vampire Hunter - Darkstalkers' Revenge (Japan) (3M) (Track 2).bin
Offset: 0
Size: 3880800
CRC: 9921da39
Shift: right
Step: 4
Range: 20000

Offset correction 0 bytes, CRC-32 8b3d5dce
Offset correction -4 bytes, CRC-32 54b68c45
Offset correction -8 bytes, CRC-32 5929eff5
Offset correction -12 bytes, CRC-32 1930b238
Offset correction -16 bytes, CRC-32 9921da39

Fragment found!

Posted: **Sat Nov 30, 2019 12:56 am**

It's not the same disc and IMHO it would be wrong to just hack it to compliance, however convenient that may seem in reducing data volume and amount of dumps in DB. Applying additional offset correction apart from what the dumping method already does is totally equivalent to hacking stuff to compliance.

Again IMHO, it's significant to indicate different print runs/different ringcodes, at least when they result in different dumps when using the same standard dumping method.

Also had a similar case with one of my dumps recently that was accepted as separate discs, which of course they are.

https://redump.info/disc/39867/
https://redump.info/disc/65686/

Same with the Vampire example, discs are different and it was correct that all of them were included.

Posted: **Sat Nov 30, 2019 4:12 am**

Maddog wrote:Again IMHO, it's significant to indicate different print runs/different ringcodes, at least when they result in different dumps when using the same standard dumping method.

I agree with you, but what I want to know is the current rules.

Posted: **Sat Nov 30, 2019 5:00 am**

Nope, these aren't the same cases. For the Audio CD we can merge all the tracks into a single image and shift the whole image by 294 samples to get the match, because the entire disc contents is shifted. While for the 1M/2M/3M/etc. ones only some tracks are shifted and even if you leave the data sectors scrambled and try to shift the whole image, it won't match any other one.

In short:

When the whole image is shifted compared to another one => both discs are the same and are only affected by the write offset, should be merged
When only some tracks are shifted compared to another image (all the tracks are shifted, but not the scrambled data track also belongs here) => both discs are mastered differently and shouldn't be merged

Redump Forum

[Resolved] same disc?

[Resolved] same disc?

Re: [Resolved] same disc?

Re: [Resolved] same disc?

Re: [Resolved] same disc?