You might be interested in hearing that I'm working on fully incorporating aifc support, including restoring the sowt byte order. If you are willing to test this functionality, please let me know
No, FLAC does not compress foreign metadata. Also, you are right that FLAC cannot restore AIFF data with sowt order. This is a limitation of the command line program
Do you have an example file? I'm unable to reproduce this. I tried compressing an old format 24-bit file with a cue chunk to FLAC, restoring it to WAVEFORMATEXTENSIBLE kept the cue chunk.
The problem here is that the foreign metadata is larger than the 16MB allowed maximum by FLAC, triggering some bugs. Do you have any idea what kind of chunk this is? It seems of the 63.504.112 bytes of that AIF file, only 47.424.520 contain actual audio, it seems the rest is some sort of metadata. I'll look into adding errors when this happens, but I cannot change FLAC to accept this data: the 16MB limit is one of the format and cannot be changed without breaking backward compatibility.
Hi, What preset have you used? Most presets, except presets -0 and -3, do stereo decorrelation.
Ah, it wasn't clear to me both accounts pointed to the same user :)
Could you perhaps check whether these patches fix the problem? PR: https://github.com/xiph/flac/pull/317 Code: https://github.com/ktmf01/flac/tree/vsx
It seems for some reason the compiler provides attribute((target("cpu=power9"))) but not the vsx functions in altivec.h when -mcpu=power9 isn't defined. This is much unlike GCC on x86, so I'm not sure how to proceed. I could check for the precence of vec_vsx_ld in altivec.h, but that would mean power9 functions aren't compiled in on your power9 machine when -mcpu=power9 isn't specified.