Martijn,
I'm a user of the feature. My case usage is the following; I record speech and music with a digital recorder (Zoom H4n) which uses a special wav format version including BEXT information, a kind of metadata including, for instance the device used to create the wav file. As I then process this file, I want to keep an exact copy of the original material for archival purposes. The feature works properly most of the time. The only exception is when one tries to decode, enabling the feature, something that hasn't been encoded enabling the feature (for instance, if when encoding I forgot enabling it). In that case an error appears indicating that there is not foreign metadata and it is necessary to uncheck the option and start over. I think in that case the decoder should simply proceed to decode ignoring the request, just considering "no foreign metadata" as a special case of empty foreign metadata. Or it could issue a warning but proceed after the user accepts. Personally I have found very few cases where the decoding differs from the original, and, if I recall correctly, the problem arose from a certain file corruption. Once more, thanks for the exceptional tool that FLAC is and for maintaining it. Regards, Federico Miyara On 30/10/2022 11:06, Martijn van Beurden 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
