While exploring the ID3v2.3 TLAN (Language) field, by writing to it from Mp3Tag-macOS, I discovered that the value-string (three-letter country code) for that field was recognised by some apps (e.g. foobar2000-macOS, MediaInfo-macOS) but not by Jaikoz-macOS, which merely displayed a blank field (i.e. field name but no value).
Initially imagining that this was an issue with Jaikoz, I reached out to its support forum, at that point naively suspecting an un-read end-string null-character delimiter (later I was informed that no such delimiter would be expected, according to the standard). On request, I sent the developer (Paul Taylor) an example Mp3 file that had a fresh ID3v2.3 tag with (only) a TLAN frame written to it by Mp3Tag-macOS.
However, it seemed, from Paul's analysis, and as I was subsequently able to confirm via a smart hex editor (Synalyze It, with an MP3/ID3 grammar template) for that same example mp3 file, that the "unread value-string" experience in Jaikoz was instead rooted in the way in which Mp3Tag-macOS had written the string to the TLAN frame. Additionally, based on its grammar template, Synalyze It reported a string-length error, as:
ERROR: String size set to zero - skip element 'Text'
The value-string in question was "fra" (ISO-639-2 code for Francais i.e. French language). The string was in UTF-16 encoding, delimited not by an endstring character (e.g. null) but (implicitly) by (what I would call) a frame-body length value (in the four bytes just after the frame identifier, in this case "TLAN"). This value was two bytes too big (11, should have been 9). I wonder if that was because Mp3Tag had included the two BOM bytes in the length-count.
I understand that this thread in this community may be relevant.
Unfortunately the ID3.org server appears down at the moment (has been for at least a few days). However at this site is what appears to be a specification or description, saying:
Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order.
...a wording which - to my naive eye gives the impression that the BOM is part of the string, whereas I wonder if the author's intention was for the BOM (in this context) to act as a kind of string header, preceding its body. In which case the truly-real root of the problem might arguably be in the spec's wording. But that is just my spec. speculation - and my superficial-subject-appreciation neurons are beginning to get tangled...
Regardless, as a result, a Jaikoz update was released yesterday to work around this (excessive string length value) situation, as a result of which Jaikoz now displays the Mp3Tag-written TLAN value as expected. From what I understand (from the developer's explanation), the workaround, that I assume is in Jaikoz's string-value-reader function, was essentially to treat null in this context as an informal endstring delimiter. Even though in reality any such nulls encountered would (I imagine) only constitute padding nulls just after the end of the frame itself. The idea being that if, while attempting to "obey" the given string length, the string-reader function detected a null (implying that it had "run past the end" of the real string) it would stop and return the string up to just before that null.
I wonder if the various other apps I mentioned (other than Jaikoz and Synalyze It), which appeared not to have any issues reading the same value, employ some similar "defensive" tactic (not necessarily with Mp3Tag in particular in mind), against a de facto "meandering away" by some apps from the intention of the official format spec. I appreciate that conceiving/implementing defensiveness against de facto meanderings is a standard part of the pragmatics of programming real-life end-user apps.
Assuming the stated diagnosis to be correct, should a fix be made to the "incorrect string length" issue in Mp3Tag ? Or is there some other relevant factor?