I run an Internet radio station and my music library is about 4000 tracks. I’m looking to do a better job of organizing the library. But whenever I add some tracks to be analyzed it works hard to find complication CDs and group these songs together in. I’m not looking for that, I simply want to standardize Track Name, Artist, Album that the song was actually from, not the album that the software thinks its from based on the other music I submitted with it.
For example. Elton John-Your Song was off the original album “Don’t Shoot Me I’m Only The Piano Player”. But since I also submitted it with a bunch of other songs, it takes it’s best guess that it is on a compilation album with all these other songs.
Is there a way for me to have it find the correct album or do I need to manually go through almost 4000 tracks and manually fix it?
Thank You!
In the Options \ Metadata \ Preferred Releases go mess with the sliders.
I am guessing you are using the Scan button to match recordings. These sliders help change matching the bias more towards albums \ singles \ EPs and reduces the match to complications.
Hello, @RobLI57 , and welcome to MusicBrainz! I’m glad you are finding a use for the data which we all curate.
I don’t have any useful advice for you, but I must say I am amused by this typo:
Yes, those compilation CDs are certainly a complication for what you are trying to do! 
All of the above advice is good. But in essence, Musicbrainz and thus Picard are geared towards albums (and EPs) rather than singles. (Personally, IMO that is a pity, as I think single releases should also be included in the Musicbrainz database - but that is not how it is right now.)
So what you really want to do is to treat your library as Non-Album-Tracks i.e. individual recordings rather than odd tracks from albums. Unfortunately this is not my area of experience or expertise, and I have no idea how best to handle this - but experimenting with the sliders that @IvanDobsky mentioned would be a good start.
To be fair, singles are included in the database. The issue is more about the bias as to how things are matched on a search. The Picard matching, especially from the Scan (AcoustID) option, is about popularity. So can often miss that original album\single match when left on default. It is especially common that a vinyl 7" has never had an AcoustID submitted.
Some people get good success when messing around with those sliders, but everything need a human to check and override the results.
Actually, I think I was wrong.
As @IvanDobsky says, singles can be included in the Musicbrainz database - but I had assumed that the coverage was on the low side.
But his response prompted me to do some research and see if my assumption was correct - and as far as I can see I was just plain wrong!!! Looking at some well known artists, they have relatively long lists of singles.
That said, a single would (historically at least) consist of at least two recordings - A and B sides of the 7” vinyl (though in the digital age this may no longer be true). And if you only have the A side recording in your library, you would still have partially populated releases.
So perhaps a collection of (lets call them) “popular” tracks might still be best handled as NATs rather than “singles”. But not having experience of this myself, this remains only a guess.
If those tracks already have reasonably accurate metadata, you should always try Lookup.
Scan is dangerous. There are many false acoustID associations and many stray (unmerged) recordings and you should really check your results from Scan, or worst case, you end up with a different Artist, if it was the best matching album. But if you have to use Scan, @IvanDobsky’s initial advice will certainly improve your results.
I always use Scan. There’s only a 1% error rate in fingerprint recognition.
I know you can count 
, but only 40 songs will be incorrect in your case.
If you have any additional questions, let me know.
And one more thing.
Turn off RDS on your radio, as the wrong artist and song can annoy listeners.
Let’s say you want to play a Christmas carol, and Trash Metal comes on the air.
I sent you an email. I can’t post on the forum because the lawyers will come after us.
IMO neither of these will be great in this use case of individual tracks rather than albums.
Lookup is designed to work on clusters and uses whatever metadata it can get both from tags and also from the directory name, the track names, the track numbers, the number of tracks in the album – and that works substantially less well for individual tracks. The individual track may have originated as a rip from an album and have album metadata - and Picard might then load the album and allocate a single track to it. But if it doesn’t have metadata, then IMO it is highly unlikely that Picard can identify the track. (But as I said previously, I have no experience of using Picard for this sort of library and an ounce of genuine experience in this area is worth an infinite amount of theory.)
Scan is going to generate an audio-fingerprint that will uniquely identify the recording - and this is a good start. Picard then uses the recording to select a release and that can be influenced by the sliders described above - but because Picard is Release oriented, AFAIK it will try to identify the best Release to load. But if you want to treat each track as a NAT (which is my recommendation for a library like this), I am not sure what slider settings you need to adopt.
I would agree with this - recordings are a bit of a mess because (historically at least) when albums get added new recordings end up being created by default rather than finding matching recordings. So in a vast number of instances when a previously released recording was reused on another release, a duplicate recording was created. I haven’t queried MB to see what proportion of recordings have AcoustIDs, but I am guessing that only a proportion actually have them.
So you do need to check the results from a Scan and make sure that Picard/MB got it right.
However, my guess (and it is just that) is that Scan will still be better at lookup because Scan is Recording based, and Lookup is Release based.
Which ever method you use, start by taking a good backup of your files and tuck that backup into a drawer. By the nature of Picard doing searches and changing tags you will get mistakes. There will be a percentage of bad matches that you may not catch initially and having an original backup to refer to will save a lot of headache.
But we don’t know if the original copy has the correct tags.
In that case, it’s unreliable.
However, you need to make a copy.
Then export the tags of the original version using Mp3Tag, tag the files, export the tags of the new version, and compare the two export files.