Thomas Orgis

Hm, so id3v2 is not actually displaying the binary data for UFID. I thought I'd let mpg123-id3dump show it in hex. Regarding additional fields: I guess you'd like to see the URL fields (starting with W), too. Then there's TORY. There is a numer that I did not cover. Adding more text-like fields is easy. The binary ID needs some specific bits, but not such a big deal. So far there was no demand for more fields, but sure, I can add more.

Sure, mpg123's ID3 parsing is not exhaustive. It is mostly about (text) fields useful for player display. Can you give an example file and also show the id3v2 output? Seems like id3v2 doesn't actually create UFID frames. id3v2 --UFID xxx foo.mp3 does not result in anything being added to the file. So I wonder how you populate these and also, since the data is supposed to be unspecific binary, how it is to be displayed. This field seems to be designed for the same purpose that Amazon utilizes a simple...

Hm. You got a working example that does this in custom assembly files? Is the layout exactly the same on x86-64 as on ARM? What replaces __ARM_FEATURE_BTI_DEFAULT and __ARM_FEATURE_PAC_DEFAULT? I wonder how many of these annoying busywork items will crop up, making it more and more cumbersome to carry stand-alone assembly files. Maybe we need to go to inline asm, after all, at least for active architectures. We'd keep the files for 32 bit archs unchanged, I presume. But for now it is reasonable to...

Isn't this a major bug in cmake and subprojects should just be avoided unless there is some isolation between them, or at least controlled sharing of variables? Anyhow, I imported the most recent patch. Is current revision 5532 fine for you?

Attempting to build results in syntax error

mpg123 build failed for the avx assembly files.

out123_open uses strtok_r, which is unavailable on MSVC

Using libmpg123 to get raw ID3 returns modified data.