WAV Chunk Reference

I put together this page in the hopes that it will serve as a reference for anyone wanting information on what the various chunks of data within a WAV file contain and what standards may define them.

A WAV file not only contains audio samples, but also can hold various types of non-audio metadata such as time code, cue markers, loudness info, sampler loops, recording description data, or metadata specific to a particular program/app. Most programs only show a small portion of what’s inside a WAV. As for the info they don’t manage, they at best ignore…and at worst, may entirely remove it.

Below you will learn how to identify every chunk written within a WAV or BWF (Broadcast Wave file). You’ll find an explanation of what info each chunk carries and what specification or source defines it, if any. Lastly, each section points out implementation details and any common software mistakes.

Who might find this reference useful? Developers writing parsers, archivists, audio engineers, those investigating metadata survival/history, or just someone technically curious.

Entries are grouped according to their function or purpose. They all receive one of four label types (see below) that explain who or what defines their specifications. This could be a formal standard written by a governing body on down to the reverse-engineering of a private spec by a group of enthusiasts.

So what makes a WAV file a WAV file? In short, a WAV file is an audio container format based on Microsoft and IBM’s RIFF specification. It stores audio data-most commonly uncompressed PCM-along with structural information in a series of data blocks called chunks. The two essential chunks are fmt for the audio format and data for the audio samples. Everything else is optional, like the metadata.

How standardization is labeled

Below is a chart showing the four standardization labels. Each chunk listed in the various tables beneath it will have one of these four labels under the “STANDARDIZATION” heading.

• Formal standardA formal standards organization publishes an authoritative document that defines the details of these chunks. Examples shown on this page include Microsoft/IBM, EBU, ITU, AES, and CIPA.
• Published specThese chunks have no formal standardization. However, they are defined by a publicly available specification from either a vendor or community group. Examples are Gallery's iXML specification or Adobe's XMP file-storage specification.
• ConventionNo specification defines the RIFF chunk itself, yet it has established support from multiple independent writers. Sometimes the data inside has a formal specification, but its WAV wrapping does not.
• Vendor-specificThe format belongs to a single company or developer and was never standardized or published for general use. Some of these have been reverse-engineered by the community, but that doesn't change who controls the format. This reference shows the chunk's presence and general purpose only.

Reading the four-character codes

WAV files use the four-character code, or FourCC, to identify audio format and data chunks, and any other chunks specific to the audio format. Spaces are allowed as padding for a FourCC with less than four characters, so a three letter FourCC would be valid, as in the case of fmt, for example. Notice the space trailing the fmt. The padding must be on the right with blank characters. And don’t overlook letter case. FourCC values are case-sensitive. So axml and AXML are not the same. RIFF conventionally uses uppercase identifiers for registered chunk types that can apply across RIFF formats, including RIFF, LIST, and JUNK, while lowercase identifiers are generally used for form-specific chunks, such as WAVE’s fmt and data. Later extensions do not always follow this convention. Lastly, when it comes to LIST / INFO and LIST / adtl, LIST is the chunk ID while INFO & adtl are list types stored at the beginning of the LIST chunk’s data.

Core RIFF structure

This section covers the structures that make up a basic WAV file: the container/header, the audio format description, the audio sample data, auxiliary format information, and large-file extensions for files larger than four gigabytes.

Broadcast Wave and EBU metadata

Broadcast Wave (BWF) is an extension of the WAV format. It was developed by the European Broadcasting Union (EBU) for professional audio production and broadcasting. The bext chunk sits at the heart of the standard. The EBU also defines a numbered series of supplement chunks that add other types of metadata. The AES defines a separate chunk for radio automation.

Object audio and the Audio Definition Model

The Audio Definition Model (ADM) describes object-based and immersive audio. Its descriptive metadata is XML, which is usually carried in the axml chunk listed above. A separate chunk maps the file’s audio tracks to the ADM description.

Cue points, regions, and sampler data

This family marks positions and ranges in the audio data, names them, and describes how a sampler should play the file. Most of it is part of the original 1991 baseline; the sampler and instrument chunks were added in Microsoft's 1994 Multimedia Standards Update.

Tagged text and consumer metadata

The oldest and most common metadata in WAV files: simple tagged text, plus the Exif-audio list used by some cameras and recorders.

Production metadata: iXML

iXML is an open standard for embedding location recording metadata that is published by Gallery (UK). It’s also the home for several vendor-defined extensions, such as the Sony ASWG iXML Extension and Steinberg’s fields. These two both live inside the iXML payload as nested elements instead of as separate chunks.

Embedded standards: XMP and ID3

Because a WAV file is built on RIFF’s flexible container structure, two metadata standards from outside the WAV world are commonly carried as chunks: Adobe’s XMP and the ID3 tag familiar from MP3.

Padding and miscellaneous chunks

This section is a bit of a catch-all. Three of the chunks (JUNK, PAD, FLLR) are used as filler or reserved space within the WAV file. The other four (CSET, DISP, MD5, PEAK) serve unrelated purposes that don’t fit neatly elsewhere.

Vendor and proprietary chunks

A WAV file can also contain chunks written by some of the various editors, samplers, recorders, and other audio software. They’re not standardized chunks, but they belong to a particular company, developer, or product. What is known about them varies quite a bit. Some have been reverse-engineered and documented, while others we still know very little about. Regardless of how well or poorly they’re understood, the goal here is to document that they exist. If known, the software or hardware they are associated with and what they appear to contain will also be shown.

Related formats that are not WAV chunks

You should be aware that there are a few four-character codes that are NOT WAV chunks. They are different file formats altogether. For example, FORM is found at the beginning of an AIFF or AIFF-C file. fLaC is another one. It identifies a FLAC file. And OggS marks the beginning of an Ogg stream. Then there’s Sony’s Wave64. It’s related to WAV, but IS its own container. Instead of the RIFF/WAV four-character codes, it uses 128-bit GUIDs to identify its structures. This info is included here mainly to avoid confusion if you happen to come across them while inspecting audio files. Everything else on this page concerns chunks you can actually find inside a RIFF WAV file.

Specifications referenced

• RIFF and WAVE (baseline): Microsoft and IBM, Multimedia Programming Interface and Data Specifications 1.0 (1991)
• RIFF additional chunks: Microsoft Multimedia Standards Update, New Multimedia Data Types and Data Techniques, Revision 3.0 (1994), which defines PAD, DISP, and the sampler and instrument chunks; JUNK and the cue, playlist, and associated-data family are part of the 1991 baseline
• LIST / INFO: Microsoft RIFF Multimedia File Reference
• Broadcast Wave (bext) and supplements: EBU Tech 3285, Version 2 (2011), with supplements 1 (mext), 2 (qlty), 3 (levl), 4 (link), 5 (axml), and 6 (dbmd); EBU R 85-2004 for production usage
• RF64 and MBWF: EBU Tech 3306
• bext and mext, ITU adoption: ITU-R BS.1352 (Annex 1 for bext and ubxt)
• BW64 chunks: ITU-R BS.2088 (ds64, axml, bxml, sxml, chna)
• Audio Definition Model: ITU-R BS.2076 (the model) and ITU-R BS.2125 (Serial ADM)
• Radio cart: AES46-2002
• Exif-audio list: CIPA DC-008-2012 (Exif 2.3), section 5.6.3
• ID3 payload: ID3v2.3 and ID3v2.4 (id3.org)
• XMP: Adobe XMP Specification Part 1 (ISO 16684-1) for the payload, and Part 3, Storage in Files (January 2020), for the WAV chunk wrapping
• iXML: Gallery iXML Specification, Revision 3.01 (Gallery UK, October 2021)
• ASWG extension: Sony ASWG iXML Extension v1.1 (github.com/Sony-ASWG/iXML-Extension)

About this reference

This reference is compiled and maintained by the developer behind WAVScribe, a WAV metadata editor, and the free, read-only WAVScribe Viewer. If you spot an error or a chunk that should be added, corrections are welcome through the contact page.