Search options (Page 1 of 32)

We document the barcodes how they are visible on the box, so include the ">" when it's there, even if it serves no practical purpose for the database.

Giving up on finding a missing Resident Evil 2 PS1 PAL. There's no evidence of an undumped release. These are all the known releases:

Original:
5 028587 081194    UK / Rest of Europe    SLES-00972
5 028587 081828    France    SLES-00973
5 028587 081835    Germany    SLES-00974
5 028587 081842    Spain    SLES-00976
5 028587 081859    Italy    SLES-00975
5 028587 081866    Greece / Portugal    SLES-00972
5 028587 081873    Nordic    SLES-00972
                   
Platinum:
5 028587 082559    UK / Rest of Europe
5 028587 082566    France           
5 028587 082573    Germany           
5 028587 082580    Spain           
5 028587 082597    Italy           

No separate Irish, Belgian (French), Australian releases exist and no hits on any subsequent barcodes

Current best guesses for RE2:
- Special Edition (Germany) release - Claimed to match normal German release, but need pictures for proof
- Ireland - Resident Evil 3 has an Irish release with a blue rating logo on the box

My final vote would be to correct offset whenever it's necessary, practical and possible, so follow the base rules that we previously discussed:

0. If there is no non zero data in pregap/lead-out, use 0 offset. Unless it's possible to manually detect the write offset with a reasonable degree of certainty, in which case combined offset correction can be used.

1. if there is non zero data in lead-out and that data can be fully shifted out of there (left) without spanning non zero data into pre-gap, correct offset with a minimum shift required
2. if there is non zero data in pre-gap and that data can be fully shifted out of there (right) without spanning non zero data into lead-out, correct offset with a minimum shift required

Whenever a disc is dumped with offset correction, this should be documented in comments.

And then for the rare headache cases discussed in your last post where it's impossible to shift out data from lead-out/pre-gap (data is wider than allocated TOC space for it):

3. Use 0 offset and preserve relevant non-zero data in separate pregap.bin or leadout.bin. I don't see any advantage in trying to include this data with the main dump through a custom cuesheet format or whatever, but if it's decided otherwise, that's fine by me.

And for the DC / PSX or other discs that have missing relevant TOC / pre-gap / lead-out data, we should also preserve this data in separate files (offset corrected if possible).

As for offset matching and "universal" checksums: Audio checksum databases like AccurateRip and CUETools are already ignoring leading and trailing zero bytes, so they are essentially already storing "universal" checksums? I think this is beyond the scope of the Redump project and would require too much work and too many changes.

Guess we still need to figure out how add the separate files in the database, with iR0b0t not around. Maybe resort to storing .dat or checksums in comments for now, similar to Xbox PFI/DMI/SS.

In reply to the issue posted here: https://github.com/saramibreak/DiscImag … issues/121

DIC dumps multisession .cue with these lines added:

REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
REM PREGAP 00:02:00

These lines are added with the intention to document the disc layout and to describe data that isn't there.
So the REM LEAD-OUT, REM LEAD-IN and REM PREGAP lines are describing missing blocks the same way as PREGAP (without REM) did before we came up with this. They are describing a length and not a relative address.
When I look at previous definitions of REM LEAD-OUT, they are also describing a length: https://github.com/libyal/libodraw/blob … m-lead-out (but a couple lines below there's a typo where it says "The REM LEAD-OUT command is used to specify the LBA corresponding to an MSF.", where they actually meant REM MSF)

It wasn't meant to be a functional implementation. These lines are stored in the database. As soon as you download the .cue from the redump site, these lines are omitted. So you end up with a cuesheet that only has the REM SESSION 02 line.
Which leads to the problem that was described before here: http://forum.redump.org/post/94441/#p94441
To have somewhat functional .cue's using old definitions, I proposed to add the PREGAP 02:32:00 after the REM SESSION 2 to downloaded .cue's. This fix was never implemented and since then, user7 got in contact and IsoBuster implemented some changes that I'm unaware of.

To summarize, there are a couple different solutions:

1. Add the REM LEAD-OUT 01:30:00, REM LEAD-IN 01:00:00, REM PREGAP 00:02:00 into the redump .cue downloads, and have tool authors interpret these lines as a missing block, similar to PREGAP.

2. Add the PREGAP 02:32:00 line to redump .cue downloads. Tell people to use redump .cue instead of the one produced by DIC.

3. Keep everything as is, but have tool authors interpret multi-bin .cue with only the SESSION 02 line (= .cue as currently downloaded) as missing a 02:32:00 block between the sessions and hardcode a fix.

Also my input for automatic offset correction:

There should be a limit on the maximum amount of non-zero samples that are corrected.
Looking at some of the large offsets that are dumped:
-9392 http://redump.org/disc/78870/
(next one is -4707)
+6722 http://redump.org/disc/1838/
(and several +5292)

It seems that maybe -10.000 to +10.000 samples seems like a logical range.

Here is my proposed method for automatic offset detection for Audio CD's:

Step 1: Determine the amount of non-zero data in the lead-out:
- If there are >10.000 samples of non-zero data in the lead-out, then this is a strange disc that violates Red Book standards. Offset correction is skipped and the disc is dumped with 0 offset?
- If there are ≤10.000 samples of non-zero data in the lead-out, then look if there's at least an equal amount of zero samples at the start of Track01. If this is the case, then proceed to use this as the custom offset correction (shift data to the left).
- If there are less zero samples at the start of Track01 than non-zero samples in the lead-out, then this is a strange disc that violates Red Book standards. Offset correction is skipped and the disc is dumped with 0 offset?
Step 2: This step should only be performed if no non-zero data was found in the lead-out. Determine the amount of non-zero data in the Track01 pregap, counting backwards from sector -1.
- If no non-zero data is found in the Track01 pregap, then no offset correction is required and the disc is dumped with 0 offset.
- If there are >10.000 samples of non-zero data in the pregap, then this is a strange disc that violates Red Book standards. Offset correction is skipped and the disc is dumped with 0 offset?
- If there are ≤10.000 samples of non-zero data in the pregap, then look if there's at least an equal amount of zero samples at the end of the last track. If this is the case, then proceed to use this as the custom offset correction (shift data to the right). If there are less zero samples at the end of the last track than non-zero samples in the Track01 pregap, then again this is a strange disc and 0 offset should be used?

The staff will discuss (and perhaps refine) this proposed solution and then we will inform you.

The reason for the ss_sector_range modifying of the SS.bin bytes is to get consistent hashes between different dumps of the same discs. Otherwise you end up with 100 different SS.bin that are actually the same, but those bytes change randomly on different reads.

IIRC the "cleaning" was only for SSv1, but please confirm.

Hi,

this disc has a strange track01 pregap: http://redump.org/disc/87558/

Logs: https://mega.nz/folder/AYoggTyS#-S138gR9lRjgqzx9d_d-8A

Is it correct?

-12 seems way more common than 0, but otherwise you're right

Hello,

The TOC indeed tells you the length in LBA of each track. Offsets have no bearing here.

This should be possible and seems sensible in the cases where you want to capture non-zero bytes that would otherwise be lost. There are some discs already in the db that were dumped this way: http://redump.org/discs/quicksearch/off … /audio-cd/
So feel free to request such a feature and we will allow such dumps.

There is no write offset correction for audio CD's, just read offset correction. IIRC the way these audio databases can link different pressings is by hashing the tracks without leading and trailing zeroes, thereby eliminating any offset differences and by measuring the amount of zeroes and storing them alongside the hashes, it's possible to calculate the offset difference.