[F] Format Value "_DIRECTORY" Bug

So I've found a bug when working with audiobooks.

Initial explanation:
Folder1: ItemA - ItemB
Folder2: ItemA - ItemB - ItemC
Folder3: AABB
Folder4: AABBCC

When using Format Value "_DIRECTORY" to modify the directory from:
ItemA - ItemB\File1.mp3
...then any file in Folder2 is affected. The program seems to think that anything anything in Folder2 has now been changed. The program now thinks that Folder2 is:
RenamedA - ItemC\FileX.mp3, although no modifications to files in this directory, or the directory itself. Since that's the case, the files are now inaccessible because the program is looking in the wrong place. It shouldn't be modifying Folder2 either way.

Also, just to verify, I checked with Folder3 & Folder4 and changing Folder3 from AABB to Renamed2 makes the program think Folder4 is now Renamed2CC even though no files or folders should have change.

I tried this with 'Tag to Filename' and there's no problems.
The problem only occurs when using the 'Format Value' option in Actions.
Personally I'm using: Format Value "_DIRECTORY" and %artist% - %album% - %title% or similar, but with some playing around I found any use of the Format Value action does this, that's how I discovered that no spaces are required.

I hope I've made the bug clear enough. It's a little annoying, but I haven't run into it a huge amount. If you need a better explanation please post and I'll try and explain further.

I am not sure what all this is about.
The convert>Tag-filename function aims at the filename of an individual file.
An action of the type "Format value" for _DIRECTORY aims at a folder with a number of files in it.
So an action of the type "Format value" with "%artist% - %album% - %title%" is puzzling to me as it moves all the files in the original folder around into a folder that has the name of the first title.

I just renamed a couple of folders and I could not see that MP3tag suddenly also treats folders that do not match the original pattern.

I disagree tag to filename is for just files directly. If the information is uniform (generally the album and artist are) then you just do something like %artist% - %album%\%title% to edit the directory as needed. I actually did %artist% - %album%\%artist% - %album% - %title% a lot before I wrote actions.

I don't use the tag to filename option because I have setup actions to fix audiobook file names. I convert the tag to something that is uniform Title is the book title and something like a number or chapter and then number, or disk # track #, then author is author and album is generally the series. because of the title being not quite as uniform as everything using the 'tag to filename' option isn't really an option because it would put every file in a different folder.

I have a regex running in my Format Value so that it takes out all numbers and makes cleaning it easier. Format Value "_DIRECTORY" and %artist% - %album% - $regexp(%title%, \d+,) and then an additional script to week out something like chapter/disk/disc/track or whatever else may popup when I'm cleaning the folders. I also have a script to rename the files inside the action as well, it's why I use the format value, so I have multiple actions setup. I only named a single file in the example because that's all that was needed. Before I got the script working right (with some help on the forum) I used to use tag to file name and do author - series ##, and then manually edit the book name in the end since most audiobooks have multiple files. This took... a long time comparatively.

However, that doesn't matter. What matters, is there a bug if you work with multiple folders open. It shouldn't be happening at all. I used Format Value "_DIRECTORY" without the regex in there, just renaming the files flat out with say artist. If I had 2 mp3 files, one in AABB and one in AABBCC, if I only formatted the AABB to %artist% then it renamed both in the program, though it didn't actually rename them on my computer.

If there's 2 (or more) folders inside the audiobook directory and I'm working with them in a series, so I don't have to close one and open the next, this can happen. It has generally happened when I have a folder that has author - series (but no series number) and another that has author - series ## - book. That's when I first noticed it happening and screwing up with my open folders I was working with. It only happens when 2 files with folders of similar file names as explained above. AABB and AABBCC or AA BB and AA BB CC if you rename the first of either, mp3tags thinks it renames both folders.

I tested this pretty extensively once I found it. It's really not that hard to reproduce, that's why I showed both examples. I'm running version 2.81, and it was happening in 2.79? (I think that was the version) as well. I can add screenshots as needed.

I've added two screenshots as examples.

The before shot:

I put a red line under the existing folder name of the file I'm not working with. Also note I have the artist/album/title named different to make it more obvious. Only a single action was performed on the highlighted file, as shown in the screenshot.

The after shot:

Again, I put a red line under the apparent new folder name on the second file, you can see that the second file folder has (apparently) been renamed too, the 'A1' is only in the first file's metadata, so there's no way it could be in the second file's rename no matter how you look at it. And, when clicking on the file, it's no longer available, as it didn't actually move and is still in it's original folder of 'ABC' even though MP3tag seems to think it was somehow moved.

I know I'm not that great at explaining things, that's why I thought it was better just to attach the screenshots as proof. Again, only 1 action was performed and only on the top file. The mp3's are in 2 different folders.

Just to get this clear:
Actions of the type "Format value" for _FILENAME and the Convert >Tag-Filename function are, if the format string is the same, absolutely identical.

If you apply a action of the type "Format value" to _DIRECTORY, then this has an equivalent in the function Convert>Tag-Tag.

I just tried and tried and I cannot reproduce the behaviour you described. I even renamed some files and moved them to folders with names from your example - and no: I cannot reproduce it.

If I rename one folder then all the files in that folder move to the new folder - but only those. There is not wildcard mechanism.

If I want to move a subset of files from a single folder to a new folder structure with several folders then I have to rename the filename including a part that describes the new path. This is the preferred method to create a new folder structure e.g. if the new files are all in one folder and should be distirbuted to several other folders.

If you want to treat individual files then you have to rename the filename and not the folder.
If you want to rename the container folder as a whole then rename the folder (and take all the included files with you). This is the preferred method if the folder structure is already OK only the individual names of the folders are not quite right yet.

That's very strange. I even moved it to a single folder under me E: drive to make sure it wasn't something funny with the folders (since mine have a . before them to make it easier to sort) and it still happened. I'm not sure why it's not reproducible.

Just to be clear (you probably understand, since the screenshot should reflect it) 2 files (I use mp3, but it doesn't seem to matter as it happened with m4a/b files too). One in say e:\ab\aa\ and one in e:\ab\aa1\ . I add the contents of e:\ab\ which includes both the 'aa' and 'aa1' folder (and any mp3 files beneath. If I change anything in the folder aa with format value: _directory, then the issue occurs and the aa1 directory is (falsely) affected. I then have to refresh the base directory, or add aa1 directly, because the program doesn't think it's in the correct place. This originally happened with longer files, but I simplified it in my screenshot and examples, as it happened with anything.

Okay, well I'll have to try on my laptop as a separate test machine to see if the problem occurs there - this is happening on my desktop. It's really odd that it can't be reproduced. Maybe there's a setting/option somewhere I've changed that makes the difference? I don't remember making many changes to the options, but I've had mp3tag installed for a long time, so I can't be sure. Perhaps it's something involved with windows version for some reason (Win7 x64)?

I mentioned previously it wasn't a huge issue, it's only happened to me (while working with files) about a dozen times in the course of 2000+folders but I thought I'd report it, since I figured it was a bug. When I do test it on my laptop (probably later today or tomorrow) I'll report what I find.

Your examples do not show a . in front of the folder name.
Also, AFAIK it is not possible to create foldername with a . as starting character.
So I think it would be easier to see the actual examples and not the constructed ones.

I tried it with a an Artist name .A2 and see what you noted.
Yet, trying to create a similar folder name with the windows explorer leads to the rather confusing error message "Please enter a file name".

In Windows Explorer, BTW, the folder does not get renamed. So what you try is not along the standards.

Why MP3tag reacts like that I don't know. But when you use conforming folder names, you do not see that behaviour. It is a very philosophical question whether a program should act correct under incorrect conditions or not.

Sorry, what I mean the top folders, not the ones I was working with.

If you look at the folders in the images I posted, 2 folders have a period in front of them. IE e:\AB.unorg.missing\AA (the .unorg and .missing are the folders I meant.) They're not actually the folders with the mp3 files. Just for sorting purposes. I have an .org and .unorg folder for stuff organized and unorganized respectively, makes it easier to insure I've checked stuff. But, as I mentioned already, this isn't the problem because I tried it in a different folder (E:\AA\ and E:\AA1\ and it still did it)

Making folders with a leading period actually easy to do in windows. When making a folder that you want a period in front of, put a period at the end too when naming it. IE ".folder." will make a folder called ".folder" or just having a second period works fine, IE ".folder.1" will make a folder labeled ".folder.1" it's a quirk I use to make sorting easier, because it sorts the . folders above anything starting with a character or number. I also hate some of the other options (#/,/;/etc.)and the period is (almost) invisible.

None of the actual mp3 folders I'm working with this have the period in front of them - I've not tried to format them like that in mp3tag, but in other programs it tends to throw errors depending on the program.

I can see that as soon as there is a dot as leading character in a folder name, MP3tag behaves like this.
So creating folder names with a quirk, seeing that other programs act up and assuming that MP3tag should behave indifferent to at least non standard folder names leads to our dialogue.

I am not supposed to judge whether something is a bug or not. So right now we have found out that the behavour is due to the dot in front of the folder name.
As soon as you do not use that "quirk" any more, MP3tag behaves the way it should.

As I said in my last post, I did a test on my root folder (E:) with
to verify that it wasn't the odd foldernames that were causing the problem.

When I used "Format value" for _DIRECTORY and only E:\AA\example.mp3 highlighted, I put several things in. %Artist% or a simple string, no matter what I tried it always caused a change in the files within the folder NOT highlighted but only in mp3tag, not the filesystem.

As of a few minutes ago, I have also tested this on a fresh install on my laptop (Windows 10 x64). In the very first test of the brand new install, the 2 files were named as:


... the same thing happened. It's not because of the folders with a leading dot. It happens with any folder that is a partial of the second folder

(C:\Temp\AA vs C:\Temp\AA1) or
(C:\Temp\11 vs C:\Temp\112)
(C:\Temp\Test vs C:\Temp\Test two)
(C:\Temp\Test vs C:\Temp\Test 2)

I did 6 variations of the folder naming on my laptop just to make sure using using multiple variations as the example folders show above. Everyone did the exact same thing I've already explained several times. If I renamed AA (in the case of the first one)using "Format value" for _DIRECTORY and the String BB, AA1 was changed to BB1, along with the folder that was intentionally changed. This only in the program, No change actually occurred in the filesystem.

Ed: Spelling\Emphasis\Clear up wording.

I can reproduce this behaviour.
It only happens if

  1. The directory or any directory above

    a ) has a leading dot in its name or
    b ) had a leading dot in its name and was renamed without this dot afterwards.

  2. The afflicted directories are in the same parent-directory

  3. The name of the directory that is not intended to treat starts with name of the directory to treat.

There is no difference whether the directory-name with the leading dot was created with the explorer and the described trick to overcome the missing feature of the explorer or ordinary with the DOS-command mkdir in the console window.

It is not forbidden in Windows to name directories with a leading dot. It is even done by the system itself and a lot of programs for their application directories and even MP3tag is able to name them like this with actions.

So I think we have to call this behaviour a bug (which accurs under very special conditions).

Thanks for the detailed investigation!

This issue should have been fixed now with the latest Development Build Mp3tag v2.81b.

Kind regards
– Florian

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.