Lossless WAV Metadata Guide: Dual RIFF & ID3 Chunk Architecture

The Fatal Flaw of Standard Audio Tagging

Every independent composer understands the routine: you finish a mix, bounce an MP3, use an MP3 tagging application to insert artist name, title, and email, and hit save. When you upload that MP3 to DISCO.ac, your tags appear. You assume the job is done.

Then a music supervisor requests the broadcast-quality 24-bit / 48 kHz WAV. You bounce the WAV from Pro Tools, Logic Pro, or Ableton, attach it to an email or cloud link, and send it.

Here is what happens on the recipient's end: The music supervisor downloads the file and drags it into their DAW or NLE (Avid Media Composer, Adobe Premiere Pro, or Apple Final Cut Pro). In 95% of cases, every single piece of metadata vanishes. The filename is all that remains. If the editor renames the file to Chase_Scene_Alt_Mix.wav on their timeline, your track becomes an orphaned asset. Even if the director falls in love with the cue, nobody knows who wrote it, who owns the master, or who to write the check to.

The Anatomy of a Broadcast WAV File

The Waveform Audio File Format (WAV) is based on the Resource Interchange File Format (RIFF) container structure originally developed by Microsoft and IBM. A WAV file does not store metadata as a simple text block at the start; it is divided into discrete binary "chunks" identified by four-character FourCC codes:

Why Video Editors Depend on RIFF LIST INFO

Video editing suites like Avid Media Composer and Adobe Premiere Pro were built around broadcast video standards. They do not have built-in MP3 ID3 engines for uncompressed audio. Instead, when an assistant editor imports a folder of 50 music cues into an Avid bin, the software reads the native RIFF LIST INFO sub-chunks:

Why DISCO.ac & Music Supervisors Require ID3v2.3

While NLEs rely on RIFF INFO, music supervision platform DISCO.ac and catalog search engines rely heavily on the embedded id3 chunk inside the WAV. Specifically, ID3v2.3 frames store musical data that RIFF never originally specified:

• TBPM: Integer tempo (e.g. 124), allowing supervisors to filter tracks by pacing instantly.
• TKEY: Musical key signature (e.g. Am or 8A Camelot), essential for cue-to-cue mixing.
• TSRC: ISRC codes for royalty tracking.
• TXXX (User Defined Text Frames): Crucial for sync licensing split declarations (e.g. TXXX:One-Stop: 100% Cleared, TXXX:Clearance Email: support@airtightaudio.com).

The SyncPilot Dual-Chunk Solution

Traditional tagging software forces you to choose between RIFF or ID3, or fails to write to 24-bit files entirely without forcing a lossy re-encode or modifying audio sample alignment.

SyncPilot solves this at the binary level. Our client-side WebAssembly and native Rust engines parse the WAV header, preserve every byte of your uncompressed PCM data chunk, and atomically append or update both the LIST INFO chunk and the id3 chunk.

When your file lands on an assistant editor's desktop, Avid reads the RIFF info. When it gets imported into DISCO.ac, DISCO reads the ID3 frames. Your clearance contact, BPM, key, and splits remain permanently attached no matter where the file travels.