Picard does a pretty good job at tagging music, but sometimes it tags the music with an incorrect release. Like tagging an artist’s release to a compilation album (happens most of the time), or tagging a single with an album or something else. After the track has been tagged with an mbid, it’s a little difficult to modify it. I mean one can modify each tag manually, but searching automatically doesn’t works (one’ll get the same results again afaik).
##Workarounds
Change filters: One can modify the preferred release sliders, but that doesn’t works if one doesn’t want to use the same filter for each file. Also it is tedious to change the sliders for each track.
Lookup in browser: Lookup in browser before tagging. One can see similar search results in the browser tab, and then modify some tags accordingly, then try the lookup again. I think some users won’t like switching between applications, and it also is tedious.
##Proposed Solution
I think Picard should be able to display a list of releases within the application itself, just like the website shows when searching for a release. Not the complete exhaustive list of all similar releases, but the most probable ones, like a compilation release, a single release, an album (or more if search tags are quite similar). A user could click on the tagged track, and select display more results.Then present a list of similar releases in a separate window, or a another pane, and ask the user to select one. I think clementine does something similar when searching for metadata (but I’m not quite sure, I used it some time ago).
Presently, I haven’t done much research on how to implement this. I think the GUI shouldn’t be much difficult with Qt. But I don’t have much grasp of Picard’s working, how it accesses the MB database (afaik it receives a json for a release), as for now. Also should changes be made on the server side too. I personally think it’s a good idea (from my current knowledge), and would love to work on it this summer. Will lookup more into it after receiving a feedback.
Extending Picard to allow for more choices would definitely make sense. We already have kind of something like this: If you right click on an album you can choose another release version from the same release group in the “Other version” sub menu. But this UI is a bit limited. So if Picard would offer even more choices I think the new UI should provide more information.
If this in the end would be “just” a simple MB.org search for the release title and the display of the result in a smal dialog I think that would be not really enough for a full GSoC project. But if this has a clever UI with a well thought out customizable search this could be really interesting as a feature for users. The critical part beside the UI will be how the alternative choices get selected. Maybe this will come down to some kind of extended MB search dialog inside Picard.
I suggest you develop your idea into a more detailed proposal with some UI mockup that show how you imagine this would work. Also the following discussion about improved search on the server might be interesting.
Just because I think this is a bit misleading: You don’t have to change tags and do a lookup again. Once you have opened mb.org from within Picard you can use the full power of the MB.org search to look for whatever you want and get that into Picard using the green tagger button . Also you can use the search box in the upper right, even with extended search syntax.
Yes, this is exactly what I had in mind. Picard already provides search in browser option. It could be integrated with a search dialog within the application. Also, we can replace the lookup in browser option with a search option which will redirect to Picard’s internal search dialog, from where an option can be provided to lookup in browser.
The search dialog shall be the main part of the project. As for UI, I’m thinking of displaying minimal releases details with a small cover art at the side, so it looks a bit better than the web search.
These are all minor things that I currently have in mind for the project, though I’m still working on it. Just wanted to know, will you be mentoring for Picard this year?
Off-topic
AFAIK, one can’t tag the local track with those details. Those are only displayed in application, but not attached to a file object. One still have to modify the tags manually, isn’t it?
Nice to see you wanting to dev in PIcard.
Adding multiple releases UI would be useful, compilation matching issues are some of the most common reported about Picard.
You seem to be focusing on if you already have assigned MBID info to your files.
If you have the wrong information there then technically you have used Picard incorrectly in the first place.
Maybe it is an idea to look at getting that correct information in there earlier on (I am not sure if you are suggesting that)
Here are a few suggestions:
Often the recommended workflow is
Cluster --> Lookup (the Cluster)
so maybe that is an area to improve.
Possibly look at more elements here.
Track number, track lengths, etc. And try better matching as a group. Does the best match release have the same about of tracks, do the track names look similar, etc
tracks times within a few percentage and/or within a few seconds for all the tracks.
This might make the searching widely complex
Also it does still get a little confused for multiple artists in a cluster. Sometimes for a releases with multiple artists can be an artist name or Various artists in Musicbrainz.
In the cluster code it fixes the choice to Various Artists or a fixed artist name if they appear multiple times. It is a best guess with multiartist variable, but sometimes this isn’t correct and there is no way of doing a clustered lookup for the other option.
Sorry if that isn’t within the scope of what you want to achieve, just a few ideas.
(A more crude solution to getting re-running the checks would be to an option to intentionally ignore all MBIDs but that is a option in Option–>General)
Sorry if I hadn’t made this part clear. I was not suggesting to get the correct information right away (though it should be improved). Basically what I meant was if Picard has not tagged the album correctly, and the user chooses to lookup for more results, then ignore the tagged MB id and make a search with the original tags. Present the list (somewhat like the web interface) to the user and ask him to select the correct release. This would be within the application, so the user would not have to switch between browser. As for search, I’m thinking of retrieving the list by modifying the preferred release filters several times, so that we can get all sorts of releases like, some album releases, some compilations, some singles and so on.
I really appreciate the suggestions . I’ll look more into that.
I’m reviving this old thread, as the issue is still there …
I had an issue for an album, for which I had the original release (single CD), and that what rereleased as part of a larger compilation later (5 CDs).
Picard associated the files based on AccousticIDs with the later release, not the original one that I had. In this case, the change of the number of CDs in the release meant that CD numbering was wrong in addition to the other information of the release.
The original release did not appear in the “Other versions” sub-menu.
I found a workaround: I manually added the correct MB-release-ID tag to the files, before letting Picard match them.
So to improve the situation, I would suggest the following:
Add a choice in “Preferred releases” options to select older or newer release (it seems that Picard select the most recent by default)
Add a “Other versions” sub-menu at the track level, similar to what exist at release level in the right panel of Picard. This would enable selecting alternative releases of a track which may have different sets of tracks
. Also you can use the search box in the upper right, even with extended search syntax.