<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    Martijn,<br>
    <br>
    <blockquote type="cite"
cite="mid:CADQbU6-jQQuZidA_oH61HKzff17ohRjwY3veAczFMY0u19pb6w@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>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.<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    OK.<br>
    <br>
    That's why I said<br>
    <br>
    "<font face="Courier New">as long as the audio data is consistent,
      with known format and correctly located."<br>
      <br>
      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.<br>
      <br>
      Regards,<br>
      <br>
      Federico Miyara<br>
      <br>
    </font>
  <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>