APPLICATION metadata block: riff (BWF), aiff and w64

[ktmf01]

The FLAC format has room for application specific data, which may or may not have an open specification. I haven't heard of widespread use of any of them and I'd say most of them are of no value to cellar.

There are however three of these that are used by the flac command line utility that store RIFF (WAVE), AIFF and W64 metadata. As the cellar wg is specifically targeting archival usage, are the metadata capabilities of WAVE and AIFF used to some extent in archival applications? Would it be of any use to include a definition of these riff, aiff and w64 application metadata blocks, despite not technically being part of the FLAC specification?

edit: or perhaps such metadata would (from a cellar perspective) be better stored directly in the Matroska metadata?

[retokromer]

I personally would prefer having them (I am thinking in primis of RIFF) with the codec rather than with the container.

[JeromeMartinez]

I haven't heard of widespread use of any of them and I'd say most of them are of no value to cellar.

Well, for video we had to create a dedicated format for that, RAWcooked, because there is no format with this feature. Well... We actually also implemented it for audio in FLAC, because we call FFmpeg which does not handle that AFAIK + we had to implement it for raw PCM.

Would it be of any use to include a definition of these riff, aiff and w64 application metadata blocks, despite not technically being part of the FLAC specification?

As for Matroska, there is a core spec (I am OK for including audio channel layout because it is relevant for the decoder for assigning the right channels :) ) and there is a tag spec, here the core spec refers to https://xiph.org/flac/id.html so IMHO it is fine enough for at least the core document.

[ktmf01]

Well, for video we had to create a dedicated format for that, RAWcooked, because there is no format with this feature. Well... We actually also implemented it for audio in FLAC, because we call FFmpeg which does not handle that AFAIK + we had to implement it for raw PCM.

I'm not sure what you mean: has another way to store 'foreign metadata' in FLAC APPLICATION metadata blocks been designed? Or do you mean RAWcooked is also being used for just audio, without video?

As for Matroska, there is a core spec (I am OK for including audio channel layout because it is relevant for the decoder for assigning the right channels :) ) and there is a tag spec, here the core spec refers to https://xiph.org/flac/id.html so IMHO it is fine enough for at least the core document.

Well, https://xiph.org/flac/id.html doesn't explain anything, it just lists which APPLICATION IDs have been taken. As far as I know, there is no document of any kind of the way flac currently stores RIFF (so also BWF), AIFF and w64, the implementation is the only 'documentation'.

So, perhaps I should write out the current implementation and submit it for inclusion on the FLAC website so it can be linked from this specification? Or is that not what you meant?

[JeromeMartinez]

I mean that it has a certain value.
But:

perhaps I should write out the current implementation and submit it for inclusion on the FLAC website so it can be linked from this specification?

IMHO it is not the core of the format, and at the difference of the WAVEFORMATEXTENSIBLE_CHANNEL_MASK such things don't have a role of expanding a limited list in the core of the format (it is for very specific purposes) so it would worth it to document it, definitely, but maybe not in the main document which will be sent to IETF (the ID list and the corresponding list would be hosted in this repo but in a separate document).