BUG: MAXLENGTH truncates the last 7 characters for every comma "," present in the tag

[gdk]

I've been using dBpoweramp CD ripper, MP3tag and dBpoweramp Music Converter for several years to manage my Flac and AAC music libraries. I've recently noticed (what I think may be) a bug when using dBpoweramp to construct the destination folder and filename.

I use the MAXLENGTH command to limit the length of the folder or filename so my total library folder structure does not exceed the limits of the file system:

I'm on Reference 15.2, running on Windows 7 Ultimate 64 bit, but I first noticed this problem in 14.2 (on the same OS)

This is my naming string:

[MAXLENGTH]100,[album][]\[SETLEN]2,48,,[disc][][SETLEN]2,48,,[track][] - [MAXLENGTH]50,[title][] - [MAXLENGTH]40,[artist][]

I use custom "Filename Restricted Characters":

" &*8243;
> ›
< ‹
? &*65311;
: &*8758;
/ &*8725;
* &*8727;

In my folder arrangement, the folder for each album is simply the ALBUM field, limited by MAXLENGTH to 100 hundred characters. TITLE is limited to 50 characters and ARTIST, 40.

So, the resulting folder and filename for track 1, called "mytrack", on an album called "myalbum" looks like this:

libraryroot\myalbum\0101 - mytitle - myartist.flac

If I have an ALBUM named:
12345678911234567892123456789312345678941234567895 12345678961234567897123456789812345678991234567890 123456789
the resulting folder is correct, at 100 characters in length:
12345678911234567892123456789312345678941234567895 12345678961234567897123456789812345678991234567890

If I have an ALBUM with a comma character "," present, like this:
1234567891, 34567892123456789312345678941234567895123456789612 34567897123456789812345678991234567890123456789
the resulting folder is only 93 characters in length:
1234567891, 34567892123456789312345678941234567895123456789612 3456789712345678981234567899123

If more commas are present another 7 characters is lost for each one. I first noticed the "bug" on TITLE, so it presumably affects all tag fields.

Has anyone else experienced this? Does anyone know a workaround? Is this a known bug? Or am I missing something really basic?

[gdk]

I think I've posted to the wrong sub Forum. So I'll repost under CD Ripper with some additional information. Thanks.

[BrodyBoy]

Is this actually ever an issue?

I've never run into an album name that's that long, so a need to set a 100 character limit would never have occurred to me. And there have only been a few very rare cases, all with classical music (specifically opera, where track "names" are really descriptions...), where the entire library folder structure + filename was too long for Windows' file system. I forever solved that problem by moving my "Classical" folder up to just under the root level in my music library.

[gdk]

Thanks for your helpful and friendly reply to my first post on this forum.

I'd have thought that maxlength should "do what it says on the tin". That's all.

Your library might not contain a significant amount of long titled classical music, but others might.

None of us would be here, using this product, if we weren't at least a little OCD about our music libraries.

[BrodyBoy]

I meant no snark and I'm sorry that you seem to have taken it that way. I'm hopeful that Spoon weighs in on what's happening with that combination of special characters and string limits.


My library does contain a great deal of long-titled classical music, and as I said, I've only run into that issue on a very small number of files in the past. So I am honestly curious whether this is something that poses an ongoing problem for you, and under what circumstances. If in fact it does, it might make sense to re-visit your file naming and folder structure schemes with an eye toward making them more user-friendly.

[Spoon]

Possible bug noted.

[gdk]

Possible bug noted.

Thanks, spoon.

And to answer Brodyboy:

In fact it does crop up fairly often. The 100 character ALBUM was just an example. (Please see my other post under CD Ripper - sorry to have created a duplicate). You don't need a particularly long TITLE to exceed 50 characters - which is where I first noticed the issues.

On the general principle and "philosophy": To my way of thinking, ensuring the folder and filename does not exceed the limits of the file system is simply common sense and good coding practice. I have run into issues before when an application creates an illegal folder structure (that the OS wouldn't allow to be created manually) because the OS doesn't apply the same checks as when creating by hand. The problems may not obvious at first (if the program doesn't report an error, warning or throw an exception when it attempts to create the illegal folder or file), and especially because it is likely to only affect a small portion of the files, but you will get issues when deleting, copying and backing up files and with other apps losing access to the "illegal" files and folders.

[gdk]

Some additional debug info after further testing that might help Spoon:

Reverting to default character substitution makes no difference
GRAB(1,50) has the same problem.
Applies to folders and files with names constructed from ALBUM, TITLE and ARTIST from which I would assume the source tag field doesn't matter.

It's the algorithm within MAXLENGTH and GRAB that seems to be at fault.

Any help appreciated.

[gdk]

Possible bug noted.

It's been a while, so I was wondering whether this bug will be fixed at some point? I'm new to the site, so I wondered if you can set my expectations? I have a workaround which works for me so it's not a priority - just wondering what the usual process is and how long it takes. I guess that depends on the severity of the reported bug.

Any info appreciated. Thanks.

[Spoon]

It has been fixed in the latest R15.3 beta test version, see the testing section of the forum.

[gdk]

It has been fixed in the latest R15.3 beta test version, see the testing section of the forum.

That's great! Thanks. :)

[gdk]

I finally upgraded to 15.3 after upgrading to Windows 10 as well and confirm this bug is fixed. Thanks again! :)