by TIV73 » Fri Aug 04, 2017 4:41 pm
Hi everybody,
Mediamonkey has a function to manage duplicates which, in version 4, works reasonably well. Without really testing it, I assume this is a strictly mechanical comparison, i.e. a hash is generated for each file and if two hashes match, a duplicate is found. While this is fine if two files are exact duplicates, it's less ideal if two tracks have identical content without being exactly the same, e.g. if one track cuts out a second sooner. In this case both tracks can be, for all intents and purposes, considered duplicates, but mediamonkey wouldn't identify them as such.
What about a more "involved" way to handle relations between tracks? I only spoke about duplicate handling above, but I was thinking about a generic way of indicating the relationships between two or more files, e.g. file A is a live recording of file B, file C is an unplugged version of file D, files E and F are both duplicates of file D and so on. The idea behind this is to give users with libraries containing several ten thousand songs in there library additional tools to organize their collection.
Truth be told, I can see that this is not something every user will need and therefore might be an optional feature, which makes it possibly more suited to be an addon, not a core feature. The problem I see with this being an addon is that I can't think of a practical way for an addon to store the needed data for that.
There is a good possibility that a single track can have multiple relations, which means that an addon could either use several custom fields, write all information into a single field and then parse it every time the data is needed, write all of it in the config file or store the data in a separate file somewhere in the file system. While all of the solutions above are (probably) technically doable, none of them seems to be really ideal.
What are your thoughts about this?
Hi everybody,
Mediamonkey has a function to manage duplicates which, in version 4, works reasonably well. Without really testing it, I assume this is a strictly mechanical comparison, i.e. a hash is generated for each file and if two hashes match, a duplicate is found. While this is fine if two files are exact duplicates, it's less ideal if two tracks have identical content without being exactly the same, e.g. if one track cuts out a second sooner. In this case both tracks can be, for all intents and purposes, considered duplicates, but mediamonkey wouldn't identify them as such.
What about a more "involved" way to handle relations between tracks? I only spoke about duplicate handling above, but I was thinking about a generic way of indicating the relationships between two or more files, e.g. file A is a live recording of file B, file C is an unplugged version of file D, files E and F are both duplicates of file D and so on. The idea behind this is to give users with libraries containing several ten thousand songs in there library additional tools to organize their collection.
Truth be told, I can see that this is not something every user will need and therefore might be an optional feature, which makes it possibly more suited to be an addon, not a core feature. The problem I see with this being an addon is that I can't think of a practical way for an addon to store the needed data for that.
There is a good possibility that a single track can have multiple relations, which means that an addon could either use several custom fields, write all information into a single field and then parse it every time the data is needed, write all of it in the config file or store the data in a separate file somewhere in the file system. While all of the solutions above are (probably) technically doable, none of them seems to be really ideal.
What are your thoughts about this?
