I thought I would just provide two additional thoughts to my previous post:
Regarding Playlist Tree Nested Query Function:
I believe I've solved the overinclusiveness problem I mentioned in my original post. The following code could be used under Playlist Tree > Format (while keeping the other fields the same as in my original post):
@query<'@format<$ifgreater(%_itemcount%,1,,@hidden)>' %artist% - %title%;@database;title HAS %title% AND artist HAS %artist%;'%artist% - %title%'>
This code is a slight tweak from my earlier code, which simply hides items that only contain a single match (i.e. non-duplicative files). Within Playlist Tree, you can go track-by-track or load the entire list (root) into the playlist. From the playlist, I usually just do a Ctrl+F (or sort by some distinguishing factor) and select the duplicate files I wish to delete.
An alternative, less CPU-intense, non-nested query function:
Upon figuring out how to use the %_itemcount% tag, I came up with an alternative way of finding "duplicate" files. In playlist tree, search your entire database and use the following format:
%artist%|'@format<$ifgreater(%_itemcount%,1,,@hidden)>' %title%|%album%
This is a standard track-listing under Playlist Tree that simply sorts by artist, then title, then album, but only reports tracks with more than one match for a track (potentially duplicate tracks). The "'@format<..." portion of the code "hides" all tracks with a single item (i.e. non-duplicates). You could go a step further and move the @format portion to the %album% portion, thus finding only songs that have the exact same artist, title, and album.
The downside to this method over a nested query is that it will only find duplicate files that have the exact same %artist% and %title% fields, which happens to be an unfortunate problem since, in many cases, the duplicate files we are seeking to eliminate are poorly tagged. Moreover, even well-tagged variations will not match. For instance, "Bruce Springsteen - Born to Run" will not match with "Bruce Springsteen - Born to Run (Live)." I'm sure there are ways around this problem, but I am still in the early stages of using this method. Until then, realize that this method is underinclusive.
Quick edit: To roughly quantify "less CPU-intense," it took about a minute to execute this code on my entire library of ~50,000 files.