BW64 support (to obsolete RF64)

[H2Swine]

The EBU won't anymore maintain the RF64 format: https://tech.ebu.ch/publications/tech3306
It has found its way into some broadcaster's publications (got that from a hydrogenaud.io contributor), and it isn't farfetched that the format will gain some traction among those who go for "object-based" audio. Which might not be FLAC's top priority, but:
To the extent they succeed at obsoleting RF64 altogether, then expect even stereo content to appear with the BW64 fourcc.

More: https://github.com/ebu/libbw64 ; WavPack supports it in the fresh 5.7.0 release ; Monkey's Audio since last December.

[ktmf01]

I am not sure what to do here. I checked out this libbw64, used one of the examples to create a file, and FLAC was able to process the file with --keep-foreign-metadata without any problems. I haven't encountered the BW64 fourcc like was added to WavPack here: dbry/WavPack@92b9d94

So it seems to me the examples of libbw64 don't actually produce BW64 files? Do you happen to know where I can find some?

Also, what kind of support do you think is appropriate? Just recognizing the file and treating all metadata as foreign, or should FLAC adopt this object-based audio metadata as its own too?

[H2Swine]

I am not sure what to do either, I don't know precisely what "level of support" is adequate to implement. More about that at the end of this comment, but: maybe it is possible to just allow "BW64" fourcc in place of "RF64"? (For what it is worth, it seems that https://ffmpeg.org/doxygen/trunk/wavdec_8c_source.html treats BW64 in a pretty much analogous manner to RF64?)

Why you don't see that fourcc when testing - it could be because the writing application works as in the EBU RF64 recommendation to not use it until it is needed? Compare page 10 therein with the recommendations in subsection 2.5 of the ITU BW64 doc: The recommendation is to write a RIFF WAVE compliant file when the size is less than 4 GB. That is,

• write the RIFF fourcc, and a JUNK chunk the size of a ds64 chunk;
• if and when file hits 4 GB, overwrite "RIFF" with "BW64" (instead of with "RF64") and the JUNK chunk by a ds64, and continue writing.

So if I am right, the recommended workflow means that a writing application could spew out a bunch of RIFF WAVE files, possibly with BWF chunks (and flac will process those). Then comes a too long file, what then? If that too long file were RF64, flac would happily process it; if they succeed at obsoleting RF64, then those files will be BW64 instead. Which makes for the question I asked initially: Would an adequate level of BW64 support be to simply amend the RF64 support to allow "BW64" as fourcc instead?

Maybe that is enough? My very loose opinion that object-based audio "might not be FLAC's top priority" is based on an uneducated hunch that they won't use the full object-based machinery for as few channels as 8. After all, FLAC cannot store 5.1.4. I don't know if I have seen "anything less" that isn't "standard multichannel".
But here comes a potential difficulty. On page 8 in the BW64 recommendation, it says that the WAVE_FORMAT_EXTENSIBLE (channel) information is "Not to be used in BW64." Then it says that, quote:

As multichannel audio should be described using ADM metadata, the use of this formatTag should be avoided. However, it should be possible that implementations are able to deal with reading a file containing this formatTag and handling it in a sensible manner.

It isn't clear on whether the WAVE/RF64 channel mask information should not be there, or if it is fine that it is there as long as you don't "use" it for anything. Anyway, one can handle channel allocation in one of the following ways:

• Honour that ADM metadata (mainly the chna chunk?) in some way or another. If the chna chunk will be complicated even when channel count is at most 8, it might be too much work to be worth it.
• If no formatTag channel mask is given, don't write any channel information (fingers crossed). Maybe give a warning. Maybe reserve that warning to 3 channels and above, presuming that one channel is mono and two are LR stereo.
• Enforce --keep-foreign-metadata for BW64 files, so that in the least the user doesn't find out too late that the information is lost. Or maybe make an exception for mono/stereo.
• Reject these files. Or some of them. For example, err out on multi-channel files without WAVE_FORMAT_EXTENSIBLE, but assume that 1 or 2 are mono or stereo. Or implement an --allow-bw64 for users who know their files, and err out with "encoder does not know channel allocation, use --allow-bw64 to encode without it".

So that gives possible alternatives for level of support, from "no support" like today and up ...?

(Edited because of left and right angles and a misplaced end-quote)

[iluvcapra]

FWIW, in the case of object-based audio, the Dolby Atmos DAPS and theatrical renderer create RF64 ADM WAV files, and in the event these ever became obsolete, WAV would probably be abandoned and they'd probably be replaced with IAB MXFs.