Problem with customised filename character replacement

[Steve Pitts]

Folks,

I have tried to customise the list of character replacements in dbPowerAmp r14.4 but the changes don't seem to have the desired effect. This is what the option dialog looks like:



but I still get inverted question marks instead of normal question marks in filenames (which is the only dodgy character that has come up in any of the handful of rips I've done so far, so it may well affect the other characters too). I have tried completely closing the program and starting the process again but both attempts gave me the inverted question mark. Is this working as intended and I've simply misinterpreted what is supposed to happen?? I prefer to keep the filenames of my music collection as vanilla as possible, so the inverted question mark and doubled greater than/less than signs are definitely not desirable AFAIC

[Spoon]

If you open that page again, have your edits stuck?

[Steve Pitts]

If you open that page again, have your edits stuck?

Yes. Perhaps I should have made that explicit, but it was why I said that I'd closed and re-opened the program. My changes were still there after doing so but they do not take effect. I've subsequently ripped '4:13 Dream' and the colon gets mapped to a semi-colon rather than an underscore. I'm unsure as to whether I have any of the other characters in any album or track names so cannot really test any further without doing so artificially. Let me know if there is anything more that I can do or provide.

[Spoon]

We will mark as a possible bug to look at for R14.5

[Steve Pitts]

We will mark as a possible bug to look at for R14.5

Did this ever get accepted as a bug?? Is it fixed, or likely to be fixed, in r15?? This is significant enough to prevent my purchasing the product and, since I have a large pile of CDs waiting to be ripped, I've been reviewing my options before biting the bullet on one solution or the other after six months of waiting for inspiration

[Spoon]

I hope to work on R15 in the next few months to finalize it, all outstanding bugs (this one still is) will be looked at.

[BrodyBoy]

Did this ever get accepted as a bug?? Is it fixed, or likely to be fixed, in r15?? This is significant enough to prevent my purchasing the product and, since I have a large pile of CDs waiting to be ripped, I've been reviewing my options before biting the bullet on one solution or the other after six months of waiting for inspiration

There's really no point in waiting over something like this. This is the kind of small issue that is (1) relatively uncommon, since most file names won't have illegal/oddball characters, and (2) quickly cleaned-up during a post-rip tag check. (And if you're the meticulous sort, you will be doing post-rip tag checks no matter what ripping program you use.)

You could probably get through that large pile of CDs, including all the character swaps you need, long before you find a ripper that can preemptively address every potential issue that will arise along the way. Again, if you're meticulous, it's going to be a two-step process anyway. Might as well get started sooner rather than later....! :smile2:

[Spoon]

We checked for this bug, tried your naming string exactly and it works as expected, the ripped files have : to _

[Houndwave]

We checked for this bug, tried your naming string exactly and it works as expected, the ripped files have : to _

I am also having problems with this function. I am currently testing a trial version of CR Ripper - I can't see from the user interface what the version is but in C:\Program Files\Illustrate\dBpoweramp\Versions\dMC.txt it says Release 15.1

In the "Filename restricted characters" settings, I changed the "?" to a "~" just to test it. Here is the rip log for Van Morrison's Avalon Sunset CD, track 7: (note the "~")

Track 7: Ripped LBA 97783 to 123198 (5:38) in 0:22. Filename: H:\Ian\Archive\Music\Van Morrison\Avalon Sunset\ When Will I Ever Learn to Live in God~.IGNORE
AccurateRip: Accurate (confidence 137) [Pass 1]
CRC32: F242AAA6 AccurateRip CRC: A9B18285 (CRCv2) [DiscID: 010-000f6aa0-007acd86-7e0a000a-7]
AccurateRip Verified Confidence 137 [CRCv2 a9b18285]
AccurateRip Verified Confidence 138 [CRCv1 ac04dfb]
AccurateRip Verified Confidence 14 [CRCv2 ebbe1380], Using Pressing Offset -667
AccurateRip Verified Confidence 17 [CRCv1 c11bb92b], Using Pressing Offset -667

... but here is the actual filename:

When Will I Ever Learn to Live in God¿

Knowing that this function is unreliable, I would manually edit out any unwanted characters in the "Review metadata" window before ripping. However, I hope this is useful feedback for the software authors

[Spoon]

You are ripping to Multi-Encoder it has its own replacement values which are non-editable.

[Houndwave]

You are ripping to Multi-Encoder it has its own replacement values which are non-editable.

Thanks Spoon

Maybe to avoid confusion, the restricted character settings could be disabled in a future release if multi-encoder is in use?
Or allow user settings per encoder? (if there's a technical reason why the general settings can't override the encoder settings)

[Pobo]

I just bought R15.6 and was tearing my hair out why I couldn't get the character replacement working in Options/File Name Restricted Characters... to discover this post about the limitations of Multi-Encoder. Will this still be addressed? I understand that there are all kinds of geeky steps which can be done in post to solve this. But I changed XLD for dbpoweramp exactly for the reason of spending less time on geekiness and more time on music.

In any case, it is misleading in that the UI is suggesting that functionality is available which actually is not :-(