Rhaosody & px_d8 question

Thanks for the quick response,

Is that package included in your post the same thing as generating a 2 second pregap and merging it with the original track 2 to create a new track02good.bin file? See example below.

psxt001z.exe --gen pregap.bin 352800

copy /b pregap.bin+track02.bin track02good.bin

If it's not the same thing, how would I know when to use the bat files if I'm dumping a new game with the same problem?

Yeah, on negative combined offsets, EAC cuts off data from the beginning of track 2.

In order to combat that, you can dump the track manually in ISOBuster.

For this game specifically, in ISOBuster, right-click extract from-to the 2nd track. First, click the End Address bubble, then subtract 150 from the start LBA. Extract.

Open the resulting file in a hex editor. Insert 2,468 (617*4) bytes of 00 at the beginning, and delete 2,468 bytes from the end.

If you're uncomfortable with hex editors, you can instead:
psxt001z.exe --gen offsetfix.bin 2468
copy /b offsetfix.bin+track02.bin track02good.bin
FPCopy64 -r "track02good.bin" -2468

For other games, there's a couple of precautions to take. Firstly, always calculate the correct number of bytes to shift with offset * 4. The second, and most important, is that if the game has >2 tracks, you have to delete track 3's pregap from the end of the file in addition to some bytes.

The only other precaution I can think of is that ISOBuster will not have error recovery as good as EAC, so if you're going to use this method for a new entry, be sure to dump it a couple of times (preferably in a couple of drives, too).

Not if you use "Extract RAW", which is what "Extract From-To" uses by default.

I have matched dozens of -647 offset tracks from ISOBuster with EAC rips from my GH20NS15 (+667). If this were the case, EAC would also have to give bad data.

Renegade Racers, Track 2 EAC GH20NS15:

Track  2

     Filename C:\!Redump\NotSubmitted\RenegadeRacers\GH\Track02.bin

     Pre-gap length  0:00:02.00

     Peak level 96.5 %
     Track quality 100.0 %
     Test CRC 3B68D7A0
     Copy CRC 3B68D7A0
     Copy OK

Renegade Racers, Track 2 ISOBuster + Hex editor PX-760A:

Calculating hash of 22127616 bytes file `C:\!Redump\NotSubmitted\!ActuallySubmitted\RenegadeRacers\T2-PX`...

SHA-160     : 032FAB688A27767B20C878DEC7F303275FC65855
MD5         : C4A8A3E3F2D4FE7A0414C9EFB0176591
CRC-32      : 3B68D7A0

Calculation took 0.374 seconds

Thank you all for responding and offering assistance.

Why would I need to resize track 02 by 2468 bytes? I haven't done this on any of my other 2 track dumps?

I usually just do the following when dumping a 2 track disc

FPCopy64 -r "track01.bin" -352800
      (assuming the pregap is 2 seconds)

psxt001z.exe --fix "track01.bin"

psxt001z.exe "track01.bin"

psxt001z.exe --gen pregap.bin 352800
      (assuming the pregap is 2 seconds)

copy /b pregap.bin+track02.bin track02good.bin

Should I be using the FPCopy64 -r "track02good.bin" -2468 command for all 2 track discs?

I tried my normal method of dumping then used the above command to resize track 2 but it still didn't match the database entry.

I tried dumping this disc with Perfect Rip (using the Sega CD guide in the forums) & it matched the database entry exactly. I guess my only question is why can't I get the disc to match the database entry through the normal method of dumping? Are we sure that perfect rip is producing accurate results?

But I thought that was what the copy /b pregap.bin+track02.bin track02good.bin command is for, isn't this adding the pregap to track 2?

Also I was able to verify other 2 track games such as Dino Crisis 2 without using a remove or resize command, all I used on track 2 was

psxt001z.exe --gen pregap.bin 352800
copy /b pregap.bin+track02.bin track02good.bin

I'm still a little confused on when I should be using the remove / resize command. I just want to make sure I understand in case I encounter a disc with a similar issue.

Lastly, since EAC didn't show any errors, how would I know that I have a bad dump of track 2 (assuming this game was undumped and not in the database)? Since EAC and Perfect Rip are coming up with two different results how do I know which one is correct?

That's why I had him dump a sector range starting 150 sectors early, to include the pregap that technically lies at the end of track 1. If I'm not mistaken, the CD layout in ISOBuster looks like this:

Thus, for a 2 track disc you have to keep the same end address but set the start address back (into t1's sector range) to include track 2's pregap. In a 3+ track disc with linear gaps, for all but the last you start early with a relative end, which adds a track's pregap and simultaneously removes the next track's gap. Give or take a sector or two to later account for the offset.

Offsets shift data, resulting some of it to lie in a normally inaccessible range.

The effect is that, for a negative offset, the data is pulled back into the pregap, and the pregap is pulled partially into the data track (unaddressable). The data is still in an addressable area, but unfortunately since it lies in the pregap located in track 1 (like the graphic above), EAC refuses to read it. This data that is pulled back into the pregap is lost, so in your case 617*4 bytes from the beginning of the track's data is replaced with 00s.

For positive offsets, the data is pushed past the end of the track, so we need a drive that can over-read.

Since EAC refuses to read into track 1's range, we can use ISOBuster to do this. We dump track 2, but modify the sector range in extract from-to to include its pregap that lies in Track 1. The end result is that we have a track of the proper length, but mis-aligned due to the offset.

Here's where copy /b and remove fits in.

With our negative offset, we lose the first 617*4 bytes of the pregap to the data track, so we have to put it back. We generate some dummy data with psxt001z to account for the lost bytes, and stick it back at the beginning of the track.

Now our track is 617*4 bytes too long, but the data at the end never belonged to the track to begin with (this is that white space at the end of the rectangle). We can safely delete it.

The result is that we've re-aligned the data back into its normal area.

I'm having similar issues to Specialt1212 so thank you for the great explanation velocity37.

I have multiple copies of several PS1 games and I have found two games so far (Rayman, Darkstone) with identical data but different offsets (+2 and -617?). The end result is that my +6 drive can easily dump the +2 copies and have it match the database, but I have the same problem as Specialt1212 with the -617 copies. In ISO Buster's 'Sector View', the -617 disk's data is identical to the +2, but it's pushed back by about 1 1/4 sectors.

I decided I'm not going to dump a game whose offset doesn't produce the measurable 'garbage' data to assure the total offset because the odds of me making a mistake if I manually extract an audio track is just too high.

Yes. If you have a combined negative offset, dump the first audio track in ISOBuster.

For two track games, push the end address bubble and subtract the length of the pregap from the start address (150 for two seconds, for instance.) For multi-track games with identical gap lengths, do the same without hitting the end address bubble. For games with differing gap lengths, check the end address bubble, then subtract track 2's pregap length from the start address, and track 3's pregap length from the end address.

Use the following commands on the resulting ISOBuster BIN file, where the number is (offset*-4). For -617 combined, this would be:
psxt001z.exe --gen offsetfix.bin 2468
copy /b offsetfix.bin+ISOB_T2.bin ISOB_T2Good.bin
FPCopy64 -r "ISOB_T2Good.bin" -2468

------

I've also had a couple situations where EAC would give a sync error on a flawless disc (My GH20NS15 fares fine, but my PX-760A and FX54++M don't like these weird discs). PerfectRip does well here, but for those where this is not an option, you might also have the need to manually extract a track on a disc with a positive combined offset.

The method is a little different. Before you touch anything in the extract from-to dialog, if the combined offset is >+587, you need to divide it by 588 and add that to the start address (while the length bubble is still ticked). After you've done that, set the dialog options as you would with a negative offset disc. After that, add +1 to the start address (and the end address field if that is checked). If you had a large negative offset, pretend the resulting bin file has an offset of the remainder. For instance, my GH20NS15 is +667, so with a +2 disc (+669 combined) I would add 1 to the start address and pretend herein that the offset is +81.

Once you have your dump (with real or pretend offset), we have to get rid of that extra sector we added. This is different from a negative offset, since we have to delete data from the beginning and end of the file. You fire up a hex editor, delete offset*4 bytes from the beginning, and 2352 - (offset*4) bytes from the end. On my GH20NS15, this would mean 324 bytes from the beginning and 2028 bytes from the end.

I have no idea why EAC does that on specific discs in specific drives, but every time I've manually extracted the tracks, they match EAC on the GH20NS15 and PerfectRip on the Plextor.

That's good to know. Such sectors would be in like, track 5 though?

Here's a sub of one of the discs it happened on, at the end of track 5. ISOBuster says the pregaps are all 00s.

TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 | 17:08.66 |         0    |    77165   
        2  | 17:08.66 |  0:33.51 |     77166    |    79691   
        3  | 17:42.42 |  1:28.38 |     79692    |    86329   
        4  | 19:11.05 |  3:00.62 |     86330    |    99891   
        5  | 22:11.67 |  0:43.00 |     99892    |   103116   
        6  | 22:54.67 |  1:06.03 |    103117    |   108069   
        7  | 24:00.70 |  1:00.71 |    108070    |   112640   
        8  | 25:01.66 |  2:32.06 |    112641    |   124046   
        9  | 27:33.72 |  0:05.71 |    124047    |   124492   

GH20NS15 gave:

Track  5

     Filename C:\!Redump\NotSubmitted\PSM03\GH\Track05.bin

     Pre-gap length  0:00:02.00

     Peak level 100.0 %
     Track quality 100.0 %
     Test CRC 70B5EA80
     Copy CRC 70B5EA80
     Copy OK

While the plextor did:

Track  5

     Filename C:\!Redump\NotSubmitted\PSM03\PX\Track05.bin

     Pre-gap length  0:00:02.00

     Suspicious position 0:00:42

     Peak level 100.0 %
     Track quality 97.5 %
     Test CRC 099CEF93
     Copy CRC 099CEF93
     Copy finished

With a sync error. The disc is spotless, and matched CRCs when using PerfectRip and ISOBuster to extract on the Plextor. Any clue?

Argh, I forgot. This forum truncates 7z files.
Mediafire: http://www.mediafire.com/?4ugyum5wnzl

What's weird is that my Mitsumi FX54++M also sync errors.