Manage your music collection with Picard

Migration Example

In the example with the Boston albums, you'll notice that album tracks are displayed with icons to the left of their track names in the right column (Figure 4). If the icon is a set of musical notes, that entry has not been matched with any files from the Unmatched Files collection. If the matching track is still listed under Unmatched Files (meaning Picard wasn't able to match it with the album entry), just drag it over the matching entry in the right column.

Figure 4: Picard and MusicBrainz matched four of eight tracks for the first album. Some missing tracks are still in Unmatched Files.

Matched entries (i.e., entries that were under Unmatched Files but which Picard matched to tracks and albums in the right column) display various colored block icons. The colors include green, yellow, orange, and red. Green means your audio file matches exactly the entry Picard chose for it on the basis of its acoustic fingerprint. Yellow is a near match. Orange and red indicate less accurate matches. Any entry with a reddish/pinkish tint is simply an entry that is not an exact match and might need your attention.

In some cases, Picard found a matching track but under the wrong album, which is what happened with Party and Foreplay/Long Time (Figure 5). Picard found them in a compilation album before it found them in the band's debut album. To fix this, you can drag the entry from the wrong album over the entry for the correct album. When an album has no more matches (i.e., all the entries have the musical notes icon), right-click on the album name to post a menu. To clean up some space in the list and make it easier to drag album entries around, choose Remove from the menu to remove the album entry.

Figure 5: Foreplay/Long Time is matched to the wrong album. Dragging from the top entry to the bottom fixes the problem.

If a track is a bad match, click on that entry and then use the New Metadata Lookup button to do a manual search. This will open a browser window to MusicBrainz for that track. To find the correct track metadata, view the alternate PUIDs. In many cases, bad matches only reflect multiple PUIDs, unique IDs representing entries in the MusicBrainz database, that all end up having the same information (Figure 6).

Figure 6: A track from a Lord of the Rings soundtrack did not match exactly, but examination of alternative PUID entries showed all of them to have the same metadata. In this case, the entry provided by Picard is sufficient.

After the incorrect matches are fixed and entries under Unmatched Files are applied to the correct albums, the result looks like Figure 7. The matches are not exact, and I could go through them to fix the length and other metadata manually, but the matches are usually very close. Often the only mistake in the metadata will be the length of the audio track, which might be off by a second or two.

Figure 7: Few exact matches is not a serious problem, as long as each file in a folder is matched to a track on an album.

Once the change is complete, select all tracks and albums in the right column and click on the Save button to update the files on disk. This process can take a while, especially if your source and destination directories are on NFS mounts. As it completes processing of the file, Picard will mark the entries in the right column with green checks. The settings used in this example (set via the Options menu) will move the files, not copy them, to another directory. This makes it easier to determine what files and folders are still to be processed.

When all files have been tagged, select all entries in the right column once again and use the Remove button to clear the right column.

Tagging a Collection

To tag an entire collection, you could just drag the folder containing all the music files into Unmatched Files. If you try this, it could take quite some time for Picard to complete the matching process.

Unfortunately, Picard and MusicBrainz won't match every file. If your collection is missing ID3 tags, dropping your entire collection at once onto Unmatched Files will leave a lot of unmatched files and a potentially huge number of albums in the right column. If this is the first time you are tagging your collection, do it a few folders at a time, and process fringe music (e.g., soundtracks) in even smaller groups. If your collection already has some tagging, then dragging the top folder into Unmatched Files might be more successful.

In either case, it might be wise to make a complete copy of your collection before starting the tagging process, which will require large amounts of disk space. However, you'll be happy you did it if you run into errors in how the new files are named or tagged. By working on copies, you can always start over until you have Picard configured to produce the best results.


Picard works great on files that already have some tag information and works fairly well on those without any tags. It performed best with well-known artists and albums but had more trouble identifying movie soundtracks and couldn't recognize some of my classical albums at all. Picard also crashed when I tried to import my entire collection, so you might want to consider tagging a small set of album directories at a time.

Picard and MusicBrainz were fast in performing lookups over a cable-based network connection. I noticed a difference in basic functionality between the time I first tried Picard (January 2009) and the time I wrote this article. The old interface required that I use the Lookup button to open a web page on MusicBrainz. To choose the best match manually, I clicked on a green tagger button on the website, which then updated Picard.

The MusicBrainz green tagger buttons and Picard's Lookup button are still there, but Picard is now better at automatically searching, and the Lookup and tagger buttons are now only used in manual searches. This is probably an improvement with Picard 0.11, the version I used when writing this article.

Overall, I found Picard to be easy to use – especially given the way drag and drop allows for quickly matching files to MusicBrainz tag data.

The Author

Michael J. Hammel is a software engineer living with his wife, Brinda, and two Golden Retrievers in Colorado Springs, Colorado, USA. When he isn't working on grid systems or other geekery, he likes to play tennis, run his dogs around the park, drink tea with his wife, and wonder how his daughter is enjoying her first year of college. He has written more than 100 articles for numerous online and print magazines and is the author of three books on GIMP, the GNU Image Manipulation Program.

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More