Handling of Unique file identifier (UFID) frames

[fridgemagnet]

Hi,
I think there is an issue in the handling of UFID frames. In a nutshell, it looks like an assumption has been made that the identifier information is a string. In my case, I'm writing binary data (using taglib), which I believe is legtimate (the ID3 spec states the identifier can be up to 64 bytes binary data.

The impact of this is that what MP3TAG displays appears as garbage but the most significant problem is that if you then save the tag, it corrupts the identifier content by terminating it at the first null byte it encounters.

Thanks,

Jon.

[LyricsLover]

Could you please provide an example song where you wrote binary data in a UFID frame?

That's the definition from id3.org:

[fridgemagnet]

Sure, I've dropped one here:

https://www.oasw.co.uk/public/Linkin%20Park%20-%20Papercut.mp3

[LyricsLover]

If I see it correct, there are this hex values:
00 02 00 00 00 61 04
and later two times
f0 3f
saved as binary data after the mailto:URL, right?

But this would be more then 64 bytes from .co.uk until the next COMM tag?

[Florian]

@fridgemagnet

In a nutshell, it looks like an assumption has been made that the identifier information is a string.

This is an assumption! Just kidding

Thank you for the example file which exemplifies the issue you're describing. I'm actually trying to detect if the data in the UFID frame is valid UTF-8. If yes, it's listed as textual field. If not, it's treated as a binary field and preserved as such when writing tags.

It seems that the code that checks the identifier for valid UTF-8 stops at the first null byte. I'll have to investigate further and keep you posted.

[fridgemagnet]

The first byte of the data I think is at offset 0x8A - that's the 0x02 value (the previous 0x00 is the terminating null of the owner identifier string. The COMM tag (again I think!) starts at offset 0xB2. That's a total of 40 decimal bytes, which is what I'm expecting. Here's the 'C' struct it maps onto:

typedef struct {
  uint32_t VersionId ;
  uint32_t CueStart ;
  uint32_t CueEnd ;
  BOOL          NRatioFlag ;
  double        NRatioLeft ;
  double        NRatioRight ; 
  uint32_t      HighlightFlag ; } UFIDDataType ;

[Florian]

I've just released Mp3tag v3.22d which should fix the problem. Many thanks for reporting the issue!

[fridgemagnet]

Marvellous, thanks for the fast turnaround. I shall grab it and have a play.

[fridgemagnet]

Quick question, what is the expected behaviour now with regard to displaying these tags? If I open up the file I sent the other day, it now no longer indicates the presence of a my UFID tag...

[Florian]

ID3v2 UFID frames that contain binary data are now now longer listed in extended tags. They're recognized by Mp3tag and are preserved when re-writing tags.

ID3v2 UFID frames that contain textual data are listed for editing in Mp3tag, e.g., at extended tags.