I am posting this because I am trying to find out if there is a way to determine whether something was recorded on an emulator or not.
With a video recording, is there a sure-fire way to know something was recorded using an emulator? There is a specific video I am looking at and cannot tell, and would like to know if anyone has very technical knowledge about emulation recordings, etc for this and future reference.
http://www.twingalaxies.com/showthread.php/153495-Nintendo-Entertainment-System-Top-Gun-NTSC-Points-1-083-200-Kyle-Nelson/page1
So here's a run which I think was performed on anNES emulator, but cannot say for sure with certainty. Help would be appreciated.
Super Mario Bros. console speedrunner
- Andrew Gardikis
(Note: I have not viewed the page or video in question)
It's hard to tell. Between lossy video codecs, emulators with output filters that simulate TV effects, not to mention TAS played back on a console it's hard to be sure.
Here's an idea I sorta made up just now. There's an arcade game I play where the real hardware runs too many frames per second, at over 61. When the NTSC signal is recorded on most capture hardware it outputs at 59.94 or 29.97fps and frames get dropped. This was easily noticed because the game has a built-in timer with 0.01s accuracy. The NES runs at ~60.1 fps, so maybe the framerate of the provided video can be useful? If it's not a recording standard, or if there's no dropped frames to account for the framerate variance, you may have a smoking gun.
Of course, this is highly dependent on the game not lagging, on the game being smooth enough that these can be measured in the first place, etc. Whether or not it helps, good luck.
Here's an idea I sorta made up just now. There's an arcade game I play where the real hardware runs too many frames per second, at over 61. When the NTSC signal is recorded on most capture hardware it outputs at 59.94 or 29.97fps and frames get dropped. This was easily noticed because the game has a built-in timer with 0.01s accuracy. The NES runs at ~60.1 fps, so maybe the framerate of the provided video can be useful? If it's not a recording standard, or if there's no dropped frames to account for the framerate variance, you may have a smoking gun.
I worry that this method can lead to false positives if a particular china special capture card has unexpected timing parameters, or if the user inadvertently processes the video in a weird way through Vegas or whatever. On the other hand, a skilled forger would easily know what timings are to be expected, and could carefully post-process the video to make it work.
You can find smoking guns sometimes; the best ones are emulation defects not present on real hardware. But there's no way to give the "VERIFIED NO CHEATING" guarantees that some sites claim.
More and more I feel like I'm finding it hard to trust any above average gaming performance. Maybe I'm just a grump now, but many ridiculous speedruns (and other) come along often that I'm just not sure I believe. I may believe they are humanly possible, but I feel I'm questioning runs more.
If I had to guess, I'd say that there are probably handful of TASes being accepted to be RTAs, and it's bothersome.
I was hoping maybe there was some knowledge out there that I may not be aware of that might make it easier to identify emulation. Does anyone have any useful information regarding resolutions? Frame rates and video resolutions seem to be the most identifying characteristics here.
Super Mario Bros. console speedrunner
- Andrew Gardikis
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I'd say that perfectly authentic ntsc artifacts aren't yet emulated. The most important thing would be color borders - moire on those is changing its phase during every 3 frames. 1 pixel wide vertical lines look distorted, vertical borders between solid colors look like a saw (that also shifts for every 3 frames). Also, there's a rainbow effect where on every luma (brightness) level change, there appears a tiny artifact of a semi-random color, and they also change their phase for every 3 frames. Finally, there are different artifacts of a notch filter, sometimes you can see a bit of moire even on solid colors, then, it might differ in how far from the color borders moire is clearly visible.
Just record some footage from console, then launch that game in an emulator and try checking out various ntsc filters. If you record and compare, you'll see the difference.
PS: I can't download the vid to look closely.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I'd say that perfectly authentic ntsc artifacts aren't yet emulated. The most important thing would be color borders - moire on those is changing its phase during every 3 frames.
I don't know, this comes pretty close:
From doing the entire rendering through an NTSC modem (composite video encoder+decoder) without any shortcuts. This means the whole colorburst + sync signal ensemble before it even gets to generating colors.
This emulator does not support TASes yet though, and being a proof-of-concept product (of writing an emulator in QuickBASIC), it probably never will.
Notice also the two background-color scanlines in the bottom. This matches what you see on a real console. https://www.youtube.com/watch?v=iCILuq9IzP0&t=3m It surprised even me when I made this emulator (based on meticulous study of signals generated by a transistor-level simulation of the PPU). The little streak in the first scanline was probably an emulator bug at the time I took the screenshot.
The composite decoder even spontaneously generates chroma dots (like seen in that SGDQ video) if you tune it badly, although there seems to be an unintentional noticeable pattern to them in this screenshot, probably attributable to floating point approximation issues.
More and more I feel like I'm finding it hard to trust any above average gaming performance. Maybe I'm just a grump now, but many ridiculous speedruns (and other) come along often that I'm just not sure I believe. I may believe they are humanly possible, but I feel I'm questioning runs more.
That's why live streaming speedrun attempts is important and must be encouraged. Luckily in today's world this is easy to do.
More and more I feel like I'm finding it hard to trust any above average gaming performance. Maybe I'm just a grump now, but many ridiculous speedruns (and other) come along often that I'm just not sure I believe. I may believe they are humanly possible, but I feel I'm questioning runs more.
That's why live streaming speedrun attempts is important and must be encouraged. Luckily in today's world this is easy to do.
Even this isnt foolproof though, especially when people only stream gameplay. I guess I am just super skeptical these days, and sick of cheaters...well, moreso I want accurate competition.
Super Mario Bros. console speedrunner
- Andrew Gardikis
Andrew wants his Super Mario Bros. record back.
I'm just joking. I don't have anything to contribute to this thread except to say that I agree that there's likely some funny business in the RTA community. Best of luck to you.
Edit: I think it's likely that a scandal will eventually rock the RTA community. Someone will submit an emulated run, then reveal it to be faked (or it will be discovered, though I think that's far less likely). People will argue about it for a few weeks or months and then come up with a two tiered system. They'll still accept runs from talented players who are known to be good at the game in question but there will also be something like a "directly verified" tier that includes only runs that were completed in front of judges and on known hardware. That could be frustrating because that means runs can only be completed at events like AGDQ or perhaps at special stations around the country.
I kind of stopped following SpeedDemosArchive, so let me know if anything like that has already been discussed.
From doing the entire rendering through an NTSC modem (composite video encoder+decoder) without any shortcuts. This means the whole colorburst + sync signal ensemble before it even gets to generating colors.
This emulator does not support TASes yet though, and being a proof-of-concept product (of writing an emulator in QuickBASIC), it probably never will.
Notice also the two background-color scanlines in the bottom. This matches what you see on a real console. https://www.youtube.com/watch?v=iCILuq9IzP0&t=3m It surprised even me when I made this emulator (based on meticulous study of signals generated by a transistor-level simulation of the PPU). The little streak in the first scanline was probably an emulator bug at the time I took the screenshot.
The composite decoder even spontaneously generates chroma dots (like seen in that SGDQ video) if you tune it badly, although there seems to be an unintentional noticeable pattern to them in this screenshot, probably attributable to floating point approximation issues.
