<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<font face="Courier New">Considering that <br>
<br>
1) audio data is always (I believe...) in a single connected
block, <br>
2) its location and length is unambiguously known, <br>
3) its basic formatting information is at the header, hence
readily and unambiguously known, and <br>
4) all metadata, either native or foreign, including the header,
is before or after the audio data (or both), <br>
<br>
would it be very difficult to just store all the information
before and after the audio, even compress it with any
content-unaware algorithm such as LZW, compress the audio with
FLAC's algorithm and when decoding restore each block (pre-audio
metadata, audio, and post-audio metadata) at its correct location?<br>
<br>
This would provide bit-for-bit accuracy, even for inconsistent or
ill-formed metadata, as long as the audio data is consistent, with
known format and correctly located.<br>
<br>
I don't know whether this would cause backward-compatibility
issues, probably yes.<br>
<br>
Regards,<br>
<br>
Federico Miyara<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 02/11/2022 09:48, Martijn van
Beurden wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADQbU6--YS3B9FsDQMOLh+JTWUFYSEPsEXwcFkEXheQ0z74uTQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Op ma 31 okt. 2022 om 01:37 schreef brianw <a class="moz-txt-link-rfc2396E" href="mailto:brianw@audiobanshee.com"><brianw@audiobanshee.com></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">- 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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Perhaps FLAC should refuse to do operations like --skip or --until on
a file with foreign metadata embedded? I don't think it blocks that
currently.
What I think would be a nice option is pick the correct format
according to the stored foreign metadata. Currently, one can use flac
--keep-foreign-metadata somefile.aiff without problems, but flac
--keep-foreign-metadata somefile.flac will then fail because flac
tries to restore to wav by default. Also, there are the mentioned
problems with WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE. One possible
solution is adding an option --force-foreign-metadata-format (similar
to the --force-aiff-format, --force-rf64-format, etc. options) which
would then pick a format according to what is stored in the foreign
metadata. This could work two ways: it could simply instruct FLAC to
find which format should be written to, or it could instruct FLAC to
not construct any chunks of its own but exclusively use the stored
chunks.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Reading your email question, Martijn, I think you might be asking whether FLAC should always preserve meta data - "restore ... bit-for-bit ... something that FLAC should strive for" - or leave this as an optional feature, so I want to comment on the two scenarios:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Considering being bit-for-bit accurate, I might be opening Pandora's
box here, but I think this should be dealt with properly, so I'll do
it anyway
The thing is, FLAC will store all chunks (except the contents of the
data chunk) on encoding, but currently ignores the master chunk, the
format chunk and the header of the data chunk on decoding. Usually the
result is still bit-for-bit the same (because there is usually no
ambiguity in how those chunks are formatted) but perhaps (I really
don't know, don't know whether such a thing is even possible) there
are cases where FLAC reconstructs something different than what is
stored. Choosing between WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE is
one such difference, but there might be others. That is why I'm
reaching out: perhaps the answer is obvious to people that use this
feature daily.
Perhaps an option --force-stored-foreign-metadata could be added to
have FLAC blindly use the foreign metadata chunks and data chunk
headers. I think this might result in invalid files (wrong chunk
sizes) in corner cases, for example when a FLAC file has been altered
(shortened/lengthened) but the chunks haven't been updated. I think
that might be the reason for the current behaviour.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">p.p.s. AIFF
I cannot remember whether --keep-foreign-metadata works with AIFF
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes, it does. It works with plain WAV and AIFF, and also with RF64 and Wave64.
_______________________________________________
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>