[F] Problem with UFID and character sets

Hi,

there is a serious problem with MP3TAG 2.36a and 2.37a (at least that were the versions that showed this behaviour):

The ID3V2 UFID tag is being garbled on any modification of any other tag.

You can see this in the hex dump:

OLD tag frame data:

55 46 49 44 00 00 00 0f 00 00 55 46 49 44 5f 43 52 43 33 32 00 69 4d a1 b3

This translates to "UFID" "UFID_CRC32" and the binary value 0xb3a14d69.

NEW tag frame data:

55 46 49 44 00 00 00 11 00 00 55 46 49 44 5f 43 52 43 33 32 00 69 4d c2 a1 c2 b3

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:

  1. The ID3V2 standard clearly states:

    Owner identifier $00 Identifier

That is: the identifier is binary data. Period. No encoding/rewriting whatsoever.

  1. 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.

It's been some time, but I've fixed this bug with the current Development Build.

Kind regards,
Florian

Either the bug was not fixed at all or it has reappeared. This time, the field is being truncated.

With mp3tag 2.58, the following happens:

OLD tag data:

55 46 49 44 00 00 00 0f 00 00 55 46 49 44 5f 43 52 43 33 32 00 40 f3 24 52

NEW tag data:

55 46 49 44 00 00 00 0c 00 00 55 46 49 44 5f 43 52 43 33 32 00 40

It seems, that in the advanced tag editor, the original field content is displayed truncated already.

Hm, just a comment and shot in the dark ...

55 46 49 44 00 00 00 0f 00 00

U F I D .. .. .. 15 .. ..

55 46 49 44 5f 43 52 43 33 32 00 40 f3 24 52
U F I D _ C R C 3 2 .. 40 F3 24 52

                          ^^</b><!--fontc--></span><!--/fontc--><!--sizec--></span><!--/sizec-->
  1. What does the ID3 standard say and define how the tag-field UFID structure should be constructed?

  2. Isn't it a misuse of the tag-field UFID to fill it with any other data than the ID3 standard allows it?

  3. Would it be possible that this ^^-marked zero byte is interpreted as the string terminator for the second part of the UFID record structure?

  4. 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.

DD.20140107.1405.CET

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.

Thus, the tag content is absolutely correct:

55 46 49 44 | 00 00 00 0f | 00 00 | 55 46 49 44 5f 43 52 43 33 32 00 | 40 f3 24 52

"UFID" | size = 15 | flags = 0 | "UFID_CRC32" + terminator | crc32

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.

Hm, your explanation is understandable.
But it seems to be different from there ...
http://id3.org/id3v2.3.0

DD.20140107.1527.CET

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.

This is now fixed (again) with Mp3tag v2.90e.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.