Tweet
The problem in DAP that occurs when one must move one's collection to another hardrive, rename folders, or otherwise reorganize a prize and painstakingly maintained collection centers on the Locate Missing Files function under Collection in the MMC. While this feature works admirably for a few files or even a few albums, there is a quirk whereby any files that have the exact same filename (despite being different songs in seperate folders and having different sizes) will point to the first instance of that filename DAP encounters in its search.
Thus, if you use a standard filename protocol such as Tr# - Artist - Title, and have a large collection... you will find that your 6 - The Doors - Roadhouse Blues for example under "In Concert" will now point to the corresponding file in "Best of the Doors." Once both songs in the MMC point to the same track, it is impossible to force the correct association of one without skewing the other... the only solution I have found that works is to remove one file and add it again. When adding files, this quirk doesn't surface, and MMC is perfectly able to differentiate between songs with the same name that are in seperate folders. But who wants to lose all that hard earned MMC data like "times played," "date added," and especially "volume boost."
This thread addresses this problem without solution as well.
OKAY. While I have coped with this issue by taking care to name files more specifically. (i.e. Tr# - Album - Title at the least) There are some files that have been in my MMC for years and were poorly named as Artist - Title, or some such thing and as you can surmise with as many as 10 versions of some popular songs, this is a severe headache when trying to move the music to an external hardrive.
SO, my WISH (finally) is that in future versions of DAP, we can edit the filename LOCATION directly with the edit tag function. This is currently under the details tab, but is not editable. Furthermore, it would be nice if the locate missing files feature was a tad bit smarter, and could take file size into account. Editing the filename would even allow the changing of obsolete filenames without losing the MMC's data. That would solve the problem entirely.
Thanx Spoon. Sorry to bother you, I know you're still hard at work on DMC r12, but when DAP r3 surfaces, it would be cool if this was encorporated. What do the rest of you lot think? Or am I, DBample and Donny the only ones who've had this problem?
Thus, if you use a standard filename protocol such as Tr# - Artist - Title, and have a large collection... you will find that your 6 - The Doors - Roadhouse Blues for example under "In Concert" will now point to the corresponding file in "Best of the Doors." Once both songs in the MMC point to the same track, it is impossible to force the correct association of one without skewing the other... the only solution I have found that works is to remove one file and add it again. When adding files, this quirk doesn't surface, and MMC is perfectly able to differentiate between songs with the same name that are in seperate folders. But who wants to lose all that hard earned MMC data like "times played," "date added," and especially "volume boost."
This thread addresses this problem without solution as well.
OKAY. While I have coped with this issue by taking care to name files more specifically. (i.e. Tr# - Album - Title at the least) There are some files that have been in my MMC for years and were poorly named as Artist - Title, or some such thing and as you can surmise with as many as 10 versions of some popular songs, this is a severe headache when trying to move the music to an external hardrive.
SO, my WISH (finally) is that in future versions of DAP, we can edit the filename LOCATION directly with the edit tag function. This is currently under the details tab, but is not editable. Furthermore, it would be nice if the locate missing files feature was a tad bit smarter, and could take file size into account. Editing the filename would even allow the changing of obsolete filenames without losing the MMC's data. That would solve the problem entirely.
Thanx Spoon. Sorry to bother you, I know you're still hard at work on DMC r12, but when DAP r3 surfaces, it would be cool if this was encorporated. What do the rest of you lot think? Or am I, DBample and Donny the only ones who've had this problem?
Comment