# Handling of Unique file identifier (UFID) frames
**URL:** https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [October 1, 2023, 4:56pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268 "2023-10-01T16:56:43Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@fridgemagnet](https://community.mp3tag.de/u/fridgemagnet)
#### Post date: [October 1, 2023, 4:56pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/1 "2023-10-01T16:56:43Z")
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](https://taglib.org/)), 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.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [October 1, 2023, 5:28pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/2 "2023-10-01T17:28:55Z")
Could you please provide an example song where you wrote binary data in a UFID frame?
That's the definition from [id3.org](http://id3.org):
---
### Author:  [@fridgemagnet](https://community.mp3tag.de/u/fridgemagnet)
#### Post date: [October 1, 2023, 6:32pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/4 "2023-10-01T18:32:02Z")
Sure, I've dropped one here:
`https://www.oasw.co.uk/public/Linkin%20Park%20-%20Papercut.mp3`
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [October 1, 2023, 8:53pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/5 "2023-10-01T20:53:56Z")
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?
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 2, 2023, 6:49am UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/6 "2023-10-02T06:49:49Z")
> [@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.
---
### Author:  [@fridgemagnet](https://community.mp3tag.de/u/fridgemagnet)
#### Post date: [October 2, 2023, 4:35pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/7 "2023-10-02T16:35:10Z")
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:
```auto
typedef struct {
uint32_t VersionId ;
uint32_t CueStart ;
uint32_t CueEnd ;
BOOL NRatioFlag ;
double NRatioLeft ;
double NRatioRight ;
uint32_t HighlightFlag ; } UFIDDataType ;
```
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 5, 2023, 7:22pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/8 "2023-10-05T19:22:50Z")
I've just released [Mp3tag v3.22d](https://community.mp3tag.de/t/455) which should fix the problem. Many thanks for reporting the issue!
---
### Author:  [@fridgemagnet](https://community.mp3tag.de/u/fridgemagnet)
#### Post date: [October 7, 2023, 11:04am UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/9 "2023-10-07T11:04:06Z")
Marvellous, thanks for the fast turnaround. I shall grab it and have a play.
---
### Author:  [@fridgemagnet](https://community.mp3tag.de/u/fridgemagnet)
#### Post date: [October 7, 2023, 1:33pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/10 "2023-10-07T13:33:19Z")
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...
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 7, 2023, 1:48pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/11 "2023-10-07T13:48:35Z")
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.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [November 6, 2023, 1:48pm UTC](https://community.mp3tag.de/t/handling-of-unique-file-identifier-ufid-frames/62268/12 "2023-11-06T13:48:46Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.