Anyways, I finally got Rhapsody's sound track submitted and all my checks seemed to come out correct- yay!.
The information here will help me a lot in the future

We can see the first three frames in the picture belong to track 2 (the Q-TNO), and that they are at the end of the song (see the time increasing 3:44.35, 36, 37.)

At frame 31434, we jump to Track 3's pregap. The Q-Index is 0, indicating we are in the pregap, and the time starts counting down from 1.28.

Frame 31536 is the last in the pregap, as we go to Q-Index 1 afterwards. In this instance, the pregap has counted down to Frame 1, but it can also count down to 0, like this:

(Basically, don't assume the pregap length based on the countdown start)

Now we know that the pregap starts at 31434 and ends at 31536. Subtracting 31433 from 31536 gives us a pregap of 103 frames, or 1.28. This coincides with the cuesheet generated by Subcode Analyzer and EAC's gap detection.

  TRACK 03 AUDIO
    ISRC GBJG00500048
    INDEX 00 06:59:08
    INDEX 01 07:00:36

P normally indicates the track start, but in this case it started 47 frames early. The subcode dictates that those frames belong to the end of track 2 though, not track 3.

On Rhapsody's music CD, both Subchannel Analyzer and EAC seem to be measuring the gap by counting the frames that have a Q-Index '0' combined with a P of 'FF' (i.e. 120 lines =1.45 gap etc), but they aren't counting the frames immediately above that have a Q-Index '1' and a P of 'FF' (see picture I posted above). That means they're detecting the gap correctly right?  I only wonder because if the '1+ff' frames are included in the gap with the '0+ff' frames, their total becomes 150 which seems suspiciously close to a standard 2 second gap.

Thanks, good to know. I didn't mean to spread misinformation, I just wanted him to know there's no disc offset hunting involved in audio CDs.

Sorry about that. This was the case in the all of discs I had looked at, but I dumped more subs and found exceptions. The Q-INDEX and Q-Frame sequence is what matters.

Audio CDs don't have a disc offset, so only your drive's offset matters.

They do, we just unable to determine it. Basically, yes, you should dump it with your drive's offset, but it would be better to check the lead-in and lead-out areas, some non-zero bytes can present there, if so - tweak the offset value to include ALL the data.

The first frame with Q-INDEX of 0 is well into the 'frames with mostly fs' instead of the first  having a 'P of 0s'. Should I just ignore this and trust EAC's/SubAn's gap analysis?

So a CD's offset is basically a data shift distance that occurs between the data track and audio tracks, but not on data-only or audio-only CDs?

Any disc with a data track will have one, including data-only. Data tracks have their offset handled automatically out of necessity.

Discs can have crazy gaps, but you can check them yourself.

Dump the disc with CloneCD and check the sub in Subcode analyzer. Gap frames are going to have a Q-INDEX of 0. The first in a set will have a P of 0s, followed by followed by frames with mostly/all fs. The Q-Frame sequence will also be linear across the frames. Subcode analyzer can make a cuesheet for you, which will show you the gaps. There are 75 sectors per second (4500/min), which enumerates like 0.73 0.74 1.00. Remember that when you're trying to translate sectors to seconds and vice versa.

If one of your drives can over-read, then sure. Pop up the sector viewer and try to view a sector past the last, if you get data instead of an error code, you're good to go.

Assuming the drive's offset is >0 and <+588: Extract from-to the track, set a fixed end address, subtract the pregap length in sectors from the start address, and set the end address to +1. Hex edit the resulting file, deleting the first (drive offset*4) bytes from the beginning and (2352-(drive offset*4)) bytes from the end.

Now if you want to verify that track on a drive that can't over-read, do the same without adding +1 to the end address. Delete (drive offset*4) bytes from the beginning, but add that many bytes of 00 to the end. So if your drive had an offset of +12, you'd delete the first 48 bytes, and add 48 bytes of 00 to the end. Since the drive can't over-read, you'll want to first verify that the truncated bytes are indeed 00, otherwise you risk losing data.

I see other PS sound tracks in the database so I figured out that question myself.

EDIT: A couple more questions- 
EAC shows irregular gaps (1.45, 2.43 etc) on the CD tracks;  is that normal?
Except for the last track (which gets a sync error) , I get no errors and identical CRCs on all the tracks from both dumps. Is there a way to manually dump the last track in ISO buster?