Rhaosody & px_d8 question

[Specialt1212]

-2468 are the bytes in offset -617 => 617 x 4. IsoBuster dumps a track with no offset correction, so you do it manually. You have to dump track with IB, not with normal method.

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?

[Rocknroms]

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?

yes it's adding. If you get bad result after adding pregap you simply got a bad dump.

resize => deletes bytes
remove => moves bytes from file to file

You have to use resize to cut pregap from the end of data track (but you can use remove too and than delete the temp file created). Resize is better when you have to move bytes from a track to another.

The command you use is exactly what you have to do, but about DC2 you are lucky because there's no byte lost due to negative offset.

EAC result on single audio track discs is always bad because it doesn't dump pregap and may cut of data if you have a negative offset (moreover if there's data in pregap this will be lost at all).
EAC shows error only if it finds error on disc or if cannot overread. The "no-pregap" issue is a bug.

Simply use PerfectRip (you have a plextor and dumps are also speeder) to dump all tracks, then check data track with Isobuster and audio with EAC. If track02 doesn't match is because of cutoff data, data in pregap, etc. so forget EAC for those tracks.

If you got strange gaps, and if EAC gaps don't match PR ones, you have to submit a subcode.

[velocity37]

Now that I read better Velocity method there's a mistake because IB does like CDRwin and attaches gap to previous track. So to get the right track (for a single audio track CD) you have to add also pregap manually.

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.

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.

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.

[Rocknroms]

That's why I had him dump a sector range starting 150 sectors early

Sorry I should be blind, by the way this is always risky if you have data in pregap as ISObuster scrambles those sectors to match audio.

If I'm not mistaken, the CD layout in ISOBuster looks like this

Yes layout is right. As above: within data and audio you can lose data (let's say that you can recover it if it's simply empty) with this method (probably not with psx, but with SS/CD32 it can happen).

[HwitVlf]

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.

[Specialt1212]

Thank you both for the help! I'm pretty sure I understand the concept now. But just to make sure, the only time I would need to use the FPCopy64 -r "track02good.bin" -2468 command would be if I have a negative offset, correct?

And I may need to adjust the -2468 value depending on what the combined offset is, correct? I assume the calculation would be, combined offset times 4.

In the future I'll probably dump any new discs using Perfect Rip and compare them using ISOBuster + EAC. If I find any discrepancies I'll dump the track 2 manually using ISOBuster.

[velocity37]

the only time I would need to use the FPCopy64 -r "track02good.bin" -2468 command would be if I have a negative offset, correct?

And I may need to adjust the -2468 value depending on what the combined offset is, correct? I assume the calculation would be, combined offset times 4.

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.

[Rocknroms]

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.

When you find a situation like this it's always better to submit subcode and check it. When a sync error happens at 99% you have data sectors in audio pregap (due to sync error, one of the situation I talk about above) and pregap lenght could be different from what you see both in EAC and PR. It has been discussed in the past and those bytes have to be saved as they are on disc, so if you use IsoBuster you can get a bad dump.

In the future I'll probably dump any new discs using Perfect Rip and compare them using ISOBuster + EAC. If I find any discrepancies I'll dump the track 2 manually using ISOBuster.

If you find discrepancies, submit a subcode taken with CloneCD and with the right options.

[velocity37]

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.

Code: Select all

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:

Code: Select all

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:

Code: Select all

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?

[Rocknroms]

The file you uploaded is corrupt, if it's a sub it's better to upload it to mediafire than here. I'll check once uploaded.

By the way it's not the same situation I'm talking about. This disc probaly has some sectors EAC+plextor don't like (probably due to drive speed).

ISOBuster says the pregaps are all 00s

You don't have to follow IB sector viewer because sectors will be moved by offset correction.