- 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 <mva...@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@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
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
