Quoting Hoogo

I know how to double the accuracy....

Multiple laps at once, no? Don't forget the 16 MHz timebase though, you might need a rubidium clock fed from a GPS to reach that level. :)

Though it would make sense to do a running average over a few laps though to make for a less twitchy measurement.

What if the disk had some custom loader (like krill or the other one with even custom GCR?!).

For the time being and until proven without a doubt or at least until a sound theory is presented, we can regard the discussed drive-side methods as equal.

They measure the duration of a revolution with a fixed reference clock counting from a fixed reference point (angle) on the disk to the same point a revolution later.
They will produce a 2-cycle jitter (3 cycles variance), due to the bvc *, on top of the 16 MHz oscillator's tolerance (which has the bigger part in that), on top of natural rotational wow/disk wobble/flutter (probably the biggest part in that).

Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms).

Now, although somewhat pointless, getting rid of the 2-cycle jitter might be achievable by a half-variance technique operating on 2 additional byte-sync points, quite similar to syncing drive and host CPU in a fastloader with a synchronous transfer protocol.

Quoting Zibri

What if the disk had some custom loader (like krill or the other one with even custom GCR?!).

Not sure which loader you're referring to, but running on plain standard format, both low-level and file system, is what i deal in with the public IRQ loader.

we can regard the discussed drive-side methods as equal

Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms).

This is also one of the basic techniques as used for stabilising raster routines.

Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk.

After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles.

Of course, the disk will keep on wobbling, so there is some error left.

My program writes at the lowest density using "00" clocks in 1c00 which is synchronous with the cpu clock.