Having trouble creating album subfolders


#1

I am using the following to create album subfolders under the artist when converting tags to filenames.

Normally, this works fine: %album%\%artist% - %album% - %track% - %title%

However, it seems that if the number of nested folders will become more than 4, it will not create an album subfolder under the artist folder. It puts it into the same folder AS the artist folder.

for example, if the files are in :

"D:\Temp\Artist" the conversion works OK and I wind up with:
"D:\Temp\Artist\Album"

if the files are in:

"D:\Temp\Collection\Part1\Artist" the conversion does put the files in a folder named after the album title, but not under the artist and I wind up with:
"D:\Temp\Collection\Part1\Album"

I don't think this is a Windows limitation because if I do it manually I don't get any errors.

I can move the files somewhere else to perform the conversion, but can anyone tell me why this is happening?

Thanks!


#2

I take that back - I just moved one of these folders to the root and I'm having the same problem.
I have no idea what's wrong and am looking into it further now.


#3

It appears to be something with the total number of characters in the path. I took the artist folder with the files in it and moved it up one level and now it works... odd.


#4

Check the data in the tag-fields, maybe there is a backslash or multiple dots or such things, which can be interpreted as part of the filepath and relevant to the filesystem.

DD.20120206.2142.CET


#5

Yeah I looked for that, definitely not the case. Thanks though.
If I pull one of the artist folders out and move it to the root, it works fine.
I think it has to be something with the number of characters or subfolders.

"D:\Temp\Collection\Part XX\Artist" fails to create "D:\Temp\Collection\Part XX\Artist\Album".
"D:\Artist" is OK.

I'm going to reboot for kicks.


#6

There is a limit for the entire length of the filepath.
259 chars is the maximum length for the entire filepath in the NTFS filesystem.

We had already this discussion here in the forum some time ago.
Repeatingly some users stumble over this hurdle on filename creation.

As a workaround do not put the result into the filename directly but put the result into a temporary tag field, which you can check by your eyes if the filepath would have been formatted well sized.
Afterwards the last step is setting the %_filename% directly with the value from the temporary tag field.

Read forum threads ...
what is maximum number of characters allowed in filename?
[X] NTFS path/file length exceeded

DD.20120206.2209.CET


#7

I use similar formatstrings, but I get an "error message" when the number of maximum characters is reached. So I don't think that's the case.
But maybe you have disabled those messages at: tools > options > messages
(although I don't think error messages can be disabled)


#8

For kicks, I grabbed Tag&Rename and tried the same thing - it worked.
Haven't rebooted yet. Doing that now and will test again with Mp3tag.


#9

Rebooting didn't help. Took a single file with the same directory structure and tried again. Same problem.

Copied the same file onto a different machine with Mp3tag, created the same directory structure - failed there too... I am stumped. Definitely not more than 255 characters in the full path. I am not ruling out the possibility that it could be due to some Windows setting I have changed, as I tweak a lot, but I can't think of anything. Like I said earlier, if I go to Windows Explorer and manually create the folder and move the file, it works fine. Also, Tag&Rename didn't have any trouble either.

I have uploaded this file (virus free) in a zip duplicating the directory structure. If one of you guys want to have a go at it:

http://www.sendspace.com/file/xfbikz

Be sure to keep the path/folders intact when you extract.
Then try to convert Tag > Filename using:

%album%\%artist% - %album% - %track% - %title%

I would love to know what happens when someone else tries it on their machine.

Thanks!


#10

You're using a relative path and that path it is relative to the current Mp3tag work folder.

So when %album%\%artist% - %album% - %track% - %title% creates

"D:\Temp\Collection\Part1\Album"
instead of
"D:\Temp\Collection\Part1\Artist\Album"

it probably means you've opened the folder "Part1" in Mp3tag and not the folder "Artist"

You can change the string to
%_folderpath%%album%\%artist% - %album% - %track% - %title%

to make it relative to the audio files.


#11

I think the problem is the concept of Mp3tag's Tag-Filename Converter.

If you use a releative paths, they are not based on the folder of each individual file, but on the current working directory of Mp3tag. I also stumbled over this trap a few times.

The working directory changes everytime you load new files into Mp3tag. You can display the working directory at the window title (Tools > Options > General > Show current directory in window title) and display and switch it in the tag panel (Tools > Options > Tag Panel > Display Directory Switcher).

Test the following:
Load only the last folder of you folder structure or the files without folder into Mp3tag. Perform the Converter. I guess it will work.

Load the root folder of your folder structure into Mp3tag. Perform you Converter. I guess the new %album% directory will be created in the root directory.

The problem can be avoided by using absolute paths in the converter when possible.


#12

Ah... OK now it makes sense! Thanks for the clarification.
I guess I haven't had to do this much bulk converting with the need to add album subfolders in a while and probably used Tag&Rename the last time I did. Would be nice to have this option in Mp3tag. :slight_smile:

Thanks again to everyone who chimed in - it was driving me nuts!


#13

@ Dano & Florian:

What is the advantage of using %_workingpath% instead of %_folderpath% as the "base" of the tag-filename & filename-filename converter and the Format Value: _FILENAME action?

For me it feels more like a user trap than an advantage:

  • without "" in the formatstring, the files stay at %_folderpath%, with "" the suddenly move to %_workingpath%. That's isn't consistent behaviour.
  • Action>Format Value: _DIRECTORY behaves different (better), it's always based on %_folderpath%.