InpHisto information

OK. I originally sent this to BeeJay. He asked me for some more explanation on InpHisto, and I used an .inp he sent me as a basis for making my remarks. I think this might be useful for other Editors as well, especially future Editors.
Below is the "analinp -i -S" output from a stinger .inp BeeJay sent me. Throughout this output, I have put my own remarks. The actual output is in fixed font, so it should be easy to distinguish between remarks and output.

OK. The InpHisto part starts now. Originally, InpHisto had only one column with numbers and percentages, the other two were added later. So I'll first explain the first column. Suppose someone starts a game, and after 200 frames, presses the firebutton, holds it down for 4 frames, then releases it again. For the bit in the .inp that represents the firebutton. Unfortunately, the bit is different for every game, so the MAME source code or some experimenting has to be used to find out what exactly each bit is per game. Having said that, some educated guesses can be made, as I'll show below.
We are not really interested in someone not pressing a button for a long time, or keeping it down for a long time, so everything of length 11 and more is treated the same.
InpHisto makes a histograms of the numbers of presses and releases for each length (duration). Lengths are counted in number of frames. Note that this first column counts BOTH presses AND releases.
In our example (200 frames released, 4 frames pressed), this would mean that the bit for this button now has a count of 1 for length 11+ (the 200 frames released) and a count of 1 for length 4 (4 frames pressed). Now suppose that the player leaves the button released for 4 frames, then presses it again for 3 frames, then never touches it again until the end of the recording (say 50000 frames later). We would now have:
OK, this is not really part of the output, but just to format it, I'll use fixed font here too.

For these numbers, averages and percentages are calculated. In these calculations, lengths 11 and longer are ignored, since they will skew things. Someone could press like crazy for 1 minute, then not do anything for several minutes, then press again, etc.
So in the above example, the percentages would be:
OK, this is not really part of the output, but just to format it, I'll use fixed font here too.

Length 3 : 1 ( 33.33%)
Length 4 : 2 ( 66.67%)

And the average length would be (3*1 + 4*2) / 3 = 11/3 = 3.67.
Since this is both presses and releases, and assuming a 60 fps game, this would indicate that this person fired at an average speed of 60 / (3.67 * 2) = 8.19 "fires" per second.
If this had been a 40 fps game, the number would have been 40 / (3.67 * 2) = 5.46.
By examining a lot of .inps made on shooters, we have observed that fast pressers usually average around 4 on the firebutton on 60 fps games, indicating an average speed of 60 / (4*2) = 7.5 fires per second.
For 60 fps games, we use the rule that below 3.5 indicates either autofire or slowdown. The nice thing is that people are pretty consistent. It is very hard for someone to slow a game down to half speed and then press twice as slow to mask the slowdown. I have examined several of my own Scramble recordings. Some of those recordings were made more than a year apart. The numbers were still pretty much identical...
There are a few exceptions to this 3.5 rule, though. First of all, there is Hisa-Chan. He really is a great player, but lots of people still have doubts about his firing speed. For now, we have accepted his 3.25 and such averages, but we are waiting for a way (MAMETE, for instance) to challenge his recordings.
Another exception is games that require you to press in relative short bursts. Fast pressers can get significantly faster than 4 when they press like crazy for short periods of time (say a few seconds), then not touch the button for a while. The best examples of games like these are Track & Field and similar games.
Also, there are panic pressers. I myself am a panic presser when trying to score on Goal! Goal! Goal! or when trying to hit an opponent in fighters. Most of the time, I press leisurely, and at key moments, I press in a fast burst of only a few seconds.
Note that InpHisto shows ALL the bits that change during a game, so not just buttons, but also directions (left, right, up, down), coin inserts, player-1-start, ...
Later on, two columns were added to the InpHisto output: The first of these counts the lengths when the bit in question had the value 0, the second when the bit was 1. In most games, bits are active low, meaning that when a button is pressed, the bit is 0, but, unfortunately, this does not hold for every game or for every input (button, direction, coin, etc.). Apart from, perhaps, helping in establishing some pattern for a given player on a given game, and apart from showing, for example, that a certain player's presses are shorter, on average, than the times in between presses, there is one more use for these columns, and I'll explain that further down.
Even if the averages look acceptable, a high percentage of lengths 1 and 2 is suspicious. I'd say if 25% or more are length 1 or 2, then I get suspicious. This could either be autofire being turned on and off, or temporary slowdowns (either on purpose or because of CPU-intensive parts of the game), or (never forget this) that the game runs at less than 60 fps. Remember that a player with a 4 average on a 60 fps game, could get a 2.67 average on a 40 fps game.
Also, some games are "strange". gaplus, for instance, puts a lot of lengths 1 even in perfectly legal recordings.
A good rule of thumb, when statistics look suspicious is to compare the output to that of other people (preferably people you trust, and preferably people that are known to press fast).

4th bit. OK. I have already looked ahead; 3 more bits follow. Looks like this is a game with four directions and one fire button. Based on the numbers for "all lengths", I'd say that the above four are the four directions.

5th bit. And I'd say that this one (5) is the fire button. Not really fast. Either you are not a fast presser, or you press slightly slower on average, but with more precision. I have noticed, for instance, that several good Galaga players don't press as fast, but make every press count (high hit/miss-ratio). I, for one, am a fast presser, and that's probably why I can't score over 1M on regular Galaga. I miss too much. I might fire faster, but overall, I still have more "misses per second".

6th bit. OK. "all lengths" is 3 here. Assuming you weren't holding down any buttons when the recording started, that would mean 1 release, 1 press, 1 release for the entire game. Obviously, this bit is either the "insert coin" or the "1 player start" bit. Also, the second column shows 2, and the third shows 1. Again assuming you didn't have anything pressed when the recording started, that would mean that the second column shows the releases for this bit (and so release = 0), and the third shows the presses (and so presses = 1). Realise, though, that that only holds for this bit, not necessarily for the other input bits.

7th bit. If 6 was "insert coin", then this is "1 player start", and vice versa. Again, the bit seems to be 0 when the button is released.
Let's go back to the other bits for a moment now. Assuming no buttons/directions were held when the recording started, nor when it ended, there will always be exactly one release more than press. Under this assumption, bits 234 and 239 show the releases in the third column (and so the bit is 1 when released), while all the other bits have the releases in the second column (and so the bit is 0 when released). Again, this is assuming no buttons were pressed when the recording started and ended.