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.
Scott Burkhart Scott Burkhart Effects, LLC http://www.scotteffx.com/ sc...@scotteffx.com https://www.linkedin.com/in/scotteffx 1-925-202-8852 > On Nov 3, 2022, at 8:10 PM, Martijn van Beurden <mva...@gmail.com> wrote: > > Op do 3 nov. 2022 om 19:39 schreef Federico Miyara > <fmiy...@fceia.unr.edu.ar>: >> >> >> 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. >> > > 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. > _______________________________________________ > flac-dev mailing list > flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
