WAV and RIFF
WAV usually stores audio in a RIFF WAVE structure containing a format description, sample data, and optional metadata chunks.
A WAV reader needs to find both how the audio is represented and where its data starts. The familiar RIFF/WAVE structure gives it separately identified chunks for those jobs.
RIFF begins with an overall chunk size and a file type, here WAVE. Child chunks have their own four-character identifiers, sizes, and contents. The reader advances using those sizes and required alignment rather than assuming every WAV has a fixed-length header.
| Chunk or description | What it supplies |
|---|---|
| fmt | Encoding, channel count, sample rate, and sample/block properties |
| data | Encoded or uncompressed audio bytes |
| Additional chunks | Metadata, markers, or other information |
| WAVEFORMATEXTENSIBLE, where used | A richer format description, including speaker roles and valid sample precision |
Byte layout of 48 kHz stereo PCM
Suppose fmt describes two-channel, 48 kHz, signed 16-bit linear PCM. Each channel sample occupies two bytes, so one sample frame—one value for each channel—occupies four bytes. The stored sequence is commonly interleaved: left, right, then left, right for the next sample instant.
48,000 sample frames/s × 2 channels × 2 bytes = 192,000 bytes/s
Once the reader locates data, advancing 192,000 bytes covers one second of this particular PCM arrangement. The format fields make that inference possible. A compressed WAV uses its own block and decoding rules instead; .wav is not synonymous with these PCM parameters.
The bytes occupied by a sample and its useful precision
WAVEFORMATEXTENSIBLE can distinguish the container size for one sample value from the number of valid bits. For example, 20 meaningful bits can occupy a 24-bit, three-byte storage unit. Here “sample container” means the space occupied by one value, not a media-file container such as WAV.
For multichannel sound, a speaker-position mask describes which roles the channels occupy. Six values per sample frame alone do not establish whether they represent the expected speaker order. The encoding, precision, and channel roles together tell the audio pipeline how to interpret them.
Why data does not always start at byte 44
A minimal PCM WAV layout is often associated with a 44-byte header. Extra metadata, an extended format description, or other chunks can move the beginning of data. A tool extracting samples by a hard-coded offset can consequently treat header bytes as sound or omit the first samples.
The same principle applies to size limits. Classic RIFF chunk lengths are 32-bit, giving a practical limit around 4 GiB. RF64 adds conventions for larger files; a reader needs those conventions rather than just a familiar extension. CAF uses another large-file-oriented design.
For a WAV imported into Emby, the useful source description includes the encoding, actual sample format, channel roles, rate, and complete duration. These fields explain the sound's stored organization and the amount of data the chosen playback route will need.