Tweet
I've been using dBpoweramp CD ripper, MP3tag and dBpoweramp Batch 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 CD Ripper (or Batch Converter) 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":
" is replaced with Unicode Hex 2033 (double prime)
> &*8250;
< &*8249;
? is replaced with Unicode Hex FF1F (full width Question Mark)
: is replaced with Unicode Hex 2236 (ratio)
/ is replaced with Unicode Hex 2215 (division slash)
* is replaced with Unicode Hex 2217 (asterisk operator)
| is replaced with Unicode Hex 2223 (divides)
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: Star Trek: Enterprise: Collection
and track 1 is named: Where My Heart Will Take Me (Main Title, Season One)
the resulting filename is incorrect, with the TRACK portion only 43 characters in length, instead of 50:
\Star Trek: Enterprise: Collection\0101 - Where My Heart Will Take Me (Main Title, Se - Russell Watson.flac
It should be:
\Star Trek: Enterprise: Collection\0101 - Where My Heart Will Take Me (Main Title, Season On - Russell Watson.flac
If no commas are present in the data, it is truncated at the correct length.
If more commas are present another 7 characters is lopped off the end for each comma.
If the TITLE is shorter than the MAXLENGTH value, it is unaffected.
It looks like a bug in the string shortening algorithm to me.
I first noticed the "bug" on TITLE, but have since tested it on ALBUM and ARTIST so it presumably affects all tag fields when used to construct a folder or filename.
I've also tested it using GRAB(1,50,title) and it has exactly the same issue.
Has anyone else experienced this?
Does anyone know a workaround? My workaround is to use MP3Tag's Tag -> Filename function to rename the file after ripping the CD. Its string manipulation function does not have this problem. Also, when preparing AAC versions using Batch Converter I will use original folder and filenames rather than constructing the names from the tag data.
I want to keep filenames identical in AAC and Flac versions (barring file extension of course) to make it easy to port playlists from one system to another. (Squeezebox <-> iTunes)
Is this a known bug?
Or am I missing something really basic?
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":
" is replaced with Unicode Hex 2033 (double prime)
> &*8250;
< &*8249;
? is replaced with Unicode Hex FF1F (full width Question Mark)
: is replaced with Unicode Hex 2236 (ratio)
/ is replaced with Unicode Hex 2215 (division slash)
* is replaced with Unicode Hex 2217 (asterisk operator)
| is replaced with Unicode Hex 2223 (divides)
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: Star Trek: Enterprise: Collection
and track 1 is named: Where My Heart Will Take Me (Main Title, Season One)
the resulting filename is incorrect, with the TRACK portion only 43 characters in length, instead of 50:
\Star Trek: Enterprise: Collection\0101 - Where My Heart Will Take Me (Main Title, Se - Russell Watson.flac
It should be:
\Star Trek: Enterprise: Collection\0101 - Where My Heart Will Take Me (Main Title, Season On - Russell Watson.flac
If no commas are present in the data, it is truncated at the correct length.
If more commas are present another 7 characters is lopped off the end for each comma.
If the TITLE is shorter than the MAXLENGTH value, it is unaffected.
It looks like a bug in the string shortening algorithm to me.
I first noticed the "bug" on TITLE, but have since tested it on ALBUM and ARTIST so it presumably affects all tag fields when used to construct a folder or filename.
I've also tested it using GRAB(1,50,title) and it has exactly the same issue.
Has anyone else experienced this?
Does anyone know a workaround? My workaround is to use MP3Tag's Tag -> Filename function to rename the file after ripping the CD. Its string manipulation function does not have this problem. Also, when preparing AAC versions using Batch Converter I will use original folder and filenames rather than constructing the names from the tag data.
I want to keep filenames identical in AAC and Flac versions (barring file extension of course) to make it easy to port playlists from one system to another. (Squeezebox <-> iTunes)
Is this a known bug?
Or am I missing something really basic?