You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is such a "library" at all feasible for enhancing the accuracy of the search algorithm?
If my understanding of the operational aspects is correct —
Currently, listFix() runs through a given directory of audio files trying to locate the closest match for an original track with a broken relationship within a playlist. Without expounding the reasons why the relationship with the original track was ultimately broken, it does matter a great deal now how the (automatic) search to locate the best match, is accomplished. This is where the search algorithm utilised by listFix() enters the scene, and it does appear as if the current algorithm is not up to scratch.
@Borewit has already indicated that he is in agreement that the current listFix() auto-search algorithm needs an overhaul. Any proposals about how this algorithm should be best formulated, are invited for discussion here. That is, how should such a search be stuctured for the best possible outcome?
The aforesaid also introduces the following question, which is also here up for discussion:
When executing a search for matching tracks in the Playlist Editor, would, or would it not, improve the results of search, for listFix() to have its own "library"* — established on the default input directories, replete with audio tags?
[*Compiled from the default directories, possibility making use of the audio-tag-analyzer?]
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is such a "library" at all feasible for enhancing the accuracy of the search algorithm?
If my understanding of the operational aspects is correct —
Currently, listFix() runs through a given directory of audio files trying to locate the closest match for an original track with a broken relationship within a playlist. Without expounding the reasons why the relationship with the original track was ultimately broken, it does matter a great deal now how the (automatic) search to locate the best match, is accomplished. This is where the search algorithm utilised by listFix() enters the scene, and it does appear as if the current algorithm is not up to scratch.
@Borewit has already indicated that he is in agreement that the current listFix() auto-search algorithm needs an overhaul. Any proposals about how this algorithm should be best formulated, are invited for discussion here. That is, how should such a search be stuctured for the best possible outcome?
The aforesaid also introduces the following question, which is also here up for discussion:
When executing a search for matching tracks in the Playlist Editor, would, or would it not, improve the results of search, for listFix() to have its own "library"* — established on the default input directories, replete with audio tags?
[*Compiled from the default directories, possibility making use of the audio-tag-analyzer?]
Beta Was this translation helpful? Give feedback.
All reactions