If a song is displayed as the "primary", don't show it as a "candidate match"

[lakecityransom]

The suggestion is good, assuming you already have a preferred list. The problem is, say you got tons of collections and have many dupes as there are many popular songs that are duplicated. However, these songs are not already in your library.

For this reason, it seems to me that that option is like post-exploration of music. I do not see much benefit from it. Sure, you can purge duplicate results from music you know you already have, but still there are going to be a lot of duplicates of music you do not already have.

[Admin]

lakecityransom
in next we implement folder grouping mechanism, you can mark 9 different groups, only files from different groups are compared, never in same.

[lakecityransom]

Well that is better, I just can't see why you would not code it in a manner in which the deletion candidates are purged from the list 1 by 1 and it eliminates deletion candidates further down the list that were inverse matches and such. It would sort the problem out?

As I said, I can use Similarity in its current state if I delete single files and get a refreshed list. It prevents me from deleting the inverse relationships, in other words, deleting both files.

Nonetheless, I applaud your efforts.

[lakecityransom]

Sorry I did not notice it was released, but when it comes to a majority of my stuff, I do not have a 'keep' version yet and I have hundreds upon hundreds of folders that have duplicates between them. For this reason a grouping function will not help.

[lakecityransom]

The grouping function is nice but it is not very useful when you have many, many folders of files and/or are not sure if you want either group of files, so you cannot reduce the number of folders. You would have to run many compares. This leaves you with non-grouped searching and inverse relationship issues. This is why I feel that the delete function should take out 1 deletion selection at a time from the results and check if subsequent deletion selections still exist on the results list after refreshing the list.

For example if you choose to keep "keepme" base group and deleted "deleteme" candidate, further down the list inverse base group "deleteme" will disappear along with "keepme" as candidate. Thus, if you were to choose to keep "keepme", but accidently choose to delete "keepme" further down the list, you can rest assured that your second deletion will be omitted. In effect, you ensure that 1 copy of the file must exist. This logic behind this is that you are always choosing to keep 1 file out of every group base. Therefore, if the list is reprocessed 1 deletion at a time, it must reflect that you intend on keeping that 1 file, because all inverse group bases that hold "keepme" as a candidate disappear.

Again, this can already be done by users if they simply delete one file at a time. Inverse relationships disappear as the list is updated. The problem is selecting a bunch of files deletes them all. Single file deletion is too slow, however.

Maybe I am crazy, but this seems foolproof? Screenshot to explain:

[Admin]

lakecityransom
thanks for your comment,
in future we add priority of groups in "rearrange" and "automark" dialog.

[lakecityransom]

Hi again, I made a mistake in the example. The right example should not choose 2 in one of the group bases and choose it for deletion instead. I'm guessing you understood though.

The thing I'm trying to get across is that if you simply have a bunch of songs to look through, the grouping function is not very helpful. You have no preferred group of folders and there are many folders. Maybe for example you took 10 peoples collections and put them altogether. There will be many duplicates but the grouping function will not work well unless you run it 10 times.

The priority of groups will help when using it though.

[lakecityransom]

Due to the recent update, I have found a way to make this work the way I explained without coding it in. However, it should only be used if you have a high % match and are certain everything will be deleted. The following explanation would allow you to go through a large collection of songs you plan on listening to and deciding what you will and will not keep. Since you have no preference and no folders for the group function (or too many folders), this is the way to delete all duplicates without accidentally deleting all of them:

Rearrange your group bases (the bold files that candidates go under) to whatever you prefer. Most likely size or bitrate. Next, get a macro recorder program and loop the keyboard commands "home" "down arrow" "delete". The result is that ONLY candidates can ever be deleted from the results. Home will always position the selected row at the very top of the list, and the 2nd entry will always be a candidate until all candidates are gone and the group base is all that remains, at which point it is cleared from the list automatically. This process is important, because similarity constantly updates the list, deleting matches to that file that was deleted and thus avoiding inverse relationships. This means that it will churn through the group bases 1 by 1 automatically, making the list refresh and guaranteeing that you do not delete all copies of a file, without using the grouping function.

The only problem that persists is when I have several dozen preferred folders, for which the group function will work. Yet, the results will be mixed as to what folders serve as the group bases, so you couldn't automate that process. However, as soon as the development team lets you give folder preferences to group bases, this will be possible.