More Stupid Newbie Questions

(1) My newly organized music is going into a destination folder of C:\Users\Me\Music\ and the renaming path is %artist%\ and some other stuff after. When I process an album, even if the artist is already there (and I’ve made sure they’re identical) Picard just chucks the new album into a new, identically named artist folder. I didn’t even know Windows would let it do that, but it’s very annoying. How can I diagnose why this is happening?

(2) Can I somehow condition the acceptance of new values? I have a ton of JP/KR albums with romanized titles which I prefer. But it’s not immediately apparent to me how I can script this condition into the tagging. Is there a class of variables for existing tags? Ideally I would like to if/then/else a system where Picard updates the title for albums with Latin alphabets and uses existing titles for non-Latin alphabets.

(3) Similarly, is there a way to use an existing folder structure and apply it to the tag? Right now all my jazz albums are in \Jazz Guy\ folders and Picard wants to make a bunch of different folders for Jazz Guy Trio, Jazz Guy Quintet, Jazz Guy and His Orchestra. Scripting a cut off seems very tricky since I don’t want to cut off “Leader and Band” type artist credits for pop music, so I’m stuck replacing each artist’s tags as I process them. Is that the best I can do?

1a. Windows shouldn’t allow this. They may look identical, but probably they are not. They can have unicode characters that look very similar to the ascii ones. They can have spaces which are not actually ascii spaces.etc.

1b. You should use %albumartist% in your naming script not %artist%.

  1. Which settings have you checked in Options… / Metadata? Or is it just the Album titles you have trouble with?

There has been some discussion about giving scripts access to existing tags? And we should perhaps put the language / script values into variables also.

  1. I have the same issue - but there are simply too many variables here for this to be programmable / scriptable. At present you can either move / not move albums, and I have a suggestion open to allow you to rename the album directory (parts of the path with %albumtitle%) but leave the rest of the path the same so that the album directory gets changed if the Release name is changed in musicbrainz, but the album directory is never moved.
4 Likes

Do you have a dash in that artist? “-” or an apostrophe? Some kind of punctuation?

MusicBrainz likes using perfect Unicode in the database, but this can be misleading in many artists and is inconsistent. The rule has not been applied everywhere. It will lead to what looks like identical folders side by side. Can look confusing as it is hard to spot the difference.

In Picard, make sure OPTIONS \ METADATA \ Convert Unicode Punctuation characters to ASCII is ticked and you will get something more consistent.

I am guessing something like this is going on as that will be why you get all the new stuff going into new folders as previously you’ll have just typed from your keyboard. (Took me ages to work it out on my own collections)

(1) I don’t know what to say but they definitely are. For instance I just had a Pillows album in the wrong folder and when I ran my naming script on it, it sent the album to a different folder also called “Pillows” in the same directory with no apparent hidden spaces or marks.

It seems to happen fairly consistently whenever I try to send a misplaced album to an existing folder. Both the new folder and the original folder were created by Picard.

(2) I have translations clicked but that only helps me when the album has a pseudo-release in MB; many of them don’t. I realize the real answer is “contribute your own romaji/romaja to MB” but I was just hoping for a condition I could apply as an easy first pass. It would also be useful in other instances where I want to conditionally keep metadata, such as where my original release dates are more detailed than MB’s, so I could do a length comparison and keep my date if it has month/day, etc.

It just happened again. I processed a bunch of “Ma” albums but I failed to notice that one Marvin Gaye album didn’t get caught by clustering. When I scanned it and saved it a minute later (having gone through the exact same processing scripts as its fellows), it got sent to its own folder. Seems to happen every time an album isn’t done as part of a single batch.

image

All I can say is that I run Picard on Windows and I have never experienced this.

What is the file system on that disk?
Have you run Chkdsk /r on it?

P.S. Please also post your file naming script here.

It’s a completely standard W10 NTFS partition, nothing bespoke.

Have you run chkdsk /f on that disk? (Small chance that it is an NTFS issue.)

My naming script is incredibly basic:

%albumartist%/%originalyear% - %_album%/%artist% - %_album% - $num(%tracknumber%,2) - %_title%

I can post the script leading to _album and _title if you want but it’s just some pretty standard punctuation replacements/deletions and I’ve had the bug on albums with no real puncutation.

Edit: Request withdrawn.

$set(_album,$replace(%album%,/,-))

$set(_album,$replace(%_album%,\\,-))

$set(_album,$replace(%_album%,*,∗))

$set(_album,$replace(%_album%,?,))

$set(_album,$replace(%_album%,",''))

$set(_album,$replace(%_album%,:,ː))

$set(_album,$rreplace(%_album%,\\.\\.+,…))

$set(_album,$rreplace(%_album%,\([A-Za-z]\)\\.,\\1))

The only thing that might be unusual about this is the last one, I strip A.C.R.O.N.Y.M.S. as an idiosyncratic personal preference. But the Pillows album in question didn’t have any of those, and it’s screwing up on the albumartist level judging by the folders.

In file explorer, go to View / Options and on the View tab select “Show hidden file…” and clear all the Hide options. Then go into the duplicate directories and see if there is a desktop.ini file and see what the contents are. (The desktop.ini file can spoof the directory name.)

Also, I assume that these are real directories and not just an explorer glitch. Have you tried running a command windows and doing a dir /s - does that show duplicate folders?

1 Like

There must be a difference in the name, even if we don’t see them.

Or are those screenshots from Explorer and shows really filesystem folders, or is it some music players internal organization?

That is just weird. NTFS just won’t allow that. The OS has to be seeing something different.

Right click on each of the Marvin Gaye folders, select Properties, post the general pages up here.

There has to be something different. Or Pixies are messing with your system.

These are just regular old Explorer screenshots (EDIT: actually they’re from the left pane of Picard but they are there in Explorer too). I already moved/deleted the two examples I posted but I’ll post the next one that comes up.

1 Like

¯_(ツ)_/¯

I’ll keep both folders here for now in case anyone has any bright ideas. What happened here specifically is I did an en masse save of the Mai Yamane folder, realized I forgot to preserve my romaji tags for the 1980 and 1988 albums, restored those off my backup, ran the exact same scripts, and then saved again three minutes later, which gave them a separate folder.

2 Likes

This is beyond weird. I hope that PC is backed up as something is not right.

What happens if you COPY the “Mai Yamane” from the top one and try and rename the bottom one with that text pasted into the rename? Does it then acknowledge they are the same text?

OR add a “1” to the folder name, then remove it. Does it now complain of a clash of names?

I would follow @Sophist’s advice and run a disc check. Something has to be screwy with the file table to allow that. Or Picard is performing Black Magic

What happens if you COPY the “Mai Yamane” from the top one and try and rename the bottom one with that text pasted into the rename? Does it then acknowledge they are the same text?

It objects and asks to merge, so that’s good at least. To Picard’s credit this is a much less annoying failure mode than my previous go-to of mp3tag, where I would get directories ending in “.” that forced me to fix them via 7zip. :rofl:

OR add a “1” to the folder name, then remove it. Does it now complain of a clash of names?

I’m confused about this one and want to make sure before I test it; why would it complain about a clash after I added the “1”?

Nevermind, I figured out what you were asking. And interestingly this doesn’t generate any complaint; I can rename the upper folder to “Mai Yamane1” then back again and it doesn’t give the same objection.

So there must be some kind of weird invisible data going to the folder names that distinguishes them such that it won’t let me copy one to the other, but will let me add and subtract stuff to a single one without noticing anything amiss.