Picard Feedback - little bugettes\oddities

MusicBrainz Picard
, ,
1

Some little oddities I have noticed in Picard v2.3.1 on Win10 today. A bit of feedback for the devs if you want it. Do what you will with this information. Sorry for lack of tickets.

I have been loading up batches of 20+ albums to retag\update previously tagged files. All of these have MBIDs in place previously added by Picard. All files are FLAC and ripped via EAC from my own CDs. I am just looking for the little changes that may have happened since.

1) Picard now Alpha Sorts tag values. Things like Composers, Record Labels, etc.

If the values are the same, but in a different order, then Picard should accept these tags are correct and don’t need to be updated. I can see this causing a lot of needless tag re-writes.

-=-=-

2) Why does the Composer have a companion tag of “Composer Sort Order”, but Writer and Lyricist do not? All three of those credits should be equally important.

-=-=-

3) A related oddity. A BUG that has appeared in this last year. The “Composer Sort Order” uses the wrong value for an alias.

As an example: I have an album by Plan B. When he adds a composer\writer credit he uses his real name of “Ben Drew”. BUT the Composer Sort Order is incorrect here as it puts in “Ben Drew” instead of “Drew, Ben”.

The weird thing of this is that last time I tagged this album (March 2019) the correct Composer Sort Order of “Drew, Ben” was used.
Not an alias, just a hand written name as spotted by @kellnerd
-=-=-

4) I’ve locked up Picard a few times now. (Win10). The latest way is having 20+ previously tagged albums loaded up, checking through the data before hitting save. Mainly looking for those little edits that were pending when I previously tagged.

For six of the albums I went back online and added a Lead Vocal credit. I then come back to Picard, and do a multiple select of these six albums. Right click and select Refresh. Bang - Picard now locked within seconds. Grey’s out as Not responding. Green Progress highlight on the taskbar icon is stuck at the far left not moving. No change after 30mins.

It had started the refresh. The image counts had been put back to 0 images on each of the six and [ loading album information ] had been put in place. Then it locked before downloading any of those images. Nothing on the status bar.

I had refreshed a few albums one by one without trouble.

This happened more than once. Only option is kill Picard and try again. If I can narrow this down better I’ll add more feedback.

Edit: Done it again. Threw in ten albums to update data. All of them came up with red disks after a very long wait. Hit the refresh… locked up. Same lock at refresh, counters cleared to zero, Picard then freezes with white-out.And still locked up two days later. There were some Tori Amos albums in here which I know have HUGE art and I cause problems for myself by grabbing all artwork…

Only adding this note for myself in case I ever spot the pattern. And the REFRESH button is clearly a key part of this.

-=-=-

5) Sometimes the artwork download just gives up and get stuck [ loading album information ] on the list. Green progress bar on the TaskBar icon is at the almost complete state. How are hiccups with CAA handled? This is not a “Not Responding” lockup like above. It is more like it is still waiting…

Weird… same two albums have done it again. Doolittle 25 and Indy Cindy deluxe. Both have huge numbers of images being downloaded as I have “get all the art” ticked. (I’ll refine this question after the current server maintenance is completed)

Confusingly the green progress colour has been at the far right for most of the time. Though the status bar text has changed a few times. I think something is still happening so will leave that an hour to see if is actually continuing slowly.

Solved that one. 256MB of art on one, 327MB on the other. It was just a slow download… just the standard lack of Picard is Busy" feedback lead to my confusion.

-=-=-

6) Why is the track title “War at 33⅓” written as “War at 331/3” in the tag value? Is that caused by “Convert Unicode Punctuation characters to ASCII”?

2 Likes
2

That’s something I also noticed. As a solution I have written a little plugin to provide these fields. So far I’ve tested it only on a few releases and therefore haven’t published it yet. If you are interested, I will of course share it.

1 Like
3

To be honest, I have no real use for the sort orders of Composers\Writers\Lyricists yet. Seems a weird thing to store in the tags of a music file. Okay, I agree that Artist and AlbumAritst should have their Sort Orders stored. But why a “composer”? Why not the Vocalist? Guitar player? Drummer?

Would seem more logical to me to store the MBID of Artists so lookups can get this data as needed in the Media Player.

I am guessing that this is a creep of Picard into being a Classical Tagging tool. Composer Sort Order seems more like something that would make more sense in the Classical Plugin.

But then I don’t do much Classical music so I know I have no idea what I am talking about.

I am certainly interested in seeing and testing out your plugin. Give ya some feedback. :+1: :sunglasses: for example how does your plugin handle issue 3) above?

I am getting closer to messing with plugins myself, so am very interested in seeing your plugin. Especially when I saw the source code of “Hyphen Unicode” as it sparked a number of ideas in my head to fix problems I get in my files due to the " " ’ - type substitutions. I get a few confusing issues when trying to mix files with those tagged by other taggers that don’t use the fancy Unicode versions of punctuation.

1 Like
4

I’m going to test this tomorrow before I publish/upload the plugin.

There’s one reason for me: I’m using MinimServer as UPnP server, which allows me to browse and filter my collection by custom tags. Therefore it’s very useful to always have both the tag for the displayed name and for the corresponding sortname.
Usually I don’t filter by lyricist, performer etc., but I like to browse the composers. In Picard I wanted to merge %writer% into %composer, but then I need to merge the missing sortnames into %composersort% too :wink:

1 Like
5

So, now I have revised my old Python code of the plugin and hosted it on GitHub:

The plugin itself is very simple, because Picard has already fetched the neccessary data from the webservice (but does not offer it as additional variables or tags). When I wrote this in summer 2019, the most difficult part was the incomplete and partly wrong documentation. But since my last visit the plugin API page has been corrected and updated :+1:

Finally, the relevant part of my tagger script to show you how I transform this data for my personal use:

$setmulti(lyricistsort,%_lyricistsort%)

$copymerge(composer,writer)
$copymerge(composersort,_writersort)
$copymerge(lyricist,writer)
$copymerge(lyricistsort,_writersort)
$unset(writer)

I already have some experience in coding (and with Python), but this is my first attempt at writing a Picard plugin, so any feedback (even pedantic advice) is appreciated :wink:

3 Likes
6

This seems to be related to the Use standardized artist names option. When you have enabled this checkbox, the usage of Plan B as sort name is the expected behaviour:

image
image819Ă—187 21.9 KB

Maybe you have changed this setting since – or the Picard default setting has changed with the update?

2 Likes
7

Busy this week, but I’ll grab your plugin and have a poke at the weekend.

Interesting your comment about merging writer, composer, lyricist as I was also thinking something similar last weekend. I have lots of punk, rock, pop, folk, etc and no classical. A “writer” makes more sense to me.

Not ticked. And you may have missed the subtle nature of the issue. My Sort works most of the time. Any time you have a normal artist using a normal name then the sort will work.

So “Nick Mason” is correctly credited as “Mason, Nick”.

When it fails is in the rare cases like “Plan B”. He Performs as “Plan B”, but he credits his writing as “Ben Drew” (His real name). And the Sort for that alias is borked as it will show “Ben Drew” instead of “Drew, Ben” as it should. (See the alias link in the example)

Yeah - a weird one.

8

Doh, it looks like I can’t read… The whole time I thought I had read that the tag showed Plan B instead of Drew, Ben :sweat_smile:

Now I’ve finally realized your problem. I believe the aliases are not used for these writer credits, because what you see in the relationship editor is a free text field that has no connection to the existing aliases (and hence no sort name):

writer w/o sort
writer w/o sort867Ă—194 13.4 KB

3 Likes
9

Well spotted Mr Detective. Pity the database is not clever enough to spot the alias and match the sort. Have to wait for the MB Database to become self aware for that.

1 Like
10

Picard itself just takes the values in the order it gets it from MB.org. But I think there was a change at some point because I find the same with my music collection, probably the web service is sorting it alphabetically now. But I’m unsure whether we really should ignore the order, order could be important. But please open an issue on Loading...

It’s because there are actually tags for composer sort commonly used for MP4 and ID3, but there are none for writer and lyricist. It’s actually iTunes introducing tags for this; the TSOC frame for ID3 is unofficial and was introduced by iTunes, but is used by other tools as well now.

If this is important for you to have for lyricist and writer please add a ticket at Loading... . There needs to be some research if existing tools make use of these tags and how they store it for different tagging formats.

As noted by @kellnerd these are the “credited as” entries for the relationship, and there is no sortname for those. Not sure what else Picard should do. It could use the artists default sort name (“Plan B” in this case), but this is likely confusing. Or it could try to automatically generate a sortname (assuming the last part of the name is the last name), but this would fail for many languages and cultures.

Please do report any details on a ticket at Loading... . This sounds like a threading related lockup. Hard to tackle if one cannot reproduce it. How easy is it on your system to reproduce the issue? Does it happen rather frequently or very seldom?

Yes

5 Likes
11

Thanks for your responses @outsidecontext

MB itself ignores the order you enter writers. It just alpha sorts them on the website. I’ve always found this weird as many Beatles tracks are written by either Lennon and McCartney or McCartney and Lennon. The order is important there, but MB can’t show it.

The point I was trying to make in 1\ was when the tag in the file already have B, A, C. And Picard wants to change that to A, B, C. Then there should be no need to actually re-write the tag. Just leave it alone. Partly because this is triggering lots of re-writes to my files where there is actually no change at all.

I am thinking about how common it is for people to re-check large lists of files. Re-writing them to change an order it a bit pointless.

There are also people who will have set the order here specifically due to cases like The Beatles. Now Picard will wipe that out even though the data in the file was correct.

3\ I should have gone crossed this out after @kellnerd spotted the reason. Certainly can’t guess a sort of a name.

4\ If I nail anything down on that lockup, I’ll come back with details.

6\ Thanks for confirming. Think that will help push me into hacking plugins around now if I am loosing details like that just because I am trying to standardise my own dashes and speechmarks. I misunderstood that setting as “⅓” is a number and not punctuation in my world.

But nothing in this list is important. Sorry for lack of tickets, but I’ve explained that before. Sorry :frowning:

12

I don’t think this is a good solution. If we just ignore the order when saving and always keep the order already in the file this violates the rule that we save what the user sees. Also the user can manually change the order of the multi-value tags. It would be more than confusing if this just gets ignored on saving. Another option would be to set the order in the track metadata to the order in the file once a file gets matched to the track. But it’s not clear how this should behave if more than one file gets matched. Also it might unexpectedly change an order set by the user (imagine you load a release, change the order of the tags, then match a file and get it reset). The only clean way would be for MB to support an order here and return it properly in the WS.

Apart from that I see no big issue with this for the current state, as the order returned by MB is actually stable due to the sorting. So if you retag your files you will get the same order. The correct solution therefor is to save you files once with updated order.

I know, but it’s a pity. I think it is unreasonable to expect someone else copying everything over to the ticket system. I will do this if I personally want something or if it is reporting a critical issue, but I also think if someone wants something implemented they can do us the favor of filing a proper ticket. It’s really no big deal but helps a lot. Not doing this means something like the sort tags for lyricist just vanishes into the vast voids of the forums with basically zero chance someone will take up the task :man_shrugging:

4 Likes
13

This is exactly the point I am trying to show. If there is an order already set in the tag, Picard ignores it and just re-writes it anyway. If I set an order of B, C, A then Picard will change that to A, B, C every time.

But it is okay, I accept that. No need to explain more as we are talking different ideas and I don’t want to waste any more of your time on this thread.

Sorry. As explained before, I can’t join that site as my head won’t deal with the black hole of seeing issues lost and ignored like they are in there. The dates on tickets are too depressing to me. I can’t work with a popularity system to “vote” up issues. I also don’t talk the right language. I know these are my issues and not a criticism of how that Ticket site works. I just know what it would do to my head. I’ll avoid these posts in future as I see they are not useful.

This was not supposed to be a request for features, I thought I had seen a number of issues. Things that looked inconsistent to me. Blame the OCD. Between you and kellnerd it has been made clear these are more a case of odd side effects and me misunderstanding things again.

Sorry for wasting your time.

On a positive note, this will spur me to write plugins to fix these kinds of issues for myself. Starting with my own Unicode swapping plugin as I’d never have thought that a fraction was punctuation and wonder what else is being re-written I didn’t sport before.

2 Likes