We have released a beta version for the upcoming MusicBrainz Picard 2.9 to get final feedback before we release the final version. As the alpha release did get rather positive feedback I don’t expect much changes before the final release. But please give it a try and report back.
I have noticed that often tracks get a green check instead of a green rectangle even though there are new or updated tags to be written.
(W10)
Interesting, but I cannot reproduce. Can you share some example or screenshot? Does this happen for certain tags only? Also make sure those tags are not set in Options > Advanced > “Tags to ignore for comparison”
@hiccup I tried this again, but really can’t reproduce. My usual suspect on issues like this are ID3 v2.3 tags, but currently I can’t really see how this happens. If you can see some pattern or maybe can give more insight into a specific case maybe we can narrow it down.
I’m sorry for not responding earlier.
But I have been noticing this very frequently, so I was kind of expecting that it would not take long for somebody else to experience and report this.
(b.t.w. often for a release I notice only one file (incorretly) getting a green check while all the others are recognised to have updated tags available.)
I fully understand and apreciate that it would help if I were to narrow down and analyse the setup and circumstances of why this may be happening. (to me?)
But since I’m not up to that it’s probably best to just ignore what I reported and assume it is just me.
(and thank you for your continued work on Picard, it’s much appreciated and respected)
.
edit:
b.t.w. for what it’s worth I am using ID3v2.4 for my mp3’s, not 2.3
And I am using several portable installs of Picard.
Some very Spartan, and some using plugins and more complicated scripts.
(Classical Extras, Additional Artists Variables, Format Performer Tags, Performer Tag Replace, and Language Name come to mind regarding plug-ins)
I’ll try to keep an eye out to see if I am able to recognise some pattern, but until then it’s probably best to ignore my cry wolf.
2 Likes
Alright. But if this comes up again, let us know. Just to rule that out can you check that you have nothing set in Options > Advanced > “Tags to ignore for comparison” ?
We already discussed that we will do a beta 2 release and I will do more testing before the final release as well, so maybe I’ll catch the issue.
I have nothing set there.
It is also happening with 2.9b2
I just send you an email with a link that shows the bug, and the setting files of the Picard installation that shows this behaviour.
Good luck!
1 Like
Thanks, got your mail. From the video this looks pretty clear. It’s odd how it affects only a single file in a full release.
Yeah I noticed that too.
I’m not completely sure if it always has been just one file, since I didn’t pay too much attention to it because I imagined this would get reported dozens of times within a few days by others.
Since it is not always happening, and also not to the same release or the same tracks, perhaps it is some timing issue?
(maybe related to a script that I use?)
edit
I seem to recall it was often the last track of a release, or one somewhere in the middle. But never the first one. Again, not completely sure.
2 Likes
Re. “Use standardized artist names” by default
There are quite a lot of entries in the ArtistsWithMultipleOccurrencesInArtistCredits report.
How should these be “fixed”, are there any non-trivial cases?
E.g. Artist credit “ちょむP(TakeponG)” - MusicBrainz
Right now it looks like this:
With “Use standardized artist names” enabled Picard will output this:
To handle this case I see three options for editors.
-
Add it in the “artist as credited” field
-
Add it in the join phrase field
-
Remove it completely
Option 1 seems the most straightforward solution without having to discard it completely while still delivering the expectations of “standardized artist names”.
Option 2 would still output both names if I’m not mistaken and might lead to similar problems when localizing the name too. (I haven’t used Picard in quite a while)
But what about option 3? Would it make any sense?
See also Edit #100704508 and Edit #100312314 (related to How to handle AI in MusicBrainz )
2 Likes
Not really a Picard issue that MusicBrainz doesn’t support internationalization very well (e.g., artist credits and join phrases don’t have alternate languages).
This is sort of an argument for keeping around pseudo-releases for the sole purpose of artist credits, but it goes in the opposite direction of the Style Leader’s opinion that artist credits shouldn’t be reflected in the Language/Script field of the release.
Generally I agree with yindesu that how these artists are credited is more a MB style topic and less a Picard one. However it is done, we usually have in the past tried to not make changes to the data in MB just because tagger limitations.
But regardless of the use case, I think the artist credit should be “ちょむP(TakeponG)”, as this is how the artist is credited on these releases. And not be split up like it is two separate artists. It’s not a collaboration or such.
But what about option 3? Would it make any sense?
It displays the artist differently then credited, so I don’t think so.
1 Like
@hiccup So far I could not reproduce your exact issue, but I experienced similar. When moving files around the similarity sometimes does not update properly and seemingly shows the similarity from the previous position. If that’s the case it might also explain your case (the files where not matched to a release before, that means they internally have full similarity, no metadata changes).
I added [PICARD-2669] File status icon sometimes shows wrong status - MetaBrainz JIRA
Can’t promise right now we will solve this for 2.9 release, we might move this over to 2.9.1 if we can’t nail it down. We have a couple of more important issues to solve which currently block 2.9 release 
1 Like
Thanks for the update.
It’s not some fatal bug, so I can live with it. It’s just odd.
1 Like
I notice that the ticket now says ‘fixed’ for 2.9.0b3, but for me it has actually gotten worse.
Instead of before when it was usually only one track in a release that received a green check (incorrectly), it now often are several tracks in a release.
Are you sure you tested with the latest beta 3? The issue I fixed was the only way I could reproduce this, and it also affected the only change in Picard 2.9 that was related to the status update. Apart from that I can’t see anything that would not already be in previous versions.
1 Like
I was sure. Yesterday
But a quick re-test now doesn’t show the problem.
As soon as I have the time I will setup a new b3 install, adding all my tweaked settings, scripts and plugins one by one.
I’ll probably report back on it tomorrow.
_
update:
I just tried the newly released 2.9 final, and the problem does not present itself anymore.
So it looks like I may have been doing the last testing with 2.9b2 and not with 2.9b3.
Sorry for my false report on this.
2 Likes