idea: everyone starts using sliding timer stops to protest against the wca
(jk please don't do this)
This is an extremely important point to consider. By WCA guidelines, the judge is even supposed to look at the timer itself when writing a result to reflect complete accuracy. The display does not reflect the exact time of the timer throughout the solve. In some very rare cases, it also sounds like the display doesn't shiw the correct time AFTER a solve either (I've never seen this, but the regulation must exist for some rare occurences.The frame-by-frame analysis in the video posted above doesn't appear to take into account that the display may not accurately reflect the time on the timer itself at each point. It also makes an assumption about the FPS speed of the video itself - can this be taken to be accurate?
Instead, we can use this method that Ibrahim Khanani uses instead https://docs.google.com/document/d/1syPge3vcj1oMw7l6qaRPgFdXmUZnkf3U0jNWoBAPkVk/editDisplays don't update the time quick enough for it to be a reliable reference during real-time solves.
Intentional or not, disregard for the regs is not good.He's 10, is he really trying to find a way to bend the regs to his favor?
If the excuse is that 10 year old children cannot be trusted to follow simple rules perhaps the following logic declares an age requirement be set in place to be able compete...You guys are REALLY trying to find a reason why Yiheng can have another record canceled. He's 10, is he really trying to find a way to bend the regs to his favor? I think not. Timer starts! Come on
I'm being pedantic, but it relates to my earlier point:Instead, we can use this method that Ibrahim Khanani uses instead https://docs.google.com/document/d/1syPge3vcj1oMw7l6qaRPgFdXmUZnkf3U0jNWoBAPkVk/edit
Here, he measures the pure exec time and compares it to the recorded time. In the first solve of the 0.78, the pure exec time (0.76) was apparently longer than the recorded time (0.74) he got. This could be proof that Yiheng did a turn before/after the timer started/stopped.
assumption about the FPS speed of the video itself - can this be taken to be accurate?
At least in Yiheng 0.78s case, Dylan Baumbach had both 30 and 60 fps footage, and found that the pure exec time was slower than recorded result.I'm being pedantic, but it relates to my earlier point:
Unless I've misunderstood what Ibrahim has done here, he hasn't actually measured the pure exec time - he appears to have used a frame count as a proxy? And that relies on an assumption of various different cameras (or, more likely, phones) running at a constant and predictable frame rate which never varies, either before or after compression and upload to YouTube. In other words, he's done an experiment missing an important element of control.
If we assume an intended frame rate of 60FPS recording (and I'm not sure exactly if we should), what's the likelihood that someone with a brand-new iPhone is running slightly ahead at say 61 FPS, vs someone else's old Nokia which is nearly out of battery running at say 59 FPS? That would be enough to turn a 0.74 into a 0.76 based on frame counting alone due to hardware differences. I'm not a hardware engineer, so what am I missing?!
Mobile phones almost always record at slightly variable framerate. However from my video editing experience this is very negligible. At least not noticeable enough to cause audio desync which would happen if it were I estimate 0.2 s off or more. You can go through the video with ffprobe to see the actual millisecond values for each frame.That's interesting - thank you - but it hasn't actually fully answered my point. If the equipment used to measure the count of the frames hasn't been independently tested or verified, all it potentially shows is that something labelled as "30 FPS" is running half the number of frames as something labelled "60 FPS", not the ACTUAL verified frame speed.
Thread starter | Similar threads | Forum | Replies | Date |
---|---|---|---|---|
Yiheng Wang 0.49 single/0.90 avg (2x2, AsR2) | WR/CR/NR solves | 29 | ||
D | YiHeng Wang .78 2x2 Average | WR/CR/NR solves | 2 | |
Z | [Unofficial] Yiheng Wang 2x2 Average: 0.71 (YTWB?) | Puzzle Video Gallery | 11 | |
Z | Yiheng Wang 2x2 Average: 1.15 (BPA 0.76) | General Speedcubing Discussion | 19 | |
[PR2] Yiheng Wang 2x2 Average: 0.99 | WR/CR/NR solves | 7 |