I am working on a VDJ Tool aims to sanitize the VDJ Database and the playlist files to fix miscellaneous issues and other inaccuracies. One of the challenge is to tackle duplicate songs efficiently. Suppose you have a song located in 2 different folders:
c:\folder1\MyArtist - MyTitle.mp3
c:\folder2\MyArtist - MyTitle.mp3
Your VDJ Database created 2 distinct entries for MyArtist - MyTitle.mp3. Each entry has its own PlayCount and playlists might refer to both titles.
My questions is:
- Do you have lots of such duplicates entries?
Thanks in advance,
phenryll
c:\folder1\MyArtist - MyTitle.mp3
c:\folder2\MyArtist - MyTitle.mp3
Your VDJ Database created 2 distinct entries for MyArtist - MyTitle.mp3. Each entry has its own PlayCount and playlists might refer to both titles.
My questions is:
- Do you have lots of such duplicates entries?
Thanks in advance,
phenryll
发表时间 Sat 22 Sep 12 @ 3:29 pm
I sometimes have one or two duplicates as I often copy from my down loading computer to my gig machine.
It would be good if you could compare the ID3 tag and each database entry. then make sure if the track is used in a playlist it is kept, Then keep the one with the most recent modification of the comment if different from the ID3 tag, after that check the hot_cues are set & bit rate. if none of those are relevant keep the one with the highest play count.
It might be good to have an alert when a track is about to be deleted with and let the user select which one , but it is probably not a good idea for some of the enormous 100gb databases as it would take a lot of time to manage. So if that was added you would need to be able to opt out of it and go by the previous conditions.
So in hieratical order
It would be good if you could compare the ID3 tag and each database entry. then make sure if the track is used in a playlist it is kept, Then keep the one with the most recent modification of the comment if different from the ID3 tag, after that check the hot_cues are set & bit rate. if none of those are relevant keep the one with the highest play count.
It might be good to have an alert when a track is about to be deleted with and let the user select which one , but it is probably not a good idea for some of the enormous 100gb databases as it would take a lot of time to manage. So if that was added you would need to be able to opt out of it and go by the previous conditions.
So in hieratical order
- if used in a playlist
- most recent modification of the comment - if different from ID3tag
- most hot cues used
- highest bitrate
- highest playcount
发表时间 Sat 22 Sep 12 @ 9:52 pm
Thanks mate, that recommendation is very helpful :)
I'd like to provide a way to safely delete the "duplicated" file -- I mean the one that doesn't match your conditions. It would be a suggestion of course (no constraint) as anyone may not want to let a tool taking control.
I'd like to provide a way to safely delete the "duplicated" file -- I mean the one that doesn't match your conditions. It would be a suggestion of course (no constraint) as anyone may not want to let a tool taking control.
发表时间 Sun 23 Sep 12 @ 1:37 am
You could maybe weight all the conditions and use the track with the highest total score. But not sure if that is possible as I only know a little SQL in regards to database management.
Although if you are accessing the playlist file maybe you could keep the best track and update the filepath of the playlist entry.
Although if you are accessing the playlist file maybe you could keep the best track and update the filepath of the playlist entry.
发表时间 Sun 23 Sep 12 @ 1:56 am
Sure updating the FilePath is the fundamental feature other niceties are built upon. I wrote a tool 1.5 year ago that updated all playlist files with relevant path, all the VDJ FilePath and even the problematic FirstSeen FirstPlay based on the matching creation date time file (I wrote that stuff, well, 4 years ago). I'd like to incorporate those features in the richer, upcoming tool.
One another feature I am thinking of would be to include IO operations (moving, deleting, adding files/folders, etc and to keep the VDJ database / playlist files / tracklists.txt in sync. That would be awesome -- though challenging when it comes to make it 100% safe for everybody.
Another question: I tend to be very conservative when it comes VDJ. I keep all my playlists since 2005 and keep also my tracklist.txt since its creation (2007). Right before tracklists.txt, history.txt was used and my first entry was written in 2004 lol
It means tracklist.txt / history.txt are as relevant as playlist for comparison and other related stuff.
One another feature I am thinking of would be to include IO operations (moving, deleting, adding files/folders, etc and to keep the VDJ database / playlist files / tracklists.txt in sync. That would be awesome -- though challenging when it comes to make it 100% safe for everybody.
Another question: I tend to be very conservative when it comes VDJ. I keep all my playlists since 2005 and keep also my tracklist.txt since its creation (2007). Right before tracklists.txt, history.txt was used and my first entry was written in 2004 lol
It means tracklist.txt / history.txt are as relevant as playlist for comparison and other related stuff.
发表时间 Sun 23 Sep 12 @ 2:18 am
One very clean suggestion would be to create a folder where all those files can be moved, (The ones that could be deleted) with an option to restore if need be, (similar to the os Recycle Bin), this way the user can have them placed in an external drive and delete them once the user is satisfied and confident from that folder, or like You Do, save all of them for years and not delete anything, but at least you get to clean up the Duplicate problem without compremising any playlist, VF's ect. that contains the effected files....But most important thing here is that the highest quality file should be at the top of the list.. meaning if the count is larger on the 96 bit file then in a 320 file that exist, then migrate all info to the 320 file...
A compare option also would be good to hear for yourself...
There is a program that compares quality and other criteria that would be good for you to examine http://www.similarityapp.com/
Good Luck...
A compare option also would be good to hear for yourself...
There is a program that compares quality and other criteria that would be good for you to examine http://www.similarityapp.com/
Good Luck...
发表时间 Fri 28 Sep 12 @ 5:28 pm
Thanks for the piece of advice.
This is what I was thinking of: moving duplicates to a dedicated folder. It would be good to provide a mechanism to "merge" opitons of both files into the "best" file based on a best match (qualitywise): cues, comments, count, updated playlists, etc.
Since last week, I have been pondering on an extra feature: managing your music folders in such a way that any action you undertake on that folder/files it contains updates your VDJ database, playlists, tracklist accordingly. Renaming folder, moving files to another folder, deleting folders/files, creating a folder to place files into, etc. It means your VDJ stuff would always be in sync with your music folders. It requires lots of stuff whose a more advanced UI, but it that shot would be unique in the community -- as far as I known :)
I am gonna develop the "playlist updater".
This is what I was thinking of: moving duplicates to a dedicated folder. It would be good to provide a mechanism to "merge" opitons of both files into the "best" file based on a best match (qualitywise): cues, comments, count, updated playlists, etc.
Since last week, I have been pondering on an extra feature: managing your music folders in such a way that any action you undertake on that folder/files it contains updates your VDJ database, playlists, tracklist accordingly. Renaming folder, moving files to another folder, deleting folders/files, creating a folder to place files into, etc. It means your VDJ stuff would always be in sync with your music folders. It requires lots of stuff whose a more advanced UI, but it that shot would be unique in the community -- as far as I known :)
I am gonna develop the "playlist updater".
发表时间 Sat 29 Sep 12 @ 1:16 am