Sniffer rule for video/mp2t too simple

[dsuden]

[See comment 2 to reveal the mystery]

I had a flash video (downloaded with UberTuber) sitting on my desktop, and then deleted it, so it was no longer on the desktop. Later that day, I saved a text file from Pe to the desktop. I didn't look at it at the time, but this morning I noticed my text document had the same icon as the flash video I had trashed. I was able to use filetypes to change the document back to a text file, which allowed it to again be opened normally in Pe, and its text looked fine. But that seemed like a strange enough turn-of-events that I thought I'd better report it. Note, the trashed video file also had a completely different filename than the text file on the desktop.

[dsuden]

I just saved another text file to the desktop, and it happened again. This time I double-checked the filetype right away and it's not a flash as I thought, but an "MPEG-2 transport stream." So the deleted flash file might be a red herring. Still...how strange to have Pe saving files as video!

[humdinger]

Hold on, let me contact the spirits beyond... <insert dark atmospheric music>

I get a "G".... Does the contents of your text file start with a "G" by any chance? I bet it does. Culprit is the naive sniffer rule for video/mp2t filetypes. It just checks if the first byte is 0x47. Apparently transport streams do always beginn with 0x47, but as that's just a "G", anything starting with that qualifies.
​ReadMe.IntroductionToHaiku in the root of the repository suffers that same issue.

You can "solve" this for the time being by removing the rule in the Filetypes preferences.

Can anyone come up with a better sniffer rule? It looks like after that first sync byte, there isn't much to analyze (s. ​wikipedia), or is there?