<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I need uncorrupted metadata, as I use data in Base64 encoding in a long text tag for my music synchronized light show. Implemented now in .mp3 ID3 tags, I hope to extend to FLAC, but that only works if metadata is kept exactly in its original content.<br><br><div dir="ltr"><div dir="ltr"><span style="background-color: rgba(255, 255, 255, 0); font-size: 17pt;">Scott Burkhart</span></div><div dir="ltr"><span style="background-color: rgba(255, 255, 255, 0);">Scott Burkhart Effects, LLC</span></div><div dir="ltr"><a href="http://www.scotteffx.com/" style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);"><font color="#000000">http://www.scotteffx.com/</font></a></div><div dir="ltr"><a href="mailto:scott@scotteffx.com" style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);"><font color="#000000">scott@scotteffx.com</font></a></div><div dir="ltr"><a href="https://www.linkedin.com/in/scotteffx" style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);"><font color="#000000">https://www.linkedin.com/in/scotteffx</font></a></div><div dir="ltr"><span style="background-color: rgba(255, 255, 255, 0);">1-925-202-8852</span></div></div><div dir="ltr"><br><blockquote type="cite">On Nov 3, 2022, at 8:10 PM, Martijn van Beurden <mvanb1@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Op do 3 nov. 2022 om 19:39 schreef Federico Miyara <fmiyara@fceia.unr.edu.ar>:</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Martijn,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>OK.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>That's why I said</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"as long as the audio data is consistent, with known format and correctly located."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>That would inevitably result in metadata getting stored as audio,</span><br><span>resulting in loud clicks and static, which I don't think is a good</span><br><span>idea.</span><br><span>_______________________________________________</span><br><span>flac-dev mailing list</span><br><span>flac-dev@xiph.org</span><br><span>http://lists.xiph.org/mailman/listinfo/flac-dev</span><br></div></blockquote></body></html>