Jaikoz not reading TIPL fields correctly from Helium

[HaroldEvenson]

In particular, Jaikoz is messing up WXXX and TIPL frames that are UTF-16.

I’m using Jaikoz 4.3.1 NGS Pro.
\tID3TagV1 -> Delete
\tID3TagV2 -> Always write tag v24
\tDefault writing v24 is ISO-8859-1
\tText Encoding to use writing Unicode v24 is UTF-8
\tSave Existing Fields is checked
\t
I also use Helium Music Manager 8.1 Premium
\tSave tags as ID3v2.4
\tSave in Unicode

My workflow is to first tag using Jaikoz and save. Then open in Helium. Use AlbumArtDownloader. Then I tag with Helium to include the artwork and massage a couple of fields, save, rename and import into Helium’s database. At this point the tags are pretty and the file’s ready to play.

With Jaikoz, I reopened an album I had tagged earlier. I found the producer field changed to Chinese characters, the engineer field to be blank, and the Release Discogs Url field to be changed to 3 chars (Latin small y with diaeresis, Latin small letter thorn, h).

Without saving in Jaikoz, I viewed the tags in Helium. They were still pretty and correct. I made a change to the title field in Jaikoz and saved. I viewed the tags in Helium again, and now the WXXX and TIPL frames are broken.

So I went through these steps again, using a hex editor to watch the changes to the tags and compared with the ID3v24 docs.

After first tagging with Jaikoz, all text fields are ISO-8859-1. (Only thing, none of the fields are terminated with $00 as the standard suggests.) Every thing looks fine.

Next I tag with Helium. All the text fields are changed to UTF-16 and start with BOM (FF FE) little-endian. (Again, none of the fields are terminated with $00 00 as the standard suggests.) Everything still looks fine.

I tag again with Jaikoz, changing the title field. The text fields are back to ISO-8859-1 as before. But the WXXX and TIPL frames are now corrupt.

In particular, WXXX has a text encoding byte of $00 indicating ISO8859-1, it has a description of ‘DISCOGS_RELEASE’ $00. But the URL still looks like UTF-16. (FF FE 68 00 74 00 74 00 70 00 …) FF FE 68 get interpreted as the 3 chars I mentioned above and the 00 terminates the string.

The TIPL frame has a text encoding byte of $01 indicating UTF-16. It starts with BOM (FF FE), then ‘producer’ in little-endian UTF-16, followed by $00 00. Then it incorrectly has another BOM (FF FE) and the data, but the data looks like big-endian UTF-16. You can’t switch endian in frame. This time field is terminated with $00 00.

Thanks
…Harold

[paultaylor]

Hi Harold thanks I’ll come back to you soon on this.

(Only thing, none of the fields are terminated with $00 as the standard suggests.)

The specification doesn’t recommend this actually, it is a common misinterpretation of the specification.

[HaroldEvenson]

Thanks.

The specification doesn’t recomend this actually, it is a common misinterpretation of the specification.

Yes, I shouldn’t try to read after midnight. I also missed this little nugget about WXXX.

The URL is always encoded with ISO-8859-1

So Helium breaks this frame by changing the URL to UTF-16.

I thought a work around would be turning off the unicode option in Helium, but I still have issues with TIPL.

Jaikoz saves TIPL with an ending $00, like:
producer$00Peter Dawkins$00engineer$00Richard Lush$00

Helium saves TIPL without the ending $00, like:
producer$00Peter Dawkins$00engineer$00Richard Lush

When I edit with Jaikoz again, it drops the last tuple, and saves
producer$00Peter Dawkins$00

Thanks … Harold

[paultaylor]

Yes, there is a slight incompatability with ID3v24 TIPL frame between Jaikoz and Helium. Although Jaikoz does not usually write a null at the end of a text field because the TIPL field stores data as multiple pairs this made more sense, especially since the ID3V23 IPLS frame says

Since there might be a lot of people contributing to an audio file in
various ways, such as musicians and technicians, the ‘Text
information frames’ are often insufficient to list everyone involved
in a project. The ‘Involved people list’ is a frame containing the
names of those involved, and how they were involved. The body simply
contains a terminated string with the involvement directly followed
by a terminated string with the involvee followed by a new
involvement and so on. There may only be one “IPLS” frame in each
tag.

i.e in ID3v23 each field is terminated.

However in ID3v24 it is not necessary for the last field to be terminated. only for the fields to be seperated by a null

All text
information frames supports multiple strings, stored as a null
separated list, where null is reperesented by the termination code
for the charater encoding

So I should read the last pair modified by Helium, I have raised myself an issue http://java.net/jira/browse/JAUDIOTAGGER-390

I dont know why Helium is modifying fields that it hasn’t actually changed though, even more wierd that it defaults to using UTF16 , UTF8 would surely make a beter choice when writing to ID3v24 tags.

Also I was unable to get Helium to write the InvolvedPeople field (IPLS) when writing as ID3v23, if I changed it to use v23 compability mode it then used TIPL, which is just wrong for an ID�v23 tag. YOu may want to raise a few issues with the Helium developers.

(Ive updated topic title to better reflect the problem)