Your post is a bit misleading. Timing a console run generally goes like this: Recreate run in emulator -> get frame count from emulator -> divide frame count by FPS of NES -> time of run in seconds.
Your method assumes that the milliseconds of the time is already known, which is not the case when timing runs; in fact, the reverse is how we get the exact time (using the frame count to get the final time). So while the algebra in your method works out, it's not applicable to any situation because we would already know the frame count if we knew the exact milliseconds. If you take a run that was timed with a stopwatch and apply your method, the frame count has a very, very high chance of being incorrect.
Also, for future reference, the frame rate of the NES is 39375000/655171 or ~60.098814, not 60.000.
Any% (NTSC) runs below 4:57.000 must now fulfill additional requirements in order to be verified.
- The run's full session must be included in the submission description.
- For emulator runs below 4:57.000, some form of input display must be visible for the duration of the run. A hand-cam or input
