Stumbling over this thread…
I’ve noticed that sometimes my renamed files end with (1) (before the extension).
What does that mean and where does it come from?
Thanks,
F.
Generally that will be added by the operating system (Windows?) when trying to copy the file to the same name as an existing file.
I’m on Mac OS X and I honestly thought that MB Picard would in fact rename and not copy, rename and then delete the “old” file.
F.
Because Picard is usually used as an ID3 metadata tagger (using MB as a data source) not a file renamer, so when you edit the metadata of an .mp3 file (for example) it will have to re-create the file thus a copy/paste action happens.
1 Like
OK - so in fact it is using copy/rename/delete method.
I’ll have to just double check when I apply renaming to my albums, so that I can spot the “(1)” and remove it.
F
I don’t know, but it shouldn’t append (1) unless there is another file of the same name already in the same location?? (I’m on Windows though)
If your files are only doing it sometimes then there must be something else going on anyway. I would double check that you don’t have multiple files that are being matched to the same track in Picard, for instance, or genuine double ups of songs.
1 Like
Picard will append numbers if there are existing files with the same name already. I think there have been reports about this also happening on case insensitive file systems if the only change in the name is the casing, but I’ve not verfied this yet myself. I think we have a bug report for this somewhere, though.
Yes, it does rename. Although some have requested to do the copy and delete old file on success thing in order to avoid data corruption 
Picard is very much used to rename files, that’s one of its core functionalities.
2 Likes
No you’ve got the wrong end of the stick, if it was a straight up file renamer then it would simply rename the file not perform a copy/paste operation in order to modify metadata…
Picard is of course not a general purpose file renamer, but is specialized in handling audio files and rename them based on metadata. But you can very much use Picard to e.g. only rename files without saving any tags. No metadata saving involved in this case, just straight forward renaming as long as the file remains on the same file system (if not moving the file obviously involves copying it first).
Even if you enable tag saving, saving and moving/renaming are two distinct operations.
1 Like
That’s all good with me - as long as I know how it behaves, I can work with it.
But question: is there any setting to change, so that it won’t append (1) - i.e. it won’t first copy the file?
It will only append the “(1)” if a file with the same name already exists. That has nothing to do with copying the file, Picard does not create additional copies. If you see the same file name twice, one with “(1)” and one without this actually means you have two files that ended up with the same name. In this case check the two files if they are indeed identical or not. Maybe one just got matched to the wrong track. Or your file naming can result in multiple files ending up with the same name.
If you get the “(1)” appended without there being a file with the same name this would be a bug. Please report this on Loading... together with some details how to reproduce this.
2 Likes
Issue just created - I attached relevant screenshots as well.
Thanks!
2 Likes
Thanks for the issue report. I already answered here, but just to have this available as info for others: This case is indeed a bug. Problem seems to happen when the only change is in the casing, e.g. changing an uppercase character to lowercase. On macOS with case insensitive file system this seems to confuse the renaming code. But I have to investigate the actual root cause in more detail. It’s interesting the same issue seems not to be present on Windows.
6 Likes
For my issue, it’s now fixed with MB 2.5 (released today).
Thank!
F.
4 Likes
I’m new to Picard, so forgive me if this is out of place. When collating new or revising existing releases,
I use the following in my file naming script to detect Duplicate files in complete releases and move them to a separate tree:
$set(_DUPLICATES,$and($eq($matchedtracks(),%_totalalbumtracks%),$not($is_complete())))
$set(DUPLICATES,$if(%_DUPLICATES%,Duplicates))
…
and then at the base of the directory creation section:
$if(%_DUPLICATES%,%DUPLICATES%)
Obviously, a $matchedfiles() function would be better, but I’m no python coder…