.WAV File Format – Metadata chunks

Common chunks

The chunks with a page of their own:

The others are described below. Among the files examined for this site, the most common optional chunks were bext, iXML, FLLR, LIST, fact, smpl and cue .

Filler: JUNK, junk, PAD and FLLR

These chunks hold nothing. In the words of the 1991 specification, a JUNK chunk “contains no relevant data; it is a space filler of arbitrary size”. Writers use filler to reserve room for metadata written later, to move the samples to an aligned offset, or to leave space for a 64-bit size chunk: a recorder that writes a 28-byte JUNK chunk first can turn the file into RF64 if it passes 4 GB. Apple’s own system sounds have such a 28-byte JUNK chunk first.

FLLR is written by Apple software, often with a filr chunk beside it, whose purpose is not documented. PAD and lower-case junk are also met. libsndfile skips them all, and so do other readers.

iXML

An iXML chunk holds production metadata as XML, written by field recorders and location sound software: scene, take, track names, timecode and notes. Its layout is set by the iXML specification. The explorer shows the XML as text.

axml

An axml chunk holds XML metadata, defined for Broadcast Wave files in EBU Tech 3285 supplement 5. It is used to carry Audio Definition Model (ADM) metadata, which describes what each track is and where its sound belongs, together with a chna chunk. The explorer shows it as text.

XMP

A _PMX chunk holds an Adobe XMP packet, XML metadata as Adobe’s programs write it. libsndfile calls it PMX_. The explorer shows it as text.

ID3

An ID3 or id3 chunk holds an ID3v2 tag, as MP3 files carry: the letters ID3, a version, flags and a syncsafe size, then frames such as title, artist and attached pictures. Files tagged by Soundminer carry ID3v2.3 tags with pictures. The explorer lists the text frames.

An ID3v1 tag, 128 bytes starting TAG, is sometimes appended after the end of the RIFF chunk, as on an MP3 file. RIFF readers ignore it; libsndfile and the explorer recognise it.

inst

The instrument chunk gives a sampler the note and velocity range to play a sample on. It is 7 bytes, so a pad byte follows.

Where the chunk was first defined is not confirmed.

acid

Sony’s ACID loop chunk gives a loop’s tempo and length, so music software can fit it to a song. It is not published; this is the 24-byte layout libsndfile reads. FL Studio loops carry it.

PEAK

The peak chunk gives the loudest sample of each channel, so a program need not scan the file. This is the layout libsndfile reads.

libsndfile reads 4-byte positions, though its own writer writes 8-byte ones.

cart

The cart chunk is AES46 CartChunk, used by radio automation systems. It is at least 2,048 bytes and holds, in libsndfile’s order, a version, title, artist, cut ID, client ID, category, classification, out cue, start and end dates and times, producer application and version, user text, level reference, post timers, a reserved area, a URL and tag text. The field sizes are not confirmed here, so the explorer shows the chunk as bytes.

levl

The levl chunk, from EBU Tech 3285 supplement 3 (2001), is a peak envelope: a header and the peak values of blocks of samples, so an editor can draw the waveform without reading the audio. Its layout was not checked for this page, and the explorer shows it as bytes.

DISP

A DISP chunk holds something to show for the file: a Windows clipboard format number (u32: 1 for text, 8 for a bitmap), then the data in that format. It is usually traced to the 1991 RIFF specification, which was not checked for it here.

Other chunks of the 1991 specification

The plst playlist and LIST adtl labels are on the cue page, the CSET character set chunk on the LIST INFO page, and the wavl list with its slnt silence chunks on Sample data.

Unknown chunks

Any other ID is a chunk a reader does not know, and it skips it by its size. Programs add their own chunks freely. Among the files examined for this site, these were common but are documented by no source used here; who writes them is inferred from the files, not confirmed:

• ovwf, umid, minf, regn and elm1, which come together in files whose bext originator is Pro Tools;
• SMED, in files tagged by Soundminer;
• filr, alongside FLLR;
• LGWV and ResU, apparently from Logic;
• and a few others, such as CDif, DGDA and Fake.

The explorer shows the body of an unknown chunk as bytes. The 64-bit size chunk ds64 and BW64’s XML chunks bxml and sxml are unknown chunks in this format too.

Where they sit

Metadata chunks can come before or after the data chunk. Recorders often reserve room near the start with a JUNK chunk and fill it in later, while editors often write metadata after the samples so they can change it without moving the audio.