Shouldn’t an RF64 file start with BW64 as the first 4 bytes? Currently JUCE uses RF64.
The WavAudioFormatWriter and WavAudioFormatReader classes are writing and checking for RF64 (instead of RIFF), but as far as I know the RF64 files should start with BW64 …
Is it a bug or I misunderstand something?
I’m not sure that this wikipedia article is correct. The RF64 spec (google “RF64 spec” and the first link should be a pdf from ebu.tech.ch) seems to show the chunk using the header RF64. Searching for “BW64 spec” reveals a separate spec for a different format - but this specification does reference the EBU Tech 3306 paper in a few places, notably
This BW64 format uses the core elements of the format as described in EBU Tech 3306.
There’s also a bit more information on this page, notably
BW64 is the successor of RF64
It looks like BW64 and RF64 are different formats, where BW64 is a superset of FR64. Therefore, I think it’s reasonable for the WavAudioFormatWriter to use the RF64 identifier.
The RF64 spec also says
Any other chunks that are valid in a RIFF/WAVE file are also valid in a RF64/WAVE file. For
example, the BWF extensions for RIFF/WAVE can be used “as is” in any RF64/WAVE file.
So I think this means that it’s permissible to include an axml chunk in an RF64 file, despite the axml chunk being introduced as part of the BW64 spec.
Somewhat worryingly, the “keywords” section of the Tech 3385 (BWF) Suppl. 5 document about the axml chunk includes the keyword “BF64”, but I think this is a typo rather than a third type of 64-bit wave format 
I think that the current implementation of the WaveAudioFormatWriter is correct, but I’m not an expert by any means. If anyone can provide an example of a way in which the current implementation does not adhere to the RF64 spec, I’ll take another look.
Thank you, I also read the document you shared (before the OP) and started to look for the original RF64 format but I didn’t found too much info on that, maybe my googling skills… as “RF64 spec” was success 
, and as this document says, the axml chunk was introduced as part of the BW64 format, I thought JUCE is handling the BW64 format as it handles the axml chunk. So I was a bit confused, although it is not handling the chna chunk.
As Apple and Sony uses the BW64 format, maybe it would make sense to extend the current RF64 with the CHNA chunk handling? Are there any other differences?
BWF format still start with RIFF header.
So it does not surprise me that the 64 bit compatible version should start with RF64 (meaningfully hinting at being a RIFF file, but able to exceed 4Gb)
BWF itself is not actually a format. Format is still RIFF. Just happens to have some particular extra chunks that are useful for recording/editing in a broadcast environment.
Sorry to revive an old thread, but I’ve just been debugging a related issue and I thought I’d share.
From the EBU’s perspective, RF64 is deprecated. See: RF64 Question · Issue #10 · ebu/libbw64 · GitHub So, going forward, the “proper” approach would be to use “BW64” for files which have a chunk (probably the data chunk) > 4 gig. That’s what EBU’s libbw64 does by default.
That said, I couldn’t open the BW64 files written by libbw64 in Audacity, Reaper, Dolby Atmos Converter… Large wav files with CHNA and AXML chunks being generated by ProTools are identified with RF64. This is technically incorrect, since those chunks are not part of the RF64 standard.
A recent push to libbw64 will read files with either an RF64 or BW64 identifier and lets users set a flag to write with the deprecated id. That’s probably the best approach for compatibility right now. Being technically correct is nice, but I’d rather have things work.
BTW: it would be exciting if JUCE added more support for CHNA and ADM metadata: GitHub - ebu/libadm: Audio Definition Model (ITU-R BS.2076) handling library BW64 with ADM is the delivery format for Atmos distribution, so it’s becoming quite useful.
