[flac-dev] Looking for users of --keep-foreign-metadata

[brianw]

On Oct 30, 2022, at 10:21 PM, Federico Miyara <fmiyara at fceia.unr.edu.ar> wrote:
>> - There is a generally-accepted industry practice concerning these extra chunks that points out that it's problematic to preserve all types of chunks when editing the audio. For example, a visual overview or a cue list might easily become incorrect if the audio is changed. Of course, there are some chunks that can always be preserved, like original recording date, name of engineer, etc., but FLAC cannot know how to distinguish between the two types. My opinion is that FLAC should not suffer from this category of issues because the audio is specifically unchanged by the compression. Thus, it should be the case that all meta data can be preserved without risk, since the audio is also preserved exactly.
> 
> I think the validity or correctness of the metadata is the responsibility of the user and the software they use, not FLAC's. If I edit the audio and the software I use doesn't keep track where a cue should be it is not FLAC's fault.

I think these particular details - while interesting - are at risk of being outside the scope of the design of the FLAC command line. Either the operations are done within the (audio) software, or they're done on the FLAC command-line, and each case requires different handling.

A) If the software (DAW) does not support FLAC directly, then all meta data will be stored in WAV or AIFF, and the --preserve-foreign-metadata option that we're discussing is unrelated to the correctness of the software (DAW). In this case, the FLAC command-line is merely converting (compressing) a file, and it should not matter whether the input file is correct or not (so long as the chunk sizes and file size are consistent). In this case, FLAC is merely archiving a file in a lossless format.

B) If the software (DAW) does support FLAC directly, then the developers of that software will need to find some way to store their cue list and other meta data in the FLAC format, using application blocks as described in the FLAC specification. When saving audio from an application in FLAC format, there is no "foreign" meta data, per se, because the audio is not in AIFF or WAV format if it's saved directly in FLAC.

But I agree with your basic statement: Correctness is the responsibility of other software that creates the file(s), long before being handed to the FLAC command-line for compression.


> What FLAC should do is to keep anything deemed to be metadata. An example would be when some sort of corruption happens and I dont have the time now to look at it, but want to archive the file for future analysis

There are some types of corruption that FLAC cannot deal with. These would be corruption of the file chunks. Before contributing to the FLAC project, I worked on software support for WAV and AIFF files, in various software on various platforms, and there are times when the file must be repaired before it makes any sense. Examples would be when the chunk size is zero; when the chunk size would continue past the end of the file; or when the last chunk is followed by additional data that does not have a chunk header (size and chunk type).

When you have that kind of corruption, I'm fairly certainly that you'll need to perform at least some basic repair on the file before archiving it with FLAC. In fact, I'd recommend not compressing a corrupted file at all, or at least using something like ZIP or Unix compression tools that won't try to interpret the chunks while compressing.

I see your point: Sometimes you just need to back up the files without taking the time to look at the problems in enough depth to solve them. But if there's any corruption, then you might need to avoid using FLAC for your backup.

I'm fairly certain that the FLAC command-line will refuse to operate with an AIFF or WAV file that has inconsistent chunks, so you'll surely be forced to avoid FLAC in those extreme cases.

Brian