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

[Federico Miyara]

> - 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.

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

> B) When --keep-foreign-metadata is added as an option, I believe FLAC 
> should strive to preserve all bits of the input file, and I believe 
> that the feature should allow that (although perhaps the code might 
> need some modifications). 

Agreed.


Federico Miyara

>
> On Oct 30, 2022, at 7:06 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote:
>> Hi all,
>>
>> Currently I'm looking for users of the --keep-foreign-metadata feature
>> of FLAC. There has been some improvement of this feature in FLAC
>> 1.4.0. Since 2007 there has been a warning in FLAC that
>> --keep-foreign-metadata is a new feature. I think removal of this
>> warning is long overdue, but there are still some issues surrounding
>> it.
>>
>> So, if there are users of this feature on the mailing list, could they
>> perhaps speak up? Can this feature be considered 'complete'? Currently
>> FLAC stores the top-level RIFF chunk and fmt chunk on encoding, but
>> does not restore them on decoding, is this considered a problem or
>> shortcoming?
>>
>> I know for example that WavPack will restore a WAVE file bit-for-bit,
>> even if there is ambiguous or even invalid data stored in the format
>> chunk. I don't think such behaviour is something that FLAC should
>> strive for. The current behaviour of storing metadata that is not
>> essential for decoding the file, for example CUE, LIST, bext chunks,
>> is I think sufficient, but I would like to hear the opinion of people
>> that actually use this feature.
>>
>> Kind regards,
>>
>> Martijn van Beurden
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>


-- 
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus