Directory and file name mess with long filenames

[NoMax]

Hi,
I have serious issues with the batch conversion.
I use quite long file names and paths, that's true for sure. But that's the way I want to handle my library.

When converting a couple of hundred files I run into the problem, that the files are converted, but there is a weird sub directory structure afterwards with different cut offs in the names ... and also the file names by themselfes are croped.

In additon I figured out, that one level of folder structure is missing completely.

I updated to the latest version (2024.5.1) since my other version was quite old, but worked fine besides this single issue ... But the latest version has the same issues.

And yes, I am aware of the limitations of the overall path length in older systems. But Besides dbPowerAmp I didn't run into any issues with other software or OS yet.

Does anybody know how to adress / fix this problem?

Best wishes, Max

[NoMax]

I created a couple of screenshots to make the issue more clear .....

Input:



Output:

[simbun]

My filenames are [discnumber].[tracknumber] :-)

What naming string (Output To) are you using in Music Converter?

[simbun]

I assume it's "[origdrive]Musik\Conv_MP3_HQ\[origpath]\[origfilename]" but wanted to check.

[Spoon]

There is a 255 character limit, if you are taking existing filenames which are this and putting them into a folder then it will exceed this.

[schmidj]

It is important that the OP understand the difference between file/directory/folder names and tags. You know what file names are, but tags are metadata such as the album name, the track title, the track number, the artist name and any number of other items which describe the contents of the file The tags are typically stored inside the same file that holds the music, according to several standards, depending on the file format (mp3, m4a, FLAC, etc, etc.) Most players and the library databases they use to allow you to search for music to play are optimized to search the tags, not the file and folder names.

Filenames and folder/directory names have any number of restrictions, depending on the operating system and the file storage formats (NTFS, FAT, etc.) Each have their restricted characters, characters which have a special meaning to the operating system. They also have restrictions on how many characters make up the filename. Often those filename length restrictions apply to the entire string of file and directory/folder names that define the file to the operating system and the software it is running. For instance a file named "abcdef" has 6 characters, but if it is stored in a folder named "ghi" which is in turn stored in a directory "jkl" the file path is actually defined as "jkl/ghi/abcdef", 14 characters. It gets a little more complicated if you are storing your files on let us say a NAS server running Linux but using them on a PC running Windows. Both devices must be running software that is able to read or write the files and directories on the other device, and that software has further limits on filename construction. Finally, the software you are actually using to read the file such as your player or library system may have its own limits.

The end result is that from a practical standpoint, there is a list of "illegal" characters prohibited by most operating systems, like the question mark, slashes or backslashes (except as a delimiter between the filename and directory names, and there it depends on the operating system as to which is correct). dBpoweramp has a user amendable list which it uses to prevent the user from creating "illegal" filenames. Furthermore, in many cases you will be limited to 255 characters for the length of the filename path, including the entire directory tree. However that limit depends on how you store and retrieve your files. For instance if you are storing the files on the same Windows PC as you are ripping and playing them on, and your hard drive is formatted with NTFS, you will find a pathlength limit of 256 characters imposed by Windows. But you can change that (a Windows variable called MAX_PATH in older versions of Windows) to something over 32,000 characters, through a registry edit (far beyond what I'm going to discuss here, Google it if you want to go there). But if you go to copy one of the now enabled really long filenamed files to a USB drive you may have an issue because FAT32 or EXFAT (the usual formats for USB drives) only allow each segment of the path to have 255 characters. The default dBpa setup does not have any protection to prevent you from generating "too long" filename/directory name paths, presumably because what is "too long" varies greatly with different hardware/software configurations.

But there are no such restrictions on tags. You can use any characters in the tags, including all the Unicode characters used for foreign languages. While the different tagging standards do in fact have field length limits, unless you are using a very old version of one of the standards, as a practical matter you can make the tag as long as you like, you won't run out of space. Do be aware that some players and library systems may truncate long tags when searching, and even truncate them more in the on-screen display. (I find this very annoying when they could have easily scrolled them.) And there is absolutely nothing saying that the filename or any part of it has to be the same as the tag. The main function of the filename should only be for a human (you) to find a particular file for file maintenance purposes, and for that you can easily truncate/edit long filenames to keep within the character limit. None of this effects what your player or library displays as long as you have it set up to display tags, not filenames.

In dBpa, the "naming string" is only concerned with the filename, it takes tags or portions of them and uses its 'formula' to generate the file path for storing the rip. It has nothing to do with the content of the tags. You can use functions such as the MAXLENGTH function to shorten or truncate the file and path names as you rip or convert the files. While a bit obtuse to those who don't have programming experience, it is well described in the dBpa site, and there are a number of folk here who will help you out in coming up with a naming string as long as you want to create any reasonable file storage system. There is one trap here to watch out for. It is important that your naming string comes up with unique paths (directory and file names) for every track, as otherwise some of your files may be written over and be lost. Backups before any major batch operation are your friends.

In your case, you would be best to make sure the actual tags (as opposed to the file path) have the data you want to see in them. If some (or all) is missing you can edit it using the dBpa "right click" tag editor or the tag editing program mp3tag (which works on any imaginable format, not just mp3's). Then you could use the batch convert part of dBpa with your new naming string to create a new directory with your files with shortened paths.

[NoMax]

I assume it's "[origdrive]Musik\Conv_MP3_HQ\[origpath]\[origfilename]" but wanted to check.

I am using the "preserve source path" function and select a new directory to put the converted files to. That's right. I can tweece it down by one or two levels .. but that won't help. My paths are quite huge ...

[NoMax]

It is important that the OP understand the difference between file/directory/folder names and tags. You know what file names are, but tags are metadata such as the album name, the track title, the track number, the artist name and any number of other items which describe the contents of the file The tags are typically stored inside the same file that holds the music, according to several standards, depending on the file format (mp3, m4a, FLAC, etc, etc.) Most players and the library databases they use to allow you to search for music to play are optimized to search the tags, not the file and folder names. [...]

That's a good point ... but unfortunaltely does not apply in my case. I am not using tags whatsoever to name my files ... at leat not at this point. The complete folder structure already exists as m4a files ... which I want to convert 1:1 to MP3 due to player compatibility issues.

So the original files completely exist with the exact file names and folder structures except for the file extension.

[...] But you can change that (a Windows variable called MAX_PATH in older versions of Windows) to something over 32,000 characters, through a registry edit (far beyond what I'm going to discuss here, Google it if you want to go there). But if you go to copy one of the now enabled really long filenamed files to a USB drive you may have an issue because FAT32 or EXFAT (the usual formats for USB drives) only allow each segment of the path to have 255 characters. [...]

I think that's closer to the root cause ...

I never tried on FAT, vFAT or exFAT to be frank. Didn't use them for quite a while but because of the 2GB filesize limitations. Even my USB sticks are mainly NTFS formatted since this is the file system that most OS understand. I tried NTFS, EXT4 and BTFS ... and CIFS / SMBFS on a QNAP NAS ... non of them have any issues with the long path/file names. Also once the files have been converted I can rename them exactly in the location they are stored in in the first place to full length. So the file system can be excluded. Unfortunately renaming is not an option for me since renaming 1000+ files by hand ... no thanks ...

Soe when dbPowerAmp does not care about such limitations, where are they comming from?

[NoMax]

There is a 255 character limit, if you are taking existing filenames which are this and putting them into a folder then it will exceed this.

Yes, that's right ... 255 characters easily are exceeded.

So is this a limitation of dbPowerAmp then? My file system (NTFS on Windows 10/11 or BTFS/EXT4 on Linux ... not to mention LTFS) are fully capable of longer file and path names. Besides that, the original file structure already exists on the same storage media where the converted files are supposed to end up. After the broken conversion I can rename the files and folders by hand to the original names as well ... so the file location is capable of handling them.

Actually, literally, the only limitation on long file path/names I've seen so far was total commander ... and this software just rises a warning but does it without limits nevertheles. dbPowerAmp is the first SW I actually have seen that has real trouble.

What is your suggestion? How should I proceed?

[Spoon]

Although the filesystems are able to handle 65535 characters, most systems cannot, even Windows Explorer messes up with a long filename. Any network share is limited also, so dBpoweramp imposes these rules so no one has issues with files or accessing them.

Do something like:

[origdrive]Musik\Conv_MP3_HQ\[origpath]\[MAXLENGTH]80,[origfilename][]"

[NoMax]

Ok ... well ... as mentioned ... it works on all my systems ... But ok ... that's a limitation I am disapointed about ... especially since I updated now for ... nothing .. The functions I am using I already was able to do with my 3 year old version ...

Can we at least file it as a bug or improvement for further versions somehow?

[Spoon]

We might well do

[NoMax]

At least I figured out a workaround ...

1. I put all current file names of the originals in a temporary tag (using mp3tag)
2. I rename all files in all subdirectories to 0001.* to xxxx.* (using Total Commander)
3. I convert the files to MP3 with dbPowerAmp
4. I rename all the files to the original name stored in the temporary tag (using mp3tag)
5. I delete the temporary tag

That's not straight forward, but worked for me ...