RF64 is RIFF/WAVE grown past 4 GB. A plain WAV stores its sizes in 32-bit fields, which top out at 4 GB. RF64 keeps the exact WAV chunk layout but writes the sentinel 0xFFFFFFFF into the RIFF and data size fields, and adds one mandatory chunk right after the header: ds64, carrying the real sizes as 64-bit integers. A reader that sees 0xFFFFFFFF must go read ds64 instead. BW64 (the newer name, EBU Tech 3306) is the same structure. This matters: trust the 32-bit field and you compute a 4.29 GB size for every RF64 file, and any scan bounded by that size silently covers nothing. The record drawn below is a real ds64 body. Hover any field to light its bytes; click a field with a + to open its table. Color marks kind (see the key).
Identical to WAV, with two twists: the magic is RF64 (or BW64) not RIFF, and ds64 must be the first chunk. The 32-bit sizes are placeholders; the truth is in ds64.
'RF64' (or 'BW64'), then a u32 size field that holds the sentinel 0xFFFFFFFF, then the form type 'WAVE'. The sentinel is the flag: it says "my real size does not fit here, read ds64".
The mandatory first chunk. It carries the real riff size, the real data size, and the sample count as 64-bit little-endian integers, then a table that overrides the size of any other chunk that also overflowed 32 bits. The body below is 28 bytes: three u64 and a u32 table length of zero (no overrides needed for this file).
From here it is ordinary WAV: fmt, data, and any LIST/bext/cue the writer added. The one difference is the data chunk's 32-bit size, which is also 0xFFFFFFFF when the audio exceeds 4 GB; its real size is the dataSize in ds64.
The same as WAV, plus the ds64 override. The important part is defensive: never trust the 0xFFFFFFFF sentinel as a real size.