On Oct 30, 2022, at 10:21 PM, Federico Miyara <fmiy...@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

_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Reply via email to