It seems like the ID3v2.3 Language/TLAN field (at least) is somehow not properly (or to defacto standards) being written-to or read-in by Jaikoz. Details below.
I started with a “clean” Mp3 file (having no tags whatsoever). I had deleted any existing tags and checked they were “really gone” by using a hex editor. Then, using another app (not Jaikoz), I added an ID3v2.3 tag with a Language field (ID3v2.3::TLAN == Jaikoz-ID3v2.3::Language), populated with an appropriate three-letter code (“fra”, meaning Francais/Français i.e. French-language). Actually I tried this same routine - producing same result as below - from three different apps.
When I then opened this file in various apps (tag editors, players, mediainfo, a hex editor), the expected TLAN/Language value was shown (either as “fra” or “French”, depending on the app).
However when I loaded the same file into Jaikoz (11.6.1 Doves, for macOS), the TLAN/Language field was displayed on-screen as blank. Despite the tag’s other fields being shown (the main ones at least, I haven’t checked every one in detail).
On the other hand when I entered (overwrote it with) “fra” in Jaikoz, then save/close and re-open that file in Jaikoz, the language was displayed (as “French”).
I next looked at this (Jaikoz-saved) file in a hex editor, to see whether Jaikoz saves TLAN data-field in a different format. I noticed that, in the hex, the preceding data-field (TPE2/AlbumArtist) had a string value that was not terminated with a Nul (Hex 00) character, instead the first hex value after the final letter of the TPE2 data-field was for the first letter (“T”) of the next data-field (“TLAN”). It looked as if, in the hex view of the data, the first of these fields had run up against the start of the other field.
Whatever, I get the impression Jaikoz is doing/expecting something (at the binary/hex level?) non standard (de facto at least) with this field.
Is there a bug here, affecting TLAN or possibly something more generic?