Subchunk2Size header values
|Problem ID||Manufacturer||Affected Firmware||Fixed in firmware||Affected Hardware||Status|
|FL005||Frontier Labs||2.2; 2.99||3.00||BAR||Minor problem|
It appears that Frontier Labs writes an incorrect value for the
size field (known as
cksize). The value should be the size
of the data block, in bytes, and should be the equivalent of
== NumSamples * NumChannels * BitsPerSample/8. Essentially it is the size of
the PCM samples, which is the size of the file not including the WAV header.
Frontier Labs erroneously writes the total size of the file into the header
instead. On average this means the data size is off by
44 bytes (the standard
sized wav header) which is about 3 16-bit samples’ worth.
Interestingly this problem was discovered while trying to create a validation check for the corrupt files (see this file ) that BARs sometimes produce.
Update: It has been discovered that the “RIFF” chunk size is also off by
The value of the “RIFF” chunk size should be the remaining size of the file after
itself (or the total size of the file minus the first 8 bytes).
Minor problem - this problem no longer occurs in firmwares greater than
Any files produced with older firmwares still have issues though.
For files with simple wav headers 3 samples worth of error is about 0.136 seconds of error.
Status with vendor #
Vendor has patched the problem in firmware
3.00. Get updated firmware from Frontier Labs
Effects of the problem on common tools #
Emu can detect and repair affected files: https://github.com/QutEcoacoustics/emu/blob/master/docs/fixes.md
Acoustics Workbench (Ecosounds, A2O) #
- While technically incorrect, all the values are small enough that they are omitted or ignored in our higher level code.
- No effect, file opens normally.
- No effect, file opens normally