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

Federico Miyara fmiyara at fceia.unr.edu.ar
Sun Oct 30 17:57:09 UTC 2022


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.


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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20221030/5cd7df21/attachment.htm>

More information about the flac-dev mailing list