As suggested by Greg Marra, this thread is to discuss a system to automatically parse matches.
I had initially suggested using the match audio to detect the beginning and end of the matches. The reason for this is that the audio is always available, and the audio markers are well-known. Also, the audio has a much low data rate than the video, which theoretically means that it requires less processing. I happen to be taking a class in digital signal processing, so I have a couple ideas of how to actually implement this.
On the other hand, Greg has mentioned a LabVIEW VI in the works which is able to work based on the match progress bar on the bottom of the screen. There is less noise in the video, so it should be somewhat more reliable than audio. However, I have seen instances where the progress bar wasn’t shown for the first few seconds of the match. Presumably, a video-based method could also parse the text on the bar and automatically grab the regional code and match number.
Obviously, if we could get some kind of feed from the FMS, that would be even better.
Video is nice if you always take it straight from the webcast, but some matches don’t have the score at the bottom (galileo video had this problem) and others are filmed from afar, so there’s merit to implementing both tools for auto-parsing.
Now the real cool thing to do would be to implement both, and use them simultaneously to parse video and line up audio-video mismatches.
The code is a simple script that reads an audio marker and can generate a noisy audio clip with the audio embedded. From there, it uses cross-correlation to locate the marker within the clip. Test data includes a couple clips from a real match, and it appears to work correctly on this data.
It’s written in MATLAB, but should run with Octave. Anyone here is welcome to use and extend it. Let me know if you have questions or suggestions!
I am reasonably certain that the FIRST website currently publishes the actual match start times with minute precision. Assuming timestamped video (if it isn’t timestamped, you would need to manually align the start time to a known reference), you can use these start times to split the video (worst case :59 of dead air before the match starts). If there is clock misalignment between the published start time and the video time sync, you would very quickly (once per event) calculate the offset.
You could also use this system in conjunction with an audio/visual classifier so that your algorithm knows which sounds map to which match.
