By the way, track 1 is not the warning track commonly found in Japanese games. It's actually the English warning track found in US releases.

How do I do this?

could you extract track that precedes data track (Track 01 usually) with IsoBuster and take a look at it with hex editor, please?
what does 1st and last data sectors (i mean those at the end, from 2nd part of gap) look like in there?

yes, usually
only a couple of Audio CDs had it different so far, i think

basically you prepare drive so cover can be removed freely, then place Audio CD in tray, let drive detect it,
wait until it stops spinning, without ejecting tray remove cover and replace Audio CD with one you are going to extract
and put cover back on, so drive still thinks its an CDDA and will process your CD this way -
as one continuous stream of audio data (so no gaps at all and it will allow to read as far as TOC of Audio CD goes)
it's described in more detail here
except you don't need special Trap CD - any fairly large Audio CD should work
and extraction can be done with IsoBuster

How do I do this?

Should the pregap for track 1 be showing as 2 seconds in EAC?

What is the swapping method?

so, yeah, it should be this way - EAC's file is messed up
IsoBuster's is correct, once header is replaced with $00

about other drive - i guess it has exactly same or close offset
and EAC can't overread as well, not all drives report errors though

you could try to disable Overread and see what happens
but please don't leave this option that way, because generally you won't know when data was lost then
or leave it on for one drive and off for other, if you're going to use both
still on PCE offsets are pretty large sometimes, like 5 sectors or so - you won't be able to overpass those this way
so it's really better to be able to overread

to 01CF492F:

Why is this?

I have another drive I'll try with IsoBuster later. I dumped track 4 with EAC using that drive earlier and I got an identical file as with EAC with this drive. I didn't get any errors with EAC through that drive. It uses caching, though.

yes, so you'll end up with header from 2nd pic at the very end,
please replace it with 0x00 since IsoBuster made this data up
and i guess what you'll get will match to EAC file then
so trouble for nothing basically
but anyway you know now that your drive does not overread into Lead-Out
so you'll generally have problems with positive combined offsets at least,
still if there is no other drive available it's possible to overcome this with swapping

Is that actual data that's showing up at the end or filler data by IsoBuster? Everything else is zeroes.

The data that corresponds to the ending of the EAC track can be seen here:

Does this look right? Everything after 30364320 bytes should be trimmed, correct?

since your offset with this drive appears to be 10 from those logs you posted
remove 10 samples (40 bytes) from the beginning of file you'll get (CD Segment.bin)
and (2352-40=2312) from the end
(btw this fragment you remove from the end should contain no data: all be 0x00,
otherwise offset value likely is wrong)
so final size should be 55843+1-42934=12910 sectors = 30364320 bytes
and so this is last track with corrected offset - it should match to one extracted with EAC
except former will have more meaningful bytes at the end, where it's all 0x00 already in EAC version

There's a new development with the dumping process that I didn't notice last night. EAC is giving me a sync error on track 4. Actually, it didn't occur last night since I had accidentally set a couple things incorrectly. Earlier I had not had the "Overread into lead-in and lead-out" option checked. When ripped with the option unchecked, EAC gives a track quality of 99.8% and does not report a sync error. When checked, the sync error is reported and the track quality is 92%. The files always come out byte for byte identical each time the track is ripped. Could this kind of thing be caused by a mastering error or some sort of junk data in the leadout rather than a surface defect? If it is a surface error, does the consistency of the data between different rips tell us that it's being compensated for correctly?

Overread log

No overread log

I just wanted to let it be known that "resize" does work on Vista.  Maybe it doesn't work on Vista 64 bit though.  I have 32 bit Ultimate and it does indeed work on my end. 

If you have Vista 32bit as well, try running the prompt as administrator or disable the whole UAC thingy.  Most Vista problems are because of that crappy feature.

PCE CDs can be somewhat difficult to extract though unless you open up drive and do swapping
but i hope this won't be the case

to answer your questions:
1. offset value is not dependant on gaps in any way or vice versa,
gaps just happen to be place where it manifests
so once it is determined you would extract all tracks with same value
you can find offset for PCE CDs the same way as for the rest systems,
between Data->Audio tracks (when offset is positive) and also Audio->Data tracks (if it's negative)
so in this case you'll be looking at Track 02->03 gap at first as if they were Tracks 01 & 02 from guide
if nothing is there, then likely offset is negative and you should examine Track 01->02 gap instead

negative offset is determined following way:
click Sector View on Data Track (02) - IsoBuster should position on it's 1st sector from TOC
e.g. 3596
go 150 (usually but in rare cases this value can be different) sectors back
e.g. to sector 3446 and there should be sense error instead of nulls
(or it could probabbly be data sector on some drives but either way it shouldn't be nulls)
(this is how you can determine value different from 150 for previous step)
go one more sector back and there should be scrambled data
so for example on my +6 LiteOn drive Tengai Makyou: Ziria look this way:

and math is:
$930-$278=$6b8=1720
-1720/4=-430
-430-DriveOffset=-430-6=-436
if whole 1st page would be full with scrambled data you'd increase offset by -2352 or -$930 bytes, and so on

alternatively you could try Truman's excellent px_d8 program - it would really ease things a lot
but unfortunately most drives do not support this command
for LBA parameter any data sector can be given,
so 0 won't fit for PCE most of the time, but likely something around 4000 should

output for same CD on +30 Plextor:

Sector: 4000
MSF: 00:55:26
Combined offset: -1624 bytes / -406 samples

-406-DriveOffset=-406-30=-436

so i would extract with -430 offset on one drive, with -406 on the other and submit -436 to db

also very often for Japanese PCE CDs 1st track is common one with CRC value b979500c
this is the case for commercial release of Ys IV currently in db
and by track size also could be true for your CD
so this could hint whether offset was determined right or not

2. yes, you're right - in IsoBuster's options default extension can be configured to be either .iso or .bin
and does not influence file content in any way,
so as long as you extract raw 2352 byte data - it shouldn't matter

3. yes, it should be fine

one proble you'll run into though: Track 03 pregap appears to be determined incorrectly by EAC
(which can happen quite often for PCE CDs)
so likely you'll need to cut it's 1st sector after extraction -
you should be able to tell this from file sizes and content of last Track 02 sector after 2sec gap is removed

edit:
ah, i forgot about data track pregap - usually drive won't be able to extract it correctly,
so unless you'll be doing swapping
you'll need to determine of exactly how many data and audio sectors it consist
(like when looking for negative offset)
and then recreate it with generic data and prepend to Track 02

I read through the PC Engine topics on the forum and it seems the exact format in how exactly to handle pregap information may still be under debate. I've gotten some of the requisite strange numbers in experimenting with ripping this disc, so I'd like some advice on how to get the most accurate rip possible.

1. I'm not sure I quite understand offset value correction. With PC Engine CDs, is the offset value correction in EAC handled the same way as with other systems? Because track 1 is a music track, track 2 is a data track, and then track 3 is another music track with a different pregap value, do I need to rip the first music track with a different offset value correction than track 3? What about track 4, which has a pregap of 0?

2. The Redump PC Engine images I've downloaded from Underground Gamer have had both the data tracks as .bin extensions rather than the standard .iso rips I'm getting from Isobuster. Is there some sort of extra conversion process to .bin or do I just change the file extension?

3. I'm running Vista, so I can't get Resize to run. Manually editing the file with a hex editor should provide the same result, correct?

Thanks in advance for any information or advice you can give me.