This code implements a way of detecting recordings that have been
damaged by their broadcasters, by doing signal processing on their
audio.  It monitors all new files with certain extensions created in
any directory you aim it at, and can issue realtime alerts about
anything it finds.  It uses mplayer to convert whatever the original
audio track was in each file to a canonical representation it can
handle, so it requires that mplayer be installed somewhere.

See the file INSTALLATION for what to do with all this.

So what does this detect?  EAS alerts and silences.

Emergency Alert System notifications are those things with the
tonebursts and a placard of text (usually) that people in the US often
see late at night.  Comcast, my provider, emits them on -every-
channel simultaneously, more frequently than once a week, as part of
so-called "required weekly tests", and they destroy 1-2m of the
recording.  There are several random times between around midnight and
3am that they tend to do this, and there's little regularity---this
week, they were only 72 hours apart!  And they managed to step on the
-same piece- of the same movie I was trying to record, and which only
aired twice---even though the movie actually aired at different times
of day.  Usually, though, it's possible to rerecord something which
airs more than once and miss the alert the second time around---but
only if you know about the alert promptly, so you can catch a repeat
that might be only a couple hours later, and not next week when you
finally sit down to watch and find something crucial is missing and
there's no repeat to be found.  [EAS tonebursts are also used for
weather alerts, such as nearby tornados, so they're not -just- useless
tests for a nuclear attack that has never happened.  But you still
probably don't want to have a weather alert stuck in your recording
if you can get one that doesn't have it.]

Silences generally indicate problems at the broadcaster---my local PBS
affiliates (all three of them) often have issues where the feed will
just freeze for a few minutes or an entire hour, or they'll put up a
little screensaver-esque bouncing blue rectangle saying "No Signal"
---obviously generated automatically from something in the signal
chain.  Less frequently, I've also seen issues where other channels
will freeze during the program until the end of the showing, or will
freeze during a commercial break and then return to the program a few
minutes later, in-progress.  I've also seen just total blackness for
an entire showing of something---with perfect lead-in and lead-out
---or total pixellation and stuttering from the broadcaster---and I've
seen this sort of thing even when I had an analog cable feed directly
into a television, so I know it's their problem.  Once again, if
there's a repeat available, I can reschedule, but only if I know
promptly.  The scripts that run the silence detector currently use two
different thresholds for how long is too long, since some movies may
have silent pieces (during credits, for example, or even during normal
action) that can be 3-4 minutes long, but you'll never, ever find more
than a few seconds of deliberate dead air on the Discovery Channel,
etc, but do occasionally find 3-minute-long frozen segments.

Detecting silence obviously might also help people whose cable boxes
or DISH receivers claim to be tuned to a signal, but are actually in
"Press Select To Continue", turned off, or other useless modes.

Both of these detectors together take about 1% or less of a slow
CPU, per stream, to run in real time.  They can be run on any file,
generated by MythTV or not, which mplayer can play.  You can get
the notification seconds after the problem---long before the current
showing even ends---or you can scan the entire file looking for any
other problems it may have.

The obvious next step is to have Myth reschedule automatically in such
cases.  That might be somewhat tricky, but later Myth versions might
make this feasible.
