mp3tag capitalised descriptors in the eyes of Kodi
#1
I've found that if I do some editing with mp3tag after gathering IDs from Musicbrainz, some of the tag descriptors get changed from "mixed case" to all uppercase.

For example, "MusicBrainz Album Artist Id" becomes MUSICBRAINZ ALBUM ARTIST ID........Artist becomes ARTIST....etc.
Apparently this change makes a difference to Musicbrainz because if the edited files are scanned by Picard again, it wants to add the mixed case entry again and fill it with what it "thinks" is missing data.

According to my research most people use a "case conversion script/action" in mp3tag to resolve this issue. In fact, I have confirmed that this works. - The problem is that while it will change ARTISTS back to Artist and satisfy Picard once again, the script will also change MUSICBRAINZ to Musicbrainz which Picard still doesn't like (it wants a capital "B") ....aka - 'MusicBrainz Artist Id'.

My question is.....does Kodi care whether the letters are upper, lower, or mixed when reading the tags?

Thanks in advance,
Bryan
Reply
#2
@ DaveBlake - Just thought I'd finish this up (maybe).....
I was able to see your reply here before it got lost during the server switch.
I was also glad to hear (paraphrasing what I recall) that "Kodi doesn't care". I have since confirmed that the "uppercase changes" made by mp3tag don't need to be reverted.


That said, I thought I'd also mention a little glitch that I think (??????) causes Kodi to crash when scanning is performed. Replies either confirming my theory or telling me that I don't kow what I'm talking about are welcome:
The short version is be careful if you run something through MB a second time after having made changes with mp3tag.

The long version is:
1) I had a couple of albums that I ran through MB then made some changes in mp3tag. - No problem thus far even if mp3tag made things all uppercase.
2) Then for various reasons I did some retagging with MB and got the expected duplicate artist/MBID entries because MB "thinks" the all uppercase entries are something different.
3) Not thinking clearly, I neglected to remove the duplicates prior to saving in MB for a second time.
4) This results in the music files having "identical dual entries" ie.... Instead of properly being Artist= John Q. Public it becomes John Q. Public\\John Q. Public  and instead of MBID=12345678-1234-etc. it becomes 12345678-1234-etc.\\12345678-1234-etc.
5) Scan library and Kodi crashes when it gets to John Q. Public ...... (not sure if it also happens when just updating library)
6) Edit with mp3tag again to remove duplications and Kodi has no problem scanning.
Reply
#3
Glad you saw my now lost reply. It probably said two things:
a) Kodi does not mind about capitalisation.
b) Kodi does expect tags to be named accurately - dashes and spaces matter.

As mbid tags are a customisation (on top of the published standards where they exist) Kodi expects the names that Picard gives them. Sadly these are a little inconsistent across different tag formats, and the odd user has been confused by this so I mention it. For example MUSICBRAINZ_ARTISTID in Flac files, but MusicBrainz Artist Id in mp3. See https://picard.musicbrainz.org/docs/mappings/ for more details. The capitals don't matter, the spaces and "_" do.

Then you have files with weirdly duplicated tags causing Kodi to crash during scanning. Do you really mean crash? Can you possibly let me have such a file?

I could try to make my own, but I'm not sure Mp3tag does make tags uppercase so not sure I can repeat your experience. Mp3tag uses uppercase names for the tags in the UI, just like Picard has it's own list of names for things, but saves them inside the file correctly for the tag format. A file I can disect would be good.
Reply
#4
(2017-10-17, 17:38)DaveBlake Wrote: Glad you saw my now lost reply. It probably said two things:
a) Kodi does not mind about capitalisation.
b) Kodi does expect tags to be named accurately - dashes and spaces matter.

As mbid tags are a customisation (on top of the published standards where they exist) Kodi expects the names that Picard gives them. Sadly these are a little inconsistent across different tag formats, and the odd user has been confused by this so I mention it. For example MUSICBRAINZ_ARTISTID in Flac files, but MusicBrainz Artist Id in mp3. See https://picard.musicbrainz.org/docs/mappings/ for more details. The capitals don't matter, the spaces and "_" do.

Then you have files with weirdly duplicated tags causing Kodi to crash during scanning. Do you really mean crash? Can you possibly let me have such a file?

I could try to make my own, but I'm not sure Mp3tag does make tags uppercase so not sure I can repeat your experience. Mp3tag uses uppercase names for the tags in the UI, just like Picard has it's own list of names for things, but saves them inside the file correctly for the tag format. A file I can disect would be good.

Yes Dave, that's pretty much what I recall you saying the first time. I'll keep in mind the flac/mapping issues if I ever get finished with my mp3's and decide to work on my flacs.

Anyway, if by "such a file" you mean the actual music file with duplications, I have just intentionally re-created some and I also took screenshots to illustrate the process. There's about nine of them, the last two showing the end result if one is not careful. Unfortunately, I can't seem to embed them here so (sorry) here's a link to imgur where it looks like you'll have to scroll down:

https://imgur.com/a/wISXR


If instead, you mean the dump file and stacktrace files produced from the crashes (yes, I did mean crash, and I today "crashes" does mean multiple attempts...... It took me three crashes to notice that the "library scanning progress window" showed the same album just before the crash. So I checked the album, found and removed the "duplicates", and had no more crashing.) I no longer have those.
Reply
#5
Actually I meant a music file with duplicated tags that causes a crash when scanned. Maybe it is just me but I don't ever get much from stack traces etc. Of course there is the issue of copyright, and sharing files etc., but it really would be the quickest way for me to reproduce the Kodi issue. I have no interest in the music itself, and I think intent matters (even if the law doesn't).

Anyway you have given me lots of pictures, thanks for those.

I woud like to see if we can make Kodi behave more elegantly (than crash) when weird tags give her indigestion.
Reply
#6
I note that you are using ID3 v2.3 format tags, and it's limitations maybe contributing to some of the things you have experienced. Unless you have some other ancient media player you want to use I recommend switching to ID3 v2.4. That supports multiple fames for a tag so it can have seveal separate values, while v2.3 is single frame.

I would add that the people at Mp3tag and Picard could benefit from seeing the issue that their products have.

I use both but on FLAC files, and have no such difficulties. Smile
Reply
#7
Just to say don't worry about providing a music file, after a bit of jiggery-pokery I have managed to get one with the same odd tagging you describe.

It is odd, I found that to reproduce I have to pretend to edit an mbid tag in Mp3tag (visiting it in the extended tag view), just editing some other tags and saving the fuile didn't do it. I do suggest that to report it to both Mp3tag and Picard, afterall you already have the screen shots. ID3 v2.3 with duplicate tags in the header is not going to fare well.

I have not found the crash on Kodi yet, but I bet it is Taglib getting upset with the broken non-standard tagging and then Kodi not dealing with the error well. But we shall see, all willl become clear in debug.

EDIT: Humm... not getting any crash. File scans perfectly despite odd tags
Reply
#8
(2017-10-18, 18:41)DaveBlake Wrote: I note that you are using ID3 v2.3 format tags, and it's limitations maybe contributing to some of the things you have experienced. Unless you have some other ancient media player you want to use I recommend switching to ID3 v2.4. That supports multiple fames for a tag so it can have seveal separate values, while v2.3 is single frame.

I would add that the people at Mp3tag and Picard could benefit from seeing the issue that their products have.

I use both but on FLAC files, and have no such difficulties. Smile

I have both MB and mp3tag set to save in v2.4. The pics showing v2.3 were because I started "the demo" with an old backup copy.


(2017-10-18, 19:19)DaveBlake Wrote: It is odd, I found that to reproduce I have to pretend to edit an mbid tag in Mp3tag (visiting it in the extended tag view), just editing some other tags and saving the fuile didn't do it. I do suggest that to report it to both Mp3tag and Picard, afterall you already have the screen shots. ID3 v2.3 with duplicate tags in the header is not going to fare well.

I have not found the crash on Kodi yet, but I bet it is Taglib getting upset with the broken non-standard tagging and then Kodi not dealing with the error well. But we shall see, all willl become clear in debug.

EDIT: Humm... not getting any crash. File scans perfectly despite odd tags

I'll probably post a quick message with a link, but I'm not sure either organisation will care too much. There's already one old post about the issue on the mp3tag forums and the developer didn't think it was a problem, and the folks at MB would probably say, "Stop using mp3tag and just use Picard." Wink

Anyway, I have just few more albums to re-tag before I can cease the "test library phase" and try an official "entire library scan". Once that's done and I listen to at least a couple of tracks, I'll see if I can reproduce the crash on a usb install and I'll try to set up one of your v18 releases on a usb also.
Reply
#9
So...
If I understand the forums over at mp3tag correctly, having mixed case "fields" was once an option but it was removed. Apparently the developer was attempting to avoid errors caused by user typos.
Further reading of the forums informed me that the "now default" uppercase values that are generated when customizing the tag panel can be overridden by editing the "usrfields.ini" file located in %appdata%\Mp3tag\data.
Long story short, I've performed a test edit of my latest ini file (each saved configuration has its own ini file) along with a repeat of yesterdays tagging procedure and no duplicates were produced.
The following are before and after's of the relevent parts of the file and not the entire file since people may want a different tag panel than I do. Basically, it's a matter of editing the "value=" lines to what Musicbrainz "wants to see."
Before:
Code:
[#0]
value=ARTISTS
name=Artists
multiline=0

[#1]
value=ARTISTSORT
name=Artist Sort
multiline=0

[#2]
value=MUSICBRAINZ ARTIST ID
name=MB Artist ID
multiline=0

[#3]
name=AlbumArtist
value=ALBUMARTIST
multiline=0

[#4]
value=ALBUMARTISTSORT
name=Album Artist Sort
multiline=0

[#5]
value=ALBUMARTISTS
name=albumartists
multiline=0

[#6]
value=MUSICBRAINZ ALBUM ARTIST ID
name=MB AlbumArtist ID
multiline=0

[#7]
value=MUSICBRAINZ ALBUM ID
name=MB AlbumID
multiline=0

[#8]
value=MUSICBRAINZ RELEASE TRACK ID
name=MB Release Track ID
multiline=0

[#9]
value=MUSICBRAINZ WORK ID
name=MB Work ID
multiline=0

[#10]
value=MUSICBRAINZ_TRACKID
name=MB_TrackID
multiline=0

After:
Code:
[#0]
value=Artists
name=Artists
multiline=0

[#1]
value=ARTISTSORT
name=Artist Sort
multiline=0

[#2]
value=MusicBrainz Artist Id
name=MB Artist ID
multiline=0

[#3]
name=AlbumArtist
value=ALBUMARTIST
multiline=0

[#4]
value=ALBUMARTISTSORT
name=Album Artist Sort
multiline=0

[#5]
value=albumartists
name=albumartists
multiline=0

[#6]
value=MusicBrainz Album Artist Id
name=MB AlbumArtist ID
multiline=0

[#7]
value=MusicBrainz Album Id
name=MB AlbumID
multiline=0

[#8]
value=MusicBrainz Release Track Id
name=MB Release Track ID
multiline=0

[#9]
value=MusicBrainz Work Id
name=MB Work ID
multiline=0

[#10]
value=MusicBrainz_TrackId
name=MB Track ID
multiline=0
Personally, I found the format for track id (#10) kind of odd whether uppercase or mixed, but my tag panel confirms that it's correct.
Reply
#10
mp3tag has a lot of powerful stuff in it, but takes some digging/experimentation to suss it out.  For example I don't have "release group id" in my tags, but found an mp3tag script for musicbrainz that I could hack to get it to add the tag.

scott s.
.
Reply
#11
(2017-10-20, 08:32)scott967 Wrote: mp3tag has a lot of powerful stuff in it, but takes some digging/experimentation to suss it out.  For example I don't have "release group id" in my tags, but found an mp3tag script for musicbrainz that I could hack to get it to add the tag.

scott s.
.

Sorry for the delayed reply. I intended to post a quick reply yesterday saying that I thought that I get "release group id" without using any scripts.
However, when I went to confirm that my memory was correct, I got sidetracked playing with my usrfields.ini file (found that I still had "duplication issues" with release country, release status and release type) and then had to attend to non-computer issues.
Anyway, (for all my music with MB entries) in addition to being listed in the default extended tag screen, an entry of "value=MusicBrainz Release Group Id" in my usrfields.ini file displays it in the tag panel also..... no scripts used. My setup is Win10, Picard 1.4.2 and mp3tag 2.84a.
Reply
#12
(2017-10-21, 15:21)Bryan_W Wrote:
(2017-10-20, 08:32)scott967 Wrote: mp3tag has a lot of powerful stuff in it, but takes some digging/experimentation to suss it out.  For example I don't have "release group id" in my tags, but found an mp3tag script for musicbrainz that I could hack to get it to add the tag.

scott s.
.

Sorry for the delayed reply. I intended to post a quick reply yesterday saying that I thought that I get "release group id" without using any scripts.
However, when I went to confirm that my memory was correct, I got sidetracked playing with my usrfields.ini file (found that I still had "duplication issues" with release country, release status and release type) and then had to attend to non-computer issues.
Anyway, (for all my music with MB entries) in addition to being listed in the default extended tag screen, an entry of "value=MusicBrainz Release Group Id" in my usrfields.ini file displays it in the tag panel also..... no scripts used. My setup is Win10, Picard 1.4.2 and mp3tag 2.84a.

I assume you got the release group id from Picard.  I don't use Picard at all, so need scripts to run in mp3tag.

scott s.
.
Reply
#13
(2017-10-21, 22:05)scott967 Wrote: I assume you got the release group id from Picard.  I don't use Picard at all, so need scripts to run in mp3tag.

scott s.
.

Sorry, I should have realized that you knew what you were talking about. :$
Reply

Logout Mark Read Team Forum Stats Members Help
mp3tag capitalised descriptors in the eyes of Kodi0