MM5 2054 wrong ID3v2.4 frame field separator [#13840]

Post a reply

Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: MM5 2054 wrong ID3v2.4 frame field separator [#13840]

Re: MM5 2054 wrong ID3v2.4 frame field separator [#13840]

by rusty » Tue Dec 27, 2016 7:26 pm

Hi Scott,

Thanks for the report.

One of the devs will look into the ID3v2.4 issue you raised.

As far as tagging failures: in testing we didn't notice any obvious problems. Are the issues specific to:
- any file type / audio format ?
- any particular fields?
- use of non-North-American characters?

Re. auto-organize, I assume that the bug is the fact that it works on the library but not on tracks via the Folders (which can contain tracks not in the library)?

Thanks.

-Rusty

MM5 2054 wrong ID3v2.4 frame field separator [#13840]

by scott967 » Mon Dec 26, 2016 10:10 pm

Per ID3 v2.4 spec 4.2
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.
In viewing mp3 files that have had tags written by MM5, it appears that text information frames are being written in UTF-16 with BOM but a forward slash (0x2F00) is being written instead of a null when more than one string is provided, for example in TPE2. This seems to negate one of the main improvements of ID3 v2.4.

As an aside, it would be beneficial for many uses if you wrote UTF-8 encoding as allowed in 2.4 spec instead of UTF-16 with BOM.

At least that's the best I can determine. I can't get MM5 to reliably sync database edits back to file tags and auto-organize doesn't seem to work either.

scott s.
.

Top