<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <font face="Courier New">Yes, adding a readily playable header may
      not be a good idea in the wrong hands and could be an option, but
      this method would allow compression of an audio file (or more
      generally, a signal file) with perfect recovery regardless of
      format or possible corruption.<br>
      <br>
      Archiving corrupted or experimental files is a valid, albeit
      infrequent, usage case.<br>
      <br>
      I'm aware that the raw format allows this but at the expense of
      the need of manual parameter input. In some cases, such as in
      adaptive sample rate
      (<a class="moz-txt-link-freetext" href="https://ieeexplore.ieee.org/document/1105415">https://ieeexplore.ieee.org/document/1105415</a>) the parameters may
      be unknown or meaningless. My proposal is to automatically
      estimate the needed information under the assumption that the file
      contains some sort of signal and possibly some ad hoc metadata.<br>
      <br>
      Just in case somebody in the future might find this idea promising
      :).<br>
      <br>
      By the way, I think a better name for "foreign metadata" would be
      "non-standard metadata" or "extended metadata"<br>
      <br>
      Regards,<br>
      <br>
      Federico Miyara<br>
      <br>
    </font><br>
    <div class="moz-cite-prefix">On 03/11/2022 16:09, Martijn van
      Beurden wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CADQbU6_xzR2FQiLvhxcKBahp-RUMC9HSM6GVpbwUFZDeUed4uw@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Op do 3 nov. 2022 om 19:39 schreef Federico Miyara <a class="moz-txt-link-rfc2396E" href="mailto:fmiyara@fceia.unr.edu.ar"><fmiyara@fceia.unr.edu.ar></a>:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">

Martijn,

Currently FLAC already stores and restores most kinds of metadata corruption without problems, so in most cases the conversion is already bit-accurate. However, there are some kinds of corruption it cannot handle. These are the kinds of corruption that invalidate your considerations. For example, when a chunk length is incorrect, the location and length of the audio data is no longer known. It is also possible the basic formatting information is invalid. In this case, FLAC cannot compress the audio at all, not even without considering foreign metadata, while general purpose compressors (who don't have to discriminate between audio and metadata) have no problem compressing.


OK.

That's why I said

"as long as the audio data is consistent, with known format and correctly located."

However, I think there are relatively few uncompressed formats, and probably all of them share having large audio blocks. It would be feasible to think of an algorithm that attempts to find audio alignment by iteratively testing a short portion for different alignments (meaning different number of channels and bit depths, little/big endianness, and a few other variants or combinations of PCM) until the maximum compression is attained. Once located the optimum alignment, the FLAC algorithm would provide bit-for-bit accuracy and maximum compression, even in the absence of format-awareness. It would take a bit more time to encode and could generate its internal header for direct playback compatibility.

</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
That would inevitably result in metadata getting stored as audio,
resulting in loud clicks and static, which I don't think is a good
idea.


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