Besides ds64, fmt and data, a BW64 file can carry
any number of optional chunks. The ones that matter most are those of the Audio Definition
Model, which BW64 was made to carry. The rest are WAV’s, read the same way. A reader that
does not know a chunk skips it by its size; a chunk whose size is
0xFFFFFFFF takes its size from the
ds64 table. Every number
in them is little-endian.
Common chunks
The chunks with a page of their own:
| Chunk | Holds | Defined by |
|---|---|---|
chna | which ADM track each channel carries | EBU Tech 3285 supplement 7; ITU-R BS.2088 |
fact | the number of sample frames, for compressed audio | the 1991 RIFF specification |
LIST INFO | text tags: title, artist, comments, date, software | the 1991 RIFF specification |
cue | markers at sample positions, with LIST adtl labels and the plst playlist | the 1991 RIFF specification |
smpl | root note, tuning and loop points for samplers | believed to be the MIDI Manufacturers Association (not confirmed) |
bext | broadcast details: description, originator, time reference, loudness | EBU Tech 3285, the Broadcast Wave Format |
axml
An axml chunk holds XML metadata. In BW64 it carries the Audio Definition
Model (ADM, ITU-R BS.2076): a description of the programme, its content, and what
each track is, such as a channel of a loudspeaker layout or a moving object with its
position. It is the heart of a BW64 file. The
chna chunk
ties the tracks of the audio to the IDs this XML uses. The same chunk was defined for
Broadcast Wave files in EBU Tech 3285 supplement 5. The explorer shows the XML as
text.
bxml
A bxml chunk holds the XML metadata in compressed form. This account comes from Wikipedia and from summaries of
the Recommendation; the chunk’s layout is not confirmed here, and the explorer shows it
as bytes.
sxml
An sxml chunk holds XML metadata split into parts that follow the audio in
time. As
with bxml, this comes from Wikipedia and summaries of the Recommendation;
the layout is not confirmed here, and the explorer shows the chunk as bytes.
Wikipedia also says BW64 “replaces binary format metadata chunks”, such as
bext and ubxt, with XML. That could not be checked against the
Recommendation itself.
Filler: JUNK, junk, PAD and FLLR
These chunks hold nothing. In the words of the 1991 RIFF 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, or to move the
samples to an aligned offset. PAD , lower-case junk and
Apple’s FLLR are also met in WAV files. 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.
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. The explorer lists the text frames.
An ID3v1 tag, 128 bytes starting TAG, is sometimes appended after the end
of a WAV file’s outer chunk, as on an MP3 file. Readers ignore it; the explorer
recognises 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.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 1 | u8 | bUnshiftedNote | the MIDI note the sample plays unchanged at; 60 is middle C |
| 1 | 1 | i8 | chFineTune | fine tuning in cents, −50 to 50 |
| 2 | 1 | i8 | chGain | the suggested gain in decibels |
| 3 | 1 | u8 | bLowNote | the lowest note to play it on |
| 4 | 1 | u8 | bHighNote | the highest note |
| 5 | 1 | u8 | bLowVelocity | the lowest velocity, 1 to 127 |
| 6 | 1 | u8 | bHighVelocity | the highest velocity |
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.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 4 | u32 | flags | 0x01 one-shot rather than a loop, 0x02 the root note is set, 0x04 stretch is on |
| 4 | 2 | u16 | root note | the MIDI note of the loop, when flag 0x02 is set |
| 6 | 2 | u16 | unknown | not documented |
| 8 | 4 | f32 | unknown | not documented |
| 12 | 4 | u32 | beats | the length of the loop in beats |
| 16 | 2 | u16 | meter denominator | libsndfile reads the denominator before the numerator, and doubts the order (“are we sure about the order??”) |
| 18 | 2 | u16 | meter numerator | the other half of the time signature |
| 20 | 4 | f32 | tempo | beats a minute |
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.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 4 | u32 | dwVersion | 1 |
| 4 | 4 | u32 | dwTimeStamp | when the peaks were measured; libsndfile writes seconds since 1970 |
| 8 | 8 each | record | peaks | for each channel: the value (f32), the highest absolute sample, then its frame (u32) |
libsndfile reads 4-byte positions, though its own writer writes 8-byte ones. In a file longer than 232 frames a 4-byte position cannot reach the end.
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; libbw64
does the same. Programs add their own chunks freely. The explorer shows the body of an
unknown chunk as bytes. RF64’s marker chunk r64m, from EBU Tech 3306
version 1.1, is one of them here.
Where they sit
EBU Tech 3285 supplement 7 places chna before the data and the
axml chunk. Other metadata chunks can come before or after the data
chunk.
0BW64 WAVE12 bytes12ds64 the 64-bit sizes36 bytes or more48fmt the format24 bytes or more…chna the track allocationvaries…data the samplesvaries…axml the ADM metadatavaries