An associated data list in the wave file format is a LIST chunk of type "adtl". It defines text labels and names for cue points. An associated data list typically uses label sub-chunks, note sub-chunks, and labeled text sub-chunks.
An associated data list chunk has the following format.
| Byte sequence description | Length in bytes | Starts with byte in the chunk | Value |
| chunk ID | 4 | 0x00 | The ASCII character string "LIST" |
| size | 4 | 0x04 | The size of the sub-chunk less 8 (less the "chunk ID" and the "size") (an unsigned integer) |
| list type ID | 4 | 0x08 | The ASCII character string "adtl" |
| data | various | 0x0C | The label, note, and text sub-chunks described below |
Label and note sub-chunks
A label sub-chunk and a note sub-chunk have the same structure.
| Byte sequence description | Length in bytes | Starts with byte in the sub-chunk | Value |
| sub-chunk ID | 4 | 0x00 | The ASCII character string "labl" or "note" |
| size | 4 | 0x04 | The size of the chunk less 8 (less the "sub-chunk ID" and the "size") |
| cue point ID | 4 | 0x08 | The ID of the relevant cue point (see Cue chunk (of a Wave file)) |
| data | various | 0x0C | Some ASCII text |
The ASCII text is null terminated and must be padded, if not word aligned.
Labeled text sub-chunk
The labeled text sub-chunk associates some portion of the audio data with text and serves as a marker. This sub-chunk has the following format.
| Byte sequence description | Length in bytes | Starts at byte in the sub-chunk | Value |
| sub-chunk ID | 4 | 0x00 | The ASCII character string "ltxt" |
| size | 4 | 0x04 | The size of the sub-chunk less 8 (less the "sub-chunk ID" and the "size") |
| cue point ID | 4 | 0x08 | The ID of the relevant cue point |
| sample length | 4 | 0x0C | The number of samples in the segment of audio data described by this chunk |
| purpose ID | 4 | 0x10 | The purpose of the text. Common IDs are "scrp" for script and "capt" for closed captioning |
| country | 2 | 0x14 | The country of the text |
| language | 2 | 0x16 | The language of the text |
| dialect | 2 | 0x18 | The dialect of the text |
| code page | 2 | 0x1A | The code page for the text |
| data | various | 0x1C | Some ASCII text |
The labeled text sub-chunk is always a part of an associated data list chunk.
See also:
Wave file format, List chunk (of a RIFF file)
Comments
Older comments
admin: First posted on 2015 02 08
anonymous, 2015 02 08: The "labl" or "note" tables (above) seem to replicate but the first row "Byte sequence description" is sub-chunk ID vs chunk-ID... My assumption is that the tables are documenting the same sub-chunk - and as a result the use of "chunk-ID" in the second table is incorrect --- If my assumption is correct I would remove the redundant table because it suggests that there are two chunk/sub-chunks that have the same "Byte sequence description"
Richard Lee, 2015 05 10: As per the above comment - the second listl/note table is incorrect - the ChunkId should read "ltxt” (labelled text) not "note"/"labl".
mic, 2016 08 11: This is correct. It should be "ltxt". It is now fixed.
How about multiple list type ids?
If the wav file has more than one list type ids, what the list chunk structure will be looks like? More list chunks or more sub chunk following the chunk ending?
Structure A:
LIST | SIZE | LIST TYPE ID1 | DATA | LIST Type ID2 | DATA
Structure B:
LIST | SIZE | LIST Type ID1 | DATA | LIST | SIZE | LIST TYPE ID2 | DATA
Which one it will be?
Thanks
Both
Both. You can have multiple LIST chunks and they can grow with multiple data as needed. LIST is a RIFF construct and so other RIFF type files make heavy use of lists (e.g., DLS, SF2), where you can have multiple lists, including of the same type, as long as they are placed in the appropriate place.
P.S. Wave files specifically
P.S. Wave files specifically can have more than one LIST chunk. For example, one could be this one and the other one could be an INFO one. They would be independent of each other and not nested in any way, similarly to the way you listed your lists above. But the RIFF format is designed to be flexible. You can literally put chunks anywhere, including within other chunks. The caveat is that software might just ignore your chunks.
Add new comment