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