I'm just going to address the duplicates issue here.
I find the best way of processing duplicates is to set up a specific viewscheme for the purpose. I set up a series of Search List panes in sequence which narrow the duplicates down based on what fields have duplicate information.
The first Search List pane contains the basic elements that would identify 2 files as duplicates. I put the most restrictive one at the top, then copy/paste into subsequent ones and remove restrictions. Here's a concrete example:
~dup=[Album],[Artist],[Name],[Track #],[Album Artist /(auto/)],[Album Type],[Year],[Genre]
Selecting that search shows all files that have duplicate album, artist, track #, album type, year and genre information.
Another possible basic one, especially if you think you have actual files which are duplicates would be:
~dup=[File Type],[File Size],[Compression],[Bitrate],[Duration]
That would give you a list of files that are very likely to be duplicate files. I don't use [duration] in the first one because you might have recordings where there is a one second difference but they are the exact same track. As you can see in the image below, I use these in series, first restricting by tags, then by file info.
You can also infer what I meant by removing restrictions in subsequent searches: The second search in col. 1 does not check that Album Type is the same, because album type is based on the on-disk location of the files. If you have one track from a compilation in a folder on its own, MC will report it as part of a single-artist album, and if it has a track # of "1", MC will tell you that the album is complete.
The next thing to do is to add more panes with searches for fields that do NOT have duplicate information. For example, if you have dupes of a track, but only one of them has an artist biography, you may want to take that into consideration before deleting one of them. When you find tracks like that you have 2 choices: Copy the info you want into the file you want to keep, or delete the one that doesn't have that info.
How do you decide? Well I base it on further hierarchies of things like, file type (I always try to keep mp3 above other compressed file types), bitrate, compression type (i.e., VBR vs CBR), and date imported - I like the fact that I have tracks in my library dating back to 2003, so I try to keep them as well. (You can actually tell MC to point an old library record at a new file, so if you get a higher quality version you can use it to replace your old one).
Finally, I use another search list pane to filter the final list of duplicates so it only presents one of each for me to delete. Here's an example:
~sort=[Album],[Artist],[Name],[Bitrate] ~nodup=[Album],[Artist],[Name]
This sorts the list into duplicate groups, with bitrate as the sorting for files withing each group, and then removes every dupe apart from the first one in the group. Because it's been sorted by bitrate, it means the dupe that is still visible is the lowest bitrate copy and can be deleted. If you have more than 2 copys of a file in each group, you will have to refresh the list to see the next lowest bitrate file to delete.
One thing you might want to consider doing is not actually deleting files. A tip Marko gave me years ago which I still use, is to create a playlist (not a smart one) called 'Delete'. Then you customise the View Scheme I've just described above by setting the file display rules to NOT show any files in that playlist. After you have narrowed down your list of dupes to the ones you want to delete, you can just select them all and send them to that playlist. When you refresh after doing that, those files will no longer be used to determine duplicates in the scheme.
It means you can deal with them later and you don't have to panic about deleting things: you can just do the work and when you are absolutely sure you don't need the files you can Sift+Delete them in the playlist and you'll get the option to send them to the recycle bin.
