Force Picard to match song to different Album

MusicBrainz Picard
, ,
1

I have a song that won’t match to its album correctly. It matches to a completely different release–not other versions of the same release.
My song is already tagged, but I’m trying to sync the tags and download more.
It keeps loading Discovery: Bonus tracks from daftclub.com when I use Scanning for AcoustID.
I tried to re-run the match based on Lookup, which I expected would match to the correct album based on tags (similarity percentage), but it literally does nothing–no match at all. I can find the album online verbatim by name, but Picard won’t match it.

Harder, Better, Faster, Stronger by Daft Punk

PROPOSAL: Picard should permit the user to load ANY album they wish, so as to match correctly or force matches when there is either a lack of AcoustID information or ambiguous matches.

2

You can load any album you wish, and you have multiple options to do so:

  • You can use the search box in the upper right to search for releases. If you have enabled “Use builtin search” in Options > User interface the search results are shown in a dialog and you can select them and load them into Picard. If the builtin search is disabled the search opens in the browser, see the next point
  • If you open a browser search from within Picard (using “Lookup in browser” or the search) then MusicBrainz.org will show green “tagger” buttons next to each release*. Clicking those will load the release in Picard.
  • You can copy the URL if any MB release into the Picard search box and search for it, this will directly load the corresponding release
  • You can also drag and drop MB release URLs from e.g. your browser into the Picard main window

*) Technically this is done by adding the tport=8000 parameter to the MusicBrainz.org URLs, where 8000 is the port number shown in the lower right of the Picard window.

3 Likes
3

See also

http://picard-docs.musicbrainz.org/en/usage/retrieve_manual.html

1 Like
4

Thanks, glad to know this exists.

Shouldn’t the “Use builtin search” option be enabled by default? That’s a critical feature that isn’t available anywhere else. On the contrary, web lookup already has a button in the toolbar. Hiding this feature in the deep dark corner of a settings page seems a bit, idk, self-defeating. Nobody will use it if it doesn’t have a name that describes it well enough to know what it does, and especially if it’s buried in the settings in a nondescript list of check-boxes.

The message passing between browser and application is an incredibly rare feature in apps, so it’s not a great candidate as a default workflow. Users won’t automatically assume they can affect app behavior by clicking a link in the browser. Those two worlds don’t interact typically.

Copying the URL into search box feels like cheat codes. That’s not the behavior that the search box performs in most cases, so it’s not a discoverable feature at all. You have to “just know” it exists. Bad UI decision.

Drag and drop from browser to app–same as the message passing feature combined with the URL feature: not standard, easy to miss, you’d have to “just know”.

Make use of transferrable knowledge that people bring from their experiences with using other applications.