• From: California USA
  • Registered: 2009-05-17
  • Posts: 219

I'm trying to dump the Collectors' Edition version of the two-track PSX game Tarzan and I've encountered something new to me. So I could use some confirmation from more experienced dumpers that I'm doing it right. 

Some info:
Track 2 is blank (all 00s) so I can't see where the gap ends and the actual data begins.
EAC detects the gap on track1 as '2' and on track2 as '0'.

Some things that are happening differently than I'm used to:
When I go to 'sector view' for track 2 in ISOBuster, it opens to the exact end of track1 (IE to the beginning of the 'garbage data' generated by my +667 drive) instead of opening to the end of track2's gap like I'm used to.
Usually, ISOBuster shows the size for the last track to be larger than it ends up dumping in EAC. But, in this case, EAC dumps track 2 at the same size shown in ISObuster.

Does the 'gap' listed by EAC for track1 end up attached to track2's as it's 'pre-gap'. If so, is the 'gap' for the last track just discarded since there's no 'next track' to attach it to? That would explain what I'm experiencing anyways. Any advice about how to dump this correctly would be appreciated.

HwitVlf's Website

2 Reply by velocity37 (edited by velocity37 2010-05-21 17:05:54)

  • Registered: 2009-12-29
  • Posts: 220

HwitVlf wrote:

EAC detects the gap on track1 as '2' and on track2 as '0'.

This always happens on two track data+audio discs. It's an EAC bug, which is rather annoying. You can use PerfectRip if your drive supports it. You can read about its usage in the Saturn / Mega CD sticky.

Your case is a special exception, though, because...

HwitVlf wrote:

When I go to 'sector view' for track 2 in ISOBuster, it opens to the exact end of track1 (IE to the beginning of the 'garbage data' generated by my +667 drive) instead of opening to the end of track2's gap like I'm used to.

Then track 2 has no gap. I've run into this with San Francisco Rush.

HwitVlf wrote:

Does the 'gap' listed by EAC for track1 end up attached to track2's as it's 'pre-gap'.

Nope. The CD layout is append to previous, like this:

http://i49.tinypic.com/23myvk.png

If track 2 had a pregap, it'd be added to the end of track 1 (which is why you have to trim that track normally)

In your case, you should find that you won't need to trim track 1. When you extract the track and fix it with psxt001z.exe, you should have no warnings about additional errors. When you scan with CDMage, you shouldn't find any errors at the end. If the track had a pregap appended to it, there'd usually be 151 (last sector + 150 sector [2s] gap) errors before trim+fix.

Psxt001z's projected image filesize should match up to your final fixed data track+gapless track 2.

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

Thanks velocity, that info is really helpful. I'll check into PerfectRip. So when EAC 'detects gaps' on (for example) a standard three-track disk, the 'gap' listed for track 2 and 3 end up attached to the beginning of those tracks, right? What was confusing me a little: EAC lists 3 gaps for a disk with 2 audio tracks. Does the 'gap' detected for track1 end up attached to the beginning of track1?

PSXtoolz and CDMage didn't detect any errors in Tarzan's track1's dump (using ISOBusrter's 'extract track01' +PSXtools 'fix'). What is the psxtoo1z command to project image filesize?

Is the following method correct for dumping track2? Disk is -12 and drive is +6 (with overread support):

1) Dump track 2 in ISO buster using 'extract from-to' with the preset start address minus 1 (to accommodate -6 combined offset) and leaving preset end address as-is.

2) Delete data equal to one sector minus the combined offset from the beginning of the track (2352-24 bytes = 2328 bytes).

3) Delete data equal to the combined offset from the end of the track (24 bytes).

HwitVlf's Website

4 Reply by velocity37 (edited by velocity37 2010-05-24 10:32:49)

  • Registered: 2009-12-29
  • Posts: 220

HwitVlf wrote:

So when EAC 'detects gaps' on (for example) a standard three-track disk, the 'gap' listed for track 2 and 3 end up attached to the beginning of those tracks, right?

Track 2's gap will be appended to the end of track 1, and track 3's gap to the end of track 2. Each track ends with the next track's gap, except for the last. As for track 1's gap, it's discarded.

When we choose "Append To Next Track", we're telling EAC to instead place these gaps at the beginning of their respective tracks, as you described.

HwitVlf wrote:

What is the psxtoo1z command to project image filesize?

If you run: psxt001z.exe "Track01.file"

You'll get two different sizes like:

Size (bytes):   181503840
From image:     576155328

The second line should match the total filesize of all of your tracks.

HwitVlf wrote:

Is the following method correct for dumping track2? Disk is -12 and drive is +6 (with overread support)

That would be the correct procedure, however, I don't think this method will be reliable in this instance, since the first 24 bytes are pulled into the end of the data track instead of a pregap.

What I would do is verify the first 24 bytes in a drive that had a positive combined offset. Then you can dump the track normally (right-click extract), delete the last 24 bytes, and insert the first 24 bytes that you verified in another drive into the beginning. This would be the first 24 bytes after the garbage data.

  • From: California USA
  • Registered: 2009-05-17
  • Posts: 219

Thanks so much for your help Velocity. I verified (using a negative combined offset drive) that the last 24 bytes are all zeros, and also verified (using a positive combined offset drive) that the first 24 bytes are all zeros so hopefully I got it right.

HwitVlf's Website