However, the byte value 0xa1 and 0xb3 are escaped by prepending 0xc2 and changing the length field from 15 (0f) to 17 (0x11). This cannot be due to unsynchronisation and seems to be a UTF8-escape.
This is wrong in two ways:
The ID3V2 standard clearly states:
Owner identifier $00
Identifier
That is: the identifier is binary data. Period. No encoding/rewriting whatsoever.
I am using ISO8859-1 encoding im my preferences. Thus, there should not be any rewriting for UTF-8 at all.
This is a serious problem for me since MP3TAG garbled most of my music library.
What does the ID3 standard say and define how the tag-field UFID structure should be constructed?
Isn't it a misuse of the tag-field UFID to fill it with any other data than the ID3 standard allows it?
Would it be possible that this ^^-marked zero byte is interpreted as the string terminator for the second part of the UFID record structure?
With the Mp3tag v2.58 it was not possible to create a real tag-field UFID.
Regardless of what tag-type has been written, Mp3tag creates a TXXX/UFID frame.
No, as I cited above, ID3v2 dictates a standard UFID header, with a data field containing a zero-terminated identifier string followed by up to 64 byte of binary data.
Even if that byte were misinterpreted, the size field tells to use the next 15 bytes - and that field is truncated to 12 bytes, so the truncation point is not the zero terminator, but the byte after 0x40, namely 0xf3. Thus, I assume another encoding issue.
And what is the difference? I quoted exactly that in my first post already.
is a standard ID3v2 frame header with an ID, size and flags fields. It is followed by:
Owner identifier $00
Identifier <up to 64 bytes binary data>
I have merely used one specific owner identifier "UFID_CRC32" that uses a CRC32 to identify the MP3 data contained in the file. That is, 0x5224f340 is the checksum in my example. I might as well use "WRZLBRMPF" as identifier and 00 11 22 33 44 55 66 77 as identifying data, but then the ID3v2 size field would be 18 (0x12). I bet it would not be truncated, since it does not contain bytes > 0x7f.
The tags were created using the standard library id3lib, BTW.