Okay, sorry for the delay, disco party over. At 555.6 Hz and the table strobe locked (stationary) the speed seems correct (no motion on 60Hz indicators).
Just so happens I just recorded Yes - Tales from Topographic Oceans (yes, progressive overload) but handy as it is one track per side.
I compared the track lengths (after I split) to the track lengths listed on Discogs and was right about 4 seconds longer on each track/side as the listing. If you include lead-in/out and the like the cascading effect over the record is that the difference between the recorded and indicated (by discogs) breaks/splits get further and further from each other which is understandable. My lead in on track 1 is 14 seconds before the music starts (your results may vary). This would be dependent on how the table is set up (for automatics) and where you decide to drop the stylus (manual cueing). Add the 20 seconds at the end for the software to stop recording and the difference is going to keep getting bigger as you add sides.
Add to this the differences on Discogs and whether anyone bothered to put in the actual track length and it all becomes somewhat of a crap shoot and the software can't guess.
However, the "scan for track breaks" functionality, which I don't use very often, might help matters depending on whether there are actually breaks.
Using the Beta version and the behavior between sides has improved. It used to separate end and start breaks and, if the music tailed off, it would jump to the next side without being able to listen to what was happening. Now it puts in a break that makes it easier to do audible differentiation.
So I believe that the problem isn't with the software or hardware but just the way track lengths are defined.
At least my turntable isn't screwed up eh?
Now to sort out normalization on my end. Gain controls on A/D converter are overly sensitive and the L/R channel conundrum (as the stylus tracks across the record) comes into play.