Duplicate tracks displayed in Picard?

Once in a while I get duplicate track entries in the right side panel of Picard.

e.g. track 9 here:

I see no explanation in Picard what this means, and I am pretty sure the folder doesn’t contain duplicates of this track.

Does somebody have a clue what this means?


A follow up question about the same album:

Track 2-12 1:47 is certainly present in the folder.
Why would it get a music-note icon instead of a green column icon?

I suspect Picard is assigning two audio files to track 1-09, and none to track 2-12. Check the two entries under 1-09, and see which really belongs there. The other entry may belong with 2-12.

And, if Picard is having trouble assigning those two audio files to the right tracks, it may be having trouble with other files in the same Release. It might be wise to check all tracks.


I don’t see anything out of the ordinary when I check the folder, nor when I play the album.

With a lot of (classical) albums/box-sets, Picard seems to have a lot of trouble presenting stable output

Another example:

Is there something I could do preparing/tagging the album/tracks prior to loading them into Picard to get better results?

1 Like

And another album:

It looks like Picard gets very confused when there are tracks present in a folder that have similar playing lengths.

Am I really the first one here that experiences this?
Or am I doing something very wrong in the way I have been doing my tagging and maintaining my library?

A green note means that no track has been matched, if there’s two entries under the green note it means that two tracks (files) have been matched to the same track in the database.
Picard works with what it’s got - if the existing tags are wrong or there aren’t any, it will just use the information it’s got to try and match it, for instance track length.
(that’s for ‘Lookup’, ‘Scan’ will use the actual audio data instead of existing tags, but can take longer and throws up a lot of compilations)

Select each one to compare the old and new tags and see what’s up and we can go from there:



I suspect I didn’t make my advice clear. Let me re-word it.

In the Picard user interface, on the right-hand pane, look for the CD icon labelled “Bach 2000…”, and below it the green musical note labelled “1-09 Kantate, BWV2… III. Aria (Alto)…”. Underneath this musical note are two indented entries, both with green rectangles, both named “Kantate, BWV2… III. Aria (Alto)…”.

(When I say, “check all tracks”, I mean to click on the track entry in the Picard user interface, and look at the values in the lower part of the user interface under Original value and New Value. I do not mean to leave Picard, and look at the audio files in their folder in the File Explorer.)

In the Picard user interface, click on the first indented entry with the green rectangle. A table of values appears in the lower part of the Picard user interface. The animated image in @aerozol’s reply shows this happening. The colums of this table are labelled, Tag, Original Value, and New Value. Look for a row where Tag is “Track Number”, and a row where Tag is “Disc Number”. Look at the values in the Original Value for those two tags. Note the Disc Number and Track Number.

Now, in the Picard user interface, click on the second indented entry with the green rectangle. The table of values in the lower part of the Picard user interface changes. Note the Disc Number and Track Number for this entry.

It is likely that one of the entries will say, Disc Number is 2, Track Number is 12. That entry should be assigned to the track, back in the top-right part of the Picard user interface, which has a green musical note icon and a label, “2-12 Kantate, BWV 5… IV. Recitativo…”. Drag this entry from its spot under the “1-09” entry, and drop it on the “2-12” musical note icon.

You should see that the “2-12” musical note icon turns into a green rectangle icon, like the other entries. Also, the green musical note icon labelled “1-09” should turn into a green rectangle icon, and there should no longer be indented green rectangle icons underneath it.

MusicBrainz and Picard have an ultra-reliable way to relate an audio file to the corresponding MusicBrainz database entry, instantly and without error. It is called an “MBID”, short for a “MusicBrainz Identifier”. Read more about it in the MusicBrainz Identifier documentation.

When you tag audio files with Picard, it will write MBIDs to the metadata in the audio file. The next time you open those tagged audio files in Picard, Picard will instantly retrieve the entry for the Release, put it in the top-right part of the user interface, and assign the correct audio files to each entry.

The first time you tag the audio files, they will have no MBIDs. You have to follow the Picard documentation to assign audio files to Release entries, as you have been doing. It’s usually simpler to do this one Release at a time, or a couple of CDs at a time, even though you could try opening folders with audio files for dozens of Releases, and Picard will do its best. With just one CD having, say, 16 tracks, and with 16 audio files, Picard is more likely to make the correct assignments.

I hope this is helpful.


Thank you Jim_DeLaHunt. That’s certainly useful.
I was indeed thinking there might be something wrong with my current tagging scheme, and I was looking for problems there.

Lookup will often not present any (useful) results with larger classical releases. (that’s understandable)
Scan does a way better job with those.
But the issue seems to be (just guessing here), that Scan will try to match only a couple of tracks, and will then usually present the correct release.
But it will ignore the contents of tags such as track numbering and track titles, which could be useful to further improve the output.
So that’s probably why the track order sometimes is a big mess.

That indeed makes it necessary to do a lot of checking and corrections before you can save the release.
Your, and aerozol’s explanations are very helpful to get some better insight and a workflow in doing that.

Hopefully the ‘Scan’ function in Picard can be improved a bit so that it will also look at track numbering, and perhaps at track titles too.
Or if that’s too difficult, just adding a sortable ‘track #’ (and ‘disc #’) column in the right pane might help. I think that could speed up corrections for a lot of classical album releases I have been trying out with Picard.

Scan will match everything that we have the AcoustID for. If it’s not matching tracks, it’s because nobody has submitted an AcoustID.
However if it only matches one track to the correct release that’s fine - you just have to drag and drop the rest onto that release and you should be close to done!

This is by design. Scan ignores all tags and just matches to the AcoustID.
A combination of the two would be very confusing for the user, as they can give different results, and having a program try and guess which result a human wants would be… tricky. So we currently simply have two buttons and you can choose which to use :slight_smile:

If Lookup isn’t matching to the correct release on MB, it’s likely that your existing tags differ quite a lot from how we’ve credited things in the database for that release. It should match things to the correct track (eg using your track number tag) unless it’s found something like a track length and track title (for instance) that seems to match up more accurately, in which case it will weigh it towards another track.

Anyway, good luck and have fun! :wink: