<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<font face="Courier New">Martijn,<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Once more, thanks for the exceptional tool that FLAC is and for
maintaining it.<br>
<br>
Regards,<br>
<br>
Federico Miyara<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 30/10/2022 11:06, Martijn van
Beurden wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADQbU6_mQYdSq+-i67+WERY4ER-5BOhM+GLX5BiVrw+C7J6hSA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/flac-dev">http://lists.xiph.org/mailman/listinfo/flac-dev</a>
</pre>
</blockquote>
<br>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
<br /><br />
<hr style='border:none; color:#909090; background-color:#B0B0B0; height: 1px; width: 99%;' />
<table style='border-collapse:collapse;border:none;'>
<tr>
<td style='border:none;padding:0px 15px 0px 8px'>
<a href="https://www.avast.com/antivirus">
<img border=0 src="http://static.avast.com/emails/avast-mail-stamp.png" alt="Avast logo" />
</a>
</td>
<td>
<p style='color:#3d4d5a; font-family:"Calibri","Verdana","Arial","Helvetica"; font-size:12pt;'>
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
<br><a href="https://www.avast.com/antivirus">www.avast.com</a>
</p>
</td>
</tr>
</table>
<br />
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>