I verified, my Audio Folder rule is currently set to the MC default of [Artist]\[Album]\.
Okay, so we know that is what we should use in the RM&CF function. It may cause some issues, but it is going to be as accurate as we can, because it sounds like your metadata isn't consistent.
When you say "directory rule"
I was referring to the "directory rule" in the Rename, Move & Copy Files function, which is active when the "Directories" checkbox is ticked. The "Base Path" I referred to is also part of the RM&CF function. We are using the RM&CF function to fix the special characters in the path and file names. Nothing else at the moment.
If your directory rule has always been the default, and that is "[Artist]\[Album]\", then that is what we use to try to fix your Library.
I'm a bit confused by your above comment regarding El Huracan. First of all, where do you see the Album Artist (auto) and the other fields you talk about?
I added those fields to the View I am using for testing. You can do that by right-clicking anywhere on the column heading (i.e. on the [Name] column and selecting a new field to add as a column - you can drag the columns left and right to put them in a sequence you want to see). I wanted to look at them to see what we should use for the "Directory Rule". Now we know, we leave it at "[Artist]\[Album]\".
From what I can see in MC El Huracan IS under the Artist "Alfredo.... ".
But under [Album Artist] "El Húracan", and hence [Album Artist (auto)] is "El Húracan".
Although I do have 10 different versions of El Huracan from different Albums, different orchestras etc., each using different naming conventions for Album, Album Artist etc... it's a mess!! My guess it this is a long term project of manual fixing as I go. No hurry on this. Just need library & playlists to work again, then I can clean up.
Yes, by the sound of it there is a lot to do. I can't really help with fixing all your metadata, or recommending how to handle composers, for example, as there are many ways to do it in MC, and it really comes down to personal preference.
There are quite a few threads on handling metadata for orchestral and classical music, and where to get the metadata from. That is a task for the future.
Yes, only Working with Windows7 right now. <snip> I wish I wasn't doing all the Library modifications there, because it's such a pain. But I guess I'm already halfway committed.
If that external drive has original version of the files, and I'm sure you still have the Library Backup from Step 11 in post 15 above, or one after the transfer process in post 30,
so you could move to the Windows 10 PC. At worst, the original files are on the Mac, with a Library Backup, and everything we have done is documented in this thread, so you haven't lost anything. That is up to you. I assume that the W10 PC is faster.
Also, the only actual fixing we have done after your transfer process is some Option Settings and the the RM&CF function, I think.
The (1) suffix was already in Finder on the MAC. So it was also there in Explorer. What happened is when I accidentally did the Rename "[Track #] - [Name]" to clean up the special characters, neither of us realized that it would remove the (1) from MC making those files unreadable.
I realised, and expected, the " (1)" suffix to be removed in MC, and also on the file itself, as shown in Windows Explorer. Even though MC is showing the files as missing, and hence unplayable, Windows seems to be able to find them no problem. MC uses Windows functions to rename files, so I expected the RM&CF function to both update MC and rename the files.
I couldn't test for this, as my file system isn't broken, and the sample files you shared were always playable after they were imported.
It sounds like the RM&CF function run to update the file name did not update Windows, and hence left the " (1)" suffix on those files.
You said:
Update To Post:
Regarding the Filenames ending in (1) in Explorer but not in MC: I used RM&CM to change one filename in MC and it played.
So I believed that my assumption was correct, and the file would be renamed in Windows.
UPDATE:I see you have reversed the removal of the suffix, and now removed the suffix in MC and Explorer. Good.
So did you reverse the file renaming on all files, or just the ones with the suffix. I guess it doesn't matter too much, because if you try to rename files to the name they already have, MC will just not make changes. See attached image for how the RM&CF function should look.
BE CAREFUL to select and test just a few files. If the change looks wrong, Ctrl+Z will undo the change.
Select and test with files that have special characters in the path and file name.
Make sure you refresh all MC and Explorer views when yu check the result. Both of them sometimes don't update their views quickly.Check in Explorer after changing just a few files, to see they have been renamed in Windows (use the "On Disk (external)" function).
You need to confirm that:
The file names and paths in MC match the file names and paths in Explorer.
That MC doesn't show the files as missing.
That the files are playable.
That when you try to edit the [Filename (path)] or [filename (name)] field in a View in MC, using the F2 function or right-click and selecting "Rename", that the special characters look correct, without the gap.
You could also add the "Playlists" column to your View, if you wish, and check if the test files still have the names of any Playlists they belong to recorded in there.
By the way, I suspect that the RM&CF function will say "No Change" on some of your test files, and won't fix the problem. If that is the case was will try a slightly different idea. Hopefully though we can whittle down the number of files to deal with, step by step.
Sorry for my very long posts. But the devil is in the detail.