1

(3,291 replies, posted in General discussion)

https://mega.nz/folder/0NQh3QgL#Y2vjOQAxojTAPB4xJtjvIw

No PVD is detected on this disc, but sector 16 has a normal PVD, so I wonder what the problem is?

2

(3,291 replies, posted in General discussion)

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.

3

(3,291 replies, posted in General discussion)

http://redump.org/disc/74600/

Why is it counting 150 sectors as part of write offset? Is it a bug?

Logs: https://drive.google.com/file/d/1lbh0vA … sp=sharing

And also: http://redump.org/disc/77974/

Those dumps are missing the video partitions IIRC.

http://redump.org/newdisc/53781/
http://redump.org/newdisc/53782/

Dumps needs to be examined by F1ReB4LL. Removed from WIP for now.

6

(3,291 replies, posted in General discussion)

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?

7

(3,291 replies, posted in General discussion)

Latest DIC still outputting incorrect multisession cuesheets? http://forum.redump.org/topic/41246/ibm … intergame/

And DIC or MPF are always scanning the .img instead of the .bin files, resulting in an incorrect error count for multisession discs. The gap between the sessions should not be included in the error count, because it's not included in the .bin tracks.

8

(3,291 replies, posted in General discussion)

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

iR0b0t posted in 2017: "needs a fix"

10

(3,291 replies, posted in General discussion)

Hello,

Intothisworld wrote:

From what I understand, the table of contents at the beginning of an audio CD lays out all the LBAs (or timestamps?) for tracks throughout the disc. So when a disc has an offset pressing, say shifted +88 from another similar release, are the LBAs/timestamps in the TOC shifted by +88 as well?

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

Intothisworld wrote:

And the second question is in regards to data potentially being shifted into the lead-in or lead-out... Would it be possible to add a feature to DIC where it automatically searches the lead-in/lead-out for non-zero bytes? And then if necessary adjusts accordingly (or at least tells you how to manually adjust accordingly)? Is there any technical limitation to something like that? If it is indeed possible, I'll go ahead and submit a request on the github, but if not, I don't want to waste anyone's time. Thanks again.

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.

11

(3,291 replies, posted in General discussion)

FYI, the supposed +30 reference offset that was discovered and announced by http://forum.redump.org/user/48/ was later disputed by his friend Truong (from Trurip). With his tests using an FPGA, he determined the true "zero" read offset to be +48 (used by Pioneer drives as read offset as opposed to the +30 used by Plextor) compared to EAC. When you look in Red Book there is a part somewhere which tells about 3 x 6 samples that could explain the 18 samples difference between the 2.

Anyway, it's all hearsay and irrelevant, because Redump uses combined offset correction whenever possible and for Audio CD's the EAC reference offset is the standard and used by databases like AccurareRip and CUETools that store checksums for many millions of discs. In the end it's just a number and if you only correct the read offset, regardless of the reference used, you can still end up with data being shifted into the pregap or lead-out that will be missing from the dump because the write offset isn't corrected.

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.

I guess we need to do more research.. maybe the SafeDisc scrambled data is also meaningful.. but I always assumed that there could be no good/reliable data hidden behind a C2 error.

sarami wrote:

Logs. https://www.mediafire.com/file/js0a6rkd … 29.7z/file
C2 errors: 1445. vs your dump http://redump.org/disc/31708/ is 722

Yeah but 1 of the 2 sectors is always just 22-23 bits.. do C2 errors take into account offset correction?

For intentional C2 errors like here we always fill with 0x55 pattern.

sarami wrote:

I reported this protection before. http://forum.redump.org/post/54050/#p54050
0xd8 dumping can get the string that is recorded in the disc. But redump db adopts the result of the 0xbe dumping less error count.

Are there C2 errors when dumping this protection?
And what's the explanation for the lower error count? Is the drive correcting bytes in 1 sector when using 0xbe?

The best route might be to find a CodeLock game that's already dumped on eBay US and see if you can verify that. The drive that can verify another dump should also produce a correct dump of the US Tropico. If the error count is the same as your current dump (and twice that of the Europe release) then it could be explained by different mastering.

http://redump.org/discs/quicksearch/cod … ction/only

Surely there's some cheap ones on medimops.de also if you search for the barcodes there (without spaces), but I don't know if they're shipping again to the US (they restricted it because of COVID).

17

(3,291 replies, posted in General discussion)

@sarami any way to get BCA data from gamecube discs with a PC drive?

18

(3,291 replies, posted in General discussion)

Thx.. same bug perhaps? https://drive.google.com/file/d/1pM0Kmb … 6CCAd/view
http://redump.org/disc/73323/

19

(3,291 replies, posted in General discussion)

Here's 3 logs with bad multisession cuesheets. Is this a bug that is already fixed or a new one?

https://www109.zippyshare.com/v/qX1iHqXW/file.html
https://www109.zippyshare.com/v/j0cYXyUz/file.html
https://www109.zippyshare.com/v/WqOmxrW7/file.html

And this CD-i dump seems to dump correctly with non-plextor and IsoBuster, but messes up with DIC + Plextor:
https://www29.zippyshare.com/v/iP7DufIh/file.html

20

(3,291 replies, posted in General discussion)

sarami wrote:
Jackal wrote:

No, not replaced with 0x55 but they can be "cleaned" somehow. I think the sectors match surrounding sectors except for the random error bytes which need to be cleaned so that they match (besides header). Perhaps it can be accomplished by rereading sectors and keeping the bytes that are most consistent between reads.

Ok, but who guarantees the kept bytes is correct?

If the sectors after "cleaning" the random errors all have data that matches the data in the previous or next sector, it's pretty safe.

21

(3,291 replies, posted in General discussion)

sarami wrote:
rosewood wrote:

Is there anything that be done about this problem or did I miss the solution?

The problem may be that there is not EDC in LBA 16. Perhaps it can read using 0xbe, not 0xa8. I don't fix it yet.

Neon Beast wrote:

The installed game will have these two files

There are some cab and hdr files in the disc. If they are Microsoft cabinet files, you need to use /mscf to detect DiscGuard.
The protection of 7K2 was detected as DiscGuard.

Detected a protected file [IOSLINK.VXD]. LBA 302 to 330
Jackal wrote:

I think there were some sectors without EDC where the random errors needed to be cleaned manually.

According to the 3 logs of Neon Beast, LBA 299 to 1498 do not have EDC. These should be replaced to 0x55 like SafeDisc?

No, not replaced with 0x55 but they can be "cleaned" somehow. I think the sectors match surrounding sectors except for the random error bytes which need to be cleaned so that they match (besides header). Perhaps it can be accomplished by rereading sectors and keeping the bytes that are most consistent between reads.

22

(3,291 replies, posted in General discussion)

Neon Beast wrote:

Hi, I have this Chinese release of Heroes of Might and Magic III, I got two copies with identical ring codes, but hashes don't match, and I can't get a consistent dump. It has DiscGuard protection, don't know if this is causing the problem.
Dumped with the latest test build.
Logs: https://mega.nz/folder/XzB3SYyL#0g-CNMwckW9kQgmEFv-iRQ

DiscGuard needs a special treatment. I think there were some sectors without EDC where the random errors needed to be cleaned manually. Maybe reentrant remembers.

http://redump.org/discs/quicksearch/dis … tion/only/

Neon Beast wrote:

I tried on this one, but IsoBuster still not working.

You need to open the .cue directly with IsoBuster. The screenshots shows an Alcohol drive as source and not the cuesheet.

Can you post a screenshot?

MrPepka wrote:

Oh, for the sake of clarity, those malfunctioning drives are the ones below:
http://redump.org/disc/69762/
http://redump.org/disc/69693/

Again, both dumps are fine. No errors and everything reads fine.

REM SESSION 01
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 3).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM SESSION 02
FILE "Wszystko Gra - Gazeta Uczy i Bawi - Kwiecien 2002 (Poland) (Track 4).bin" BINARY
  TRACK 04 MODE2/2352
    PREGAP 02:32:00
    INDEX 01 00:00:00
REM SESSION 01
FILE "FrogMan + Tajemnicza Wyspa (Poland) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
REM SESSION 02
FILE "FrogMan + Tajemnicza Wyspa (Poland) (Track 2).bin" BINARY
  TRACK 02 MODE2/2352
    PREGAP 02:32:00
    INDEX 01 00:00:00

Neon Beast wrote:

Hi, I have some multisession CDs that have data track in session 2, I can mount cuesheets with Alcohol but not the ccd file, and I can't get access to session 2, also IsoBuster fails to identify them as multisession CDs. I tried your method with no luck, am I doing it wrong? Here are some of un-modified cuesheets

You need to download the cuesheets from redump. The ones that are generated by the dumping tool aren't compatible. And then add the PREGAP 02:32:00 line like above.