Besides fmt and data, a RIFX WAVE file can carry optional
chunks. They describe the audio without changing how it plays, and a reader that does not
know one simply skips it by its size. Each has the layout it has in an ordinary WAV file,
with every multi-byte number big-endian; text, chunk IDs and other four-character codes
are unchanged. The explorer reads them this way. Since RIFX files are rare, most of these
chunks are known only from RIFF files, and how a given program writes them in a RIFX file
is not recorded.
Common chunks
The chunks with a page of their own:
| Chunk | Holds | Defined by |
|---|---|---|
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 |
The others are described below.
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 or to move the
samples to an aligned offset. FLLR, PAD and lower-case
junk 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.
axml
An axml chunk holds XML metadata, defined for Broadcast Wave files in EBU
Tech 3285 supplement 5, where it carries Audio Definition Model metadata. The explorer
shows it as text. The chna chunk that goes with it in other WAV formats is
not read in a RIFX file; see unknown
chunks.
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 tag has its own byte rules and is the
same in either byte order; only the chunk’s size is big-endian. The explorer lists the
text frames.
An ID3v1 tag, 128 bytes starting TAG, is sometimes appended after the end
of the outer chunk. 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 single bytes, so byte order does not affect it, and 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, with each field big-endian as the explorer reads it in a RIFX file.
| 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, big-endian in a RIFX file.
| 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.
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 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. The explorer shows the body of an unknown chunk as bytes.
Four chunks that other WAV formats define are unknown chunks in this format: the
Audio Definition Model’s chna, the 64-bit size chunk ds64, and
BW64’s XML chunks bxml and sxml. They belong with
little-endian files, and no one is known to write them in a big-endian one.