Feature Request: Track Relations

Post a reply

Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Feature Request: Track Relations

Re: Feature Request: Track Relations

by Peke » Fri Aug 11, 2017 5:24 pm

Hi,
I agree with MMFrLife and would also add that combination of RegExp Find & Replace and Advanced Duplicate Find & Fix 3.8.2 should get you closer or at least narrow what else is missing. Not sure but Magic Nodes could also help.

Re: Feature Request: Track Relations

by MMFrLife » Sat Aug 05, 2017 6:13 am

Sounds awesome. I've thought about that sort of thing myself. Although, it sounds too complex for the devs to bother with it natively (in favor
of other things). Maybe an add-on if it is possible to do so. But once it's put into the realm of the add-on it becomes a volunteer thing,
thus making it difficult to materialize. But hey, there are some situations where we all love being proven wrong. :)

Feature Request: Track Relations

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?

Top