Show tag search results within Picard

picard
gsoc-2016
Tags: #<Tag:0x00007fcb51b32ee0> #<Tag:0x00007fcb51b32490>

#1

Show tag search results within Picard


##Overview

Presently Picard relies almost completely on the web browser for manual tag lookup. This includes searching for recording/release/artist by query, or looking up cluster/track. What I’m proposing is reduce this browser to somewhat lesser extent. This can be done by displaying the search results within Picard itself (like in a dialog) and allow user to browse and select tags from there. Just display minimal information so a user can identify the tags and ask to load them into Picard directly. If that not works for the user, allow them to lookup in browser.

What I’m trying to accomplish can be better described in these two sub tasks.

###1. Support for displaying tag search results within the application:

Right now, Picard redirects the user to MusicBrainz website when searching tags manually (the search box in the top right corner). The user can then select the release and load it into Picard.
Although it works pretty well, I think it is a bit tedious. Picard should be able to show the releases within the application itself. Not the complete list, just the top matches for different release types (like some compilations, some albums, some singles etc) with minimal information. And if the user is not satisfied with presented information, allow them to lookup more information in browser.
In addition to release, artist and track look ups can also be initially handled by Picard before redirecting to MB website.

###2. Show similar releases after automatic tagging has failed:

Sometimes automatic tagging fails to fetch the most accurate (in reference to the user) results. Although it fetches multiple release tags (i.e. 25 for tagging a file), sometimes the tagged one is incorrect, and the user is unable to see rest of the results. The usual scenario to correct such mismatch is somewhat like this:

Lookup in Browser -> Find the correct release/recording (In browser window) -> Click the tagger button (In browser window) -> Drag and drop the file to the loaded release (In Picard)

There are also other ways to load the correct track metadata into Picard as discussed here: Loading releases from musicbrainz.org into Picard , but all of them rely on the web browser (and are somewhat similar).

To simplify the correction process, support for displaying all the fetched results can be added to Picard. The displayed list of similar tracks would be organised (more description in implementation details), so user can find correct metadata with more ease. The process would be like this (if auto tagger has fetched incorrect information, and user chooses to show more results):

Right click and select ‘show more results’ -> Select correct track information -> [Optionally] Make a search for correct tags

All of this would be done without switching applications (in a Picard dialog window).


##More detail on components

###Dialog Boxes
Three new dialog boxes will be created (using Qt’s QDialog class):

  • Track Search Dialog:
    This dialog will be triggered when automatic lookup has failed (the track is in the right pane) and the user chooses to show more results either by right clicking and selecting show more results, or by clicking the search button in the top panel.
    This dialog will also be displayed when a user searches for a track by entering the query in Picard search box.
    If the user loads the track into Picard from this dialog box, the release associated with the track would be loaded rather than just the recording with [non-album-tracks] tag.
Track Search Dialog
  • Release Search Dialog:
    This dialog will be shown when searching for a release by entering query in the search box, or when clicking search button after selecting a cluster.
    This dialog can also be triggered by Artist Search Dialog, as described in next section.
    A release can be loaded into picard directly from this box. Clicking More Info would result in opening a AlbumInfoDialog instance. This is described in Implementation Details below.
Release Search Dialog
  • Artist Search Dialog
    This dialog is only triggered when a user searches for an artist from the search box. To load the corresponding releases, click Show Releases button. This would open up an instance of Release Search Dialog.
Artist Search Dialog

###Search Box in Dialogs
There will be a search box in each of the dialog as shwon above. This is especially useful when user is looking for correct tags after an incorrect auto tag. Sometimes the original tags are not sufficient for finding the correct release.

Search Syntax
A pre-defined search syntax will be quite useful when making a search for correct tags quickly. Musicbrainz’ indexed search syntax can be used for this. To make this more apparent to user, a placeholder text, or a tooltip can be added.


##Implementation Details

###UI Design

  • ui_searchdialog.py: Module which will contain definitions and design layout for the dialog boxes. Will contain following classes:
    • UI_SearchDialog: Parent class for all dialog boxes.
    • UI_TrackSearchDialog
    • UI_ReleaseSearchDialog
    • UI_ArtistSearchDialog
  • Design modifications in existing application:
    • Replace ‘Lookup in Browser’ with ‘Search with existing tags’. This will redirect user to one of the search dialogs. If displayed information is not satisfying for user, he/she can lookup in browser from there.
    • Add an option -> ‘Show more results’, when user right clicks on the file after the lookup (i.e. when the file has moved to right pane).

###Making a search when automatic tagging has failed to fetch expected metadata

When a user selects ‘Show more results’ after right clicking on the file after lookup, open up the Track Search Dialog and fetch metadata from MB server using original tags. This can be done by using lookup_metadata method of the File object. After parsing the XML, display the list of tracks to the user in organised way*.

*Organising metadata: This can achieved by:

  • Filter the downloaded XML according to the thresholds set by user.
  • Group together the items according to their release type. It would be easier to find correct tags this way.
  • Display the list in order defined by release preference of user.

The Track Search Dialog will be associated with particular File object for which the user has chose to lookup more results. When the user selects a track from the displayed list, directly load the release (i.e. Album object) into picard, and automatically associate that File object with corresponding Track object. This is in contrast with web lookup, in which Album object is loaded into Picard but the file for which lookup is performed isn’t associated with it. User has to drag and drop the file to corresponding track to get the tags.

###Making a manual search
This can be performed by entering the query in the search box in a specific format. Depending on the type of query (Track/Album/Artist) which the user will select from the drop down menu, corresponding search dialog will be shown. A module namely searchdialog.py will be used to handle search requests and managing the dialog UI. Classes for each dialog box will be defined here. These will be responsible for parsing search query, making the search, organising the results, and displaying them.

Releases can be directly loaded into Picard from Track Search Dialog and Release Search Dialog box (not the Artist Search Dialog). This would be a new Album object. There are methods already defined for fetching track and release details in webservice.py module. A new method for fetching artist details will be added to the module.

###Search using existing tags (Cluster or Track):
This will be useful if a user just wants more information on selected file or cluster without tagging. Picard already supports something like this, but through ‘Lookup in Browser’. Also this would be somewhat easier as lookup_metadata method is already defined in both file.py and cluster.py modules. All that is required is open up track/album search dialog, depending on what user chooses to lookup, call corresponding methods, organize the results and display them.

###*More Info* dialog for a release:
When user is viewing releases in a release search dialog, corresponding tracks are not shown immediately so as to make the interface clean. Instead they can be displayed by clicking More Info button (can be seen at bottom in ReleaseSearchDialog box mockup above). I’m planning to use AlbumInfoDialog from infodialog.py module for this. The problem is currently this dialog doesn’t displays corresponding tracks but only the cover art (and ClusterInfoDialog doesn’t shows the coverart). This is because the user can see corresponding tracks by expanding the release tree in Picard. So what I’m planning is also display the tracks information in the AlbumInfoDialog. It wouldn’t hurt the user to see track list in two places (in my opinion, it should be displayed if someone is looking for more information).


##Project Timeline
WOI.


##Optional Ideas
###Improve automatic tagging in Picard
Automatic tagging works pretty well for most of the time. Plus Picard has feature to fine tune the the preferred release settings which also works almost all the time. It would be better if it could improve a bit too.
Here’s a reported bug related to this: PICARD-786. I haven’t done much research on this, but from my current knowledge, what Picard does is fetch a list of metadata (25 items) from MB servers using original tags and then find the most probable match depending on preferred release setting. Sometimes it happens that correct release is not in those results.
This can be improved by either increasing the number of items recieved, or using some heuristics (like making a search by escaping some tags like release name, or track number, so as to avoid getting similar release). But I’m not sure about this. Maybe Picard already does something like this.


##About me

###Personal Information

###Probable Questions
Any previous experience with Picard development?
Yes. I’ve been associated with deveopment since last December. I’ve basic familiarity with Picard’s internals.

Any experience with Qt development?
Very basic, that too because of Picard. But I’m finding it not much difficult to work with, and there are huge resources on internet about it.

How much time can you devote to the project?
Can’t say for sure but atleast 5-6 hours daily. I’ll be having my summer vacation during most of the coding period, so this is my minimum estimate.

Associated with any training program/internship?
No, if selected for GSoC.

Expecting any break during the coding period?
Yes, for around a week. Most of the time I’ll be in campus, but I’ve to make a visit home. I’ll still be working during that time, but it’ll be a bit less than usual.

Details about computer to be used for the project.
Configuration: 4 GB RAM, 2 GB Graphics Memory, 3rd gen Intel i3 processor
Operating System: Fedora

What type of music you listen to?
Hip Hop, Pop, EDM, Rock, whatever’s on the billboard, and some favorite artists.
Some favorite albums.

  • Ghost Stories - 083305cf-1772-4db5-b10a-fb363c7e600b
  • X&Y - c50b180a-12c9-3153-8ba5-eac6a6537d6f
  • Recovery - 86c8b00a-aaf5-4795-8777-0bdf80e0ad3b

What type of books you read?
Humor, Young-Adult Fiction, Fantasy, Fiction.

Have you ever used MB data to tag your music?
After finding Picard, all the time.

Have you contributed to other open source projects?
Yes, though minor contributions.
Submitted two cheat sheets to duckduckgo (are live).

Some patches to Picard. Can be seen in my Jira profile.

Some projects you did in your free time?
Not much, just some very basic python scripts.

Are you even planning to work on optional ideas (or any work outside project scope)?
I’ve started with Picard development not only due to GSoC (though it was the main reason), but also because I find the project really interesting. So, yes, I’ll try to contribute as much as I can during GSoC period and later too.


#2

Would appreciate any feedback, suggestions, criticism. :slight_smile:
I’ll update timeline details soon.


#3

How does this work is say someone loads up 100 albums folders into picard. Picard automatically finds 70 full/complete albums and doesn’t match 20 albums folders at all and for the other 10 some tracks are matched to releases and some are left there?
Will it open 20 release search boxes and 10 track search boxes?

Load up 10 tracks in musicbrainz.
What if one track didn’t match from a album and musicbrainz matched 9 out of the 10 tracks?
You can see that the track belongs with the release the normal course of action is to drag the track to the release.
Would your automated system just open up a search box? Then you search for the track name? What if the release already exists in picard?

For the track search is that for tracks on a release or for recordings?

Sorry for all the questions.


#4

Looks like a pretty solid proposal to me.

I’d just be careful that we’re not storing the fetched XML for every single release. That’d likely drive up memory usage quite a bit. So it’d have to perform the search again if you open this dialog, or limit the number of results that are cached.

And I’d think you’re not going to get a lot of useful results for most tracks at the bottom of a list of 50 entries. I wouldn’t even display entries that don’t meet the configured score threshold.

If someone set the slider for a particular release type all the way to the left in their preferences, I think those should be excluded here.

It’d be nice if we could just share some of the code we use for rendering/expanding tracks in the right panel. I imagine we’d be duplicating a lot of functionality otherwise, because people are going to want to see titles, artist credits, durations, or open the recording on MusicBrainz, etc.


#5

There’s already an option under Advanced -> User Interface to enable advanced query syntax. We should respect this setting and not try to invent our own custom syntax.


#6

I am not sure I understand most of the queries. Can you elaborate the ones that are not answered below a little bit. Would appreciate that. :slight_smile:

No. Search dialogs will not be shown automatically. They will only be triggered when user asks for more results. Also I’m planning to display only single instance of each dialog box, so only one release/recording related information at a time. This is better described in implementation details (Making a search when automatic tagging has failed to fetch expected metadata).

The Track Search Dialog will display recording information. If user chooses to load selected track information in Picard, then corresponding release metadata will be loaded.


#7

Yes, you’re right. I didn’t thought about when user has loaded multiple tracks into Picard (like complete directory). Caching all that data will not be feasible.

Acknowledged. Updated the proposal.

I’m not sure about this. These dialogs are meant to display minimal information so the user can identify the track/release (I mean, that’s what I’m planning them to do). One can then load the metadata into Picard, or lookup into browser for more information. Another thing is, one can’t see the coverart on right pane, and in my opinion it would be a nice feature. I’m definitely up for using as much of previous code as I can, but I think dialog boxes would require new UI.

I really appreciate the feedback. Thanks. :smile:


#8

Well, agreed about displaying minimal information, but for tracks, I think number - title - artist - duration is about as minimal as you can get while allowing people to properly identify them. :slight_smile: Which is all what the tracks in the current panels show.


#9

Yes it does display minimal information. But for displaying cover arts too, the right panel code would require some changes. These would be specific for release dialog, as showing cover art in main window too doesn’t makes sense (one is already shown in bottom right corner). Else, I would’ve to skip the cover art column from release search dialog.

I am not including this into my proposal for now (as I don’t have much time to look more into it and you guys know we’ve already discussed this). I hope that shouldn’t be much of a problem. :slight_smile:


#10

Rahulr: You should submit your proposal to the GSoC site. You can still edit it after you’ve submitted it – but it is certainly close enough to submit to ensure you’re in the running.


#11

Sure @rob, will do by tomorrow after finishing up the timeline. :slight_smile:


#12

Quoting sttaylor in #gsoc (IRC) last night:

Remember a Final PDF must be submitted before the March 25th 19:00 UTC deadline to be considered for GSoC 2016
also if you submit your final pdf now you can upload a new one up until the deadline on March 25th
but I strongly encourage students to submit at least 6 hours before the final deadline - we do not extend the deadline under any circumstances
every year students miss the deadline because their wifi goes out or their computer dies and they have to wait until the next year to try again

So consider this a heads up and a reminder :wink:


#13

Thanks for the reminder :slight_smile: . Done!