WAV and AIFF header metadata explained
Container headers describe fields; they do not prove audible content, quality, or fitness.
WAV observations
A supported RIFF/WAVE header can expose declared encoding, channels, sample rate, bit depth, byte rate, data size, and an estimated duration. Truncated or inconsistent chunks are rejected.
AIFF and AIFC observations
A FORM/AIFF or AIFC common chunk can expose channel count, frame count, bit depth, extended sample rate, and a compression label where present.
What remains unknown
The product does not decode samples, detect silence, clipping, noise, loudness, intelligibility, synchronization, or content identity. Header declarations may also be inaccurate.
Worked example
The sample preflight observations declare forty-eight kilohertz, twenty-four bit, one channel, PCM integer, with a byte size and an estimated duration for each file. One of them, the observation attached to cue twelve, declares an AIFF container and AIFF PCM encoding while the expected filename still ends in wav. The station reports that as a container difference rather than guessing which one is right.
That is the honest shape of header reading. It told you the two declarations disagree. It did not tell you whether the file is broken, whether the extension is wrong, or whether the recipient will care.
Method
A supported RIFF/WAVE header can expose declared encoding, channel count, sample rate, bit depth, byte rate, data size and an estimated duration. A FORM/AIFF or AIFC common chunk can expose channel count, frame count, bit depth, an extended sample rate and a compression label where one is present. Truncated or internally inconsistent chunks are rejected rather than half-read.
Only a bounded slice from the front of each file is read. The audio data itself is never loaded, decoded or stored.
What this does not do
- No sample decoding, so no silence, clipping, noise, loudness, intelligibility or synchronization detection.
- No content identity: the header cannot tell you which cue is inside the file.
- Header declarations are written by whatever produced the file and can simply be wrong.
Do this in the app
Treat a header difference as a question for your audio software.
- Open station 07 Preflight and read the declared fields for the file in question.
- Open that file in your own audio tool and confirm what it actually contains.
- Record the resolution in the session rather than in the finding list alone.
Open the local workspace at station 07 Preflight