More data on "REPEAT" command behavior

So today I pulled out a random disc from my collection and it turned out to be Cliff Hanger.  I haven't played this disc in literally 10 years so I was nervous to see how it had held up.  Fortunately, it seems to be in the same condition it was 10 years ago; no rot!

This is the first time I've captured the VBI on Cliff Hanger, and I learned (to my surprise) that all of the frame numbers are stored in the second field of each frame, which is the same "trick" that Firefox and Freedom Fighter use (although I have to admit, I have never understood what the benefit of doing this is).  So it turns out that this disc was a good test for this situation.

Again, I told it to do two passes and to stop on frame 298 (because there is where a natural break in Cliffy's attract mode is).

When it gets to the track that houses frame 298, it displays the first field (which contains no frame number).  Then it displays the VBI for the second field (which DOES have the frame number 298) and displays the first few lines of the field, and then black.  For the purposes of Dexter, I feel comfortable always displaying a completely black field in this case.

It seems pretty evident that when the frame number is read from the VBI, that the search is intended to take place ASAP and no further fields are intended to be displayed.

Now, what does it do on the second pass?

It overshoots by 1 frame every time.

So in this case, if I tell it to stop on frame 298, it will stop on frame 299.  I've tested this by telling it to stop on frames 298, 299, and 300 and it always overshoots by 1.

Next I am going to test on a disc with conventional VBI (ie the frame numbers on the first field instead of the second) and hopefully with all of this data, I will be able to come up with an algorithm for predicting whether it will stop on the requested frame over overshoot by 1.

UPDATE : Just tried Dragon's Lair 2 disc and it is organized the same way as Cliff Hanger, with the frame number appearing on the second field.  Maybe something is wrong on my end!

UPDATE #2 : Just tried Time Traveler and the frame numbers come on the first field of the frame.  The disc still overruns by 1 frame when pausing.  So it looks like the 2:3 pulldown case is an exception which I will need to study a bit more before I can predict how it will behave.

UPDATE #3 : I just went back to the 2:3 pulldown disc and noticed it is also overrunning by 1 frame, but the frame it overruns into has no frame number which is why it appears to not overrun.  So that settles it.  It will always overrun into the next track no matter what!  Now to code this up and write some unit tests...