Differentiate "too short" errors when harvesting

[atruskie]

There's currently an issue with the Frontier Labs BAR recorders that occasionally causes corrupt WAV files to be produced.

These files aren't detectable by normal means - they are full-size and have a "valid" header. Such files appear to have two things wrong with them:

• The Subchunk2Size field (offset at byte 40) in the WAV header is set to
  0x0000002c (44 decimal) when it should be much much larger
• And each of the files seems to be only partially written - after some
  point only empty bytes (NULs / zeroes) are present in the file

The likely cause is a sensor running out of battery life and shutting down. Apparently, the files are pre-allocated (hence the empty bytes at the end) and the SubChunk2Size field is written only at the end of the writing process.

The result of the malformed header means that SoX reports absolutely absurd
sample rates for recordings (e.g. 5.4 Terasamples per second or
34.4 Terasamples per second) and since it calculates duration from the number of samples / sample rate it fails our _too short _ validation check.

Fix

And a special validation check and error message for this case, so that when harvesting fails, we can reliably understand what the true problem is.