Too silly - the batch converter truncates longer folder and path names. VERY inconvenient and very tedious to repair.
Please correct this bug - the program should of course be able to handle all folder and path names that are valid in Windows.
Too silly - the batch converter truncates longer folder and path names. VERY inconvenient and very tedious to repair.
Please correct this bug - the program should of course be able to handle all folder and path names that are valid in Windows.
It is not a bug 'cause a windows standard setup allows a path length of max. 260 characters only. Even if you enable NTFS long paths you can't be sure, that all of your programs and apps can handle those.
Dat Ei
Hi,
I don't agree.
Firstly, any programs running on my standard Windows 10 installation should be able to handle the file names that ordinary programs create on this system. By the way, the (in your view) "illegal" path names have been created by the dbPoweramp CD ripper (!!), so it is odd that the converter from the same company cannot handle those path names.
Secondly, my path names are nowhere near the 260 char limit. In this example it is both the FOLDER name and the FILE NAME that show the problem:
As created by the CD ripper:
R:\Music\Klassisk\W. A. Mozart - Complete Works\Vol. 3 - Serenades, Divertimenti, Dances\W. A. Mozart - Divertimento for 5 trumpets & 4 timpani, KV 188\01 Divertimento for 5 trumpets & 4 timpani, KV 188 - 1. Andante - W. A. Mozart.flac
As created by the converter:
R:\Music MP3\Klassisk\W. A. Mozart - Complete Works\Vol. 3 - Serenades, Divertimenti, Dances\W. A. Mozart - Divertimento for 5 trumpets & 4 timpa\01 Divertimento for 5 trumpets & 4 timpani, KV 188 - 1. Andante - W. A. Mo.mp3
I maintain that the converter program is buggy.
Well, my previous mail was not entirely correct.
The source flac file was not created directly by the CD ripper. The ripper created the file on the local C: drive with a slightly different file name and was thereafter moved to the network drive R:
However, since the converter was able to read the source file it should still be able to write the target mp3 file with almost the same path name.
Hey kas,
unfortunately there is a big gap between theory and practice. We have experienced problems even within windows itself. There are a lot of aspects to take in count. In my company we don't enable long paths as the are more a source of problems than they help at all.
Dat Ei
Which version of dBpoweramp do you have?
What is your naming string? (in Output To)
Spoon
www.dbpoweramp.com
I am having no problem with the longer names at all. Neither Windows (Explorer) nor other programs (VLC, Sonos, Dyalog APL, etc.) are having problems that I have encountered.
In any case dbPoweramp should definitely issue a warning when it encounters names that it think that it is unable to handle. I discovered it because I am paranoid enough to compare the input list with the output list (2,500+ files).
Hi Spoon
I'm using version 17.3 (64 bit). The naming string was [origpath]\[origfilename], as far as I remember.
However, there might be some confusion, since version 14.4 occasionally pops up. I don't see how I can get rid of the old version without just deleting the folder.
Version 14.4 is in Program Files (x86)\Illustrate\dbPoweramp, whereas version 17.3 is in Program Files\dbPoweramp.
In the Apps list in Windows I only see one entry (without version no.).
Can I just delete the old Illustrate folder?
...../Kim
By te way, it looks a bit random where names are being truncated. Most often it is the very last characters of the file name, but occasionally it's also the name of the containing folder that is truncated (as in the example I posted above).
Another related problem is that some characters are not transferred correctly from the source to the target. One example is the character '¿' which becomes '½'.
...../Kim
I doubt that, as the parent folder is R:\Music MP3, not R:\Music.
To troubleshoot, we would need to know the exact contents of Output To. Also, were you using any DSP Effects when converting to mp3?
Is this happening for metadata tags and/or in the path\filename?
If the naming string is:
[origpath]\[origfilename]
Then the filename is not touched, even if illegal on the system. This is in R17, R14 would be totally different.
Spoon
www.dbpoweramp.com
I still believe that I used [origpath]\[origpathname], but with base folder set to R:\Music MP3\Klassisk\W. A. Mozart - Complete Works\. Perhaps this made the problem worse, as there temporarily were two levels of extra folders, which I had to remove afterwards. The description of the logic for dynamic naming leaves a lot to be desired - basically it says "experiment", which is what I did.
I did not use any DSP effects.
Only in the path/filenames, as far as I have seen. I haven't checked the metadata tags. I don't think I would find the problem there, since the upside down question mark was used in the file names only because the regular question mark is not allowed. In the metadata tags the regular question mark is used.
Ah. it is becoming clearer now and explains the truncation.
If Base Location is R:\Music MP3\Klassisk\W. A. Mozart - Complete Works, then you need to use [TRIMFIRSTFOLDER][] e.g.:
[TRIMFIRSTFOLDER][TRIMFIRSTFOLDER][TRIMFIRSTFOLDER][origpath][][][]\[origfilename]
to remove the first 3 folders from [origpath].
Thanks, but it is indeed very confusing. I have no idea what is the [origpath] - is it the full path or relative to the folder that I have selected for conversion, or??? Apparently the drive letter is not part of the [origpath]. Questions like this that I did not find useful answers to led me to run an apparently inappropriate conversion. I use the program too rarely to really learn the details.
Copyright © illustrate 2024, All rights reserved