I'm not sure if this is a bug or if I have missed something ...

When using "move or rename files" (playlist selection context menu->File operations->Move, rename or copy files"), $replace() seems to be ignored. I use the following output filename format:

For a track with the title:

the preview in the main "Move, rename or copy files" dialog, and the name of the renamed file after the Run button is pressed, is as follows:

The preview field in the "File naming schemes" dialog (which appears after the Edit button is pressed) and in the "File naming scheme" dialog (which appears when the file naming scheme in question is double clicked) is correctly rendered as:


Hypothesis: Characters that cannot be represented in Windows file names are replaced with an underscore (_) character prior to the application of the selected file naming scheme instead of after. This behaviour would make $replace() on such characters ineffective.

edit: Note that this works correctly in Foobar2000 0.8.3. This has existed for all 0.9betas I have tried so far, but I just hadn't gotten around to reporting it until now.
edit 2: Damn, just found this topic, which describes the same issue.

As you suspect, in 0.9 the filtering is applied when a field reference is expanded as opposed to 0.8.3 and previous where the filtering was applied on the final result of the formatting script. The upside of the new way is that you no longer have restrictions on using / and \ in massrenamer scripts, i.e. you can do instead of

The downside is that your custom character replacement scheme won't work.

Is there any possibility of toggling this behaviour for a given file naming scheme? I understand that sometimes, a change has to be made which fixes a problem encountered by many at the expense of a problem encountered by very few, but this change makes the aforementioned file naming scheme impossible to use at all, which means I need to keep 0.8.3 around even when 0.9 goes final. Also, at least with the old behaviour, it is possible to work around by using the same condition many times (as in e.g. your first example), whereas it is impossible to get mine to work at all, although I suspect there are probably situations where you can't work around the issues created by the earlier behaviour.

Thanks.

My apologies for bumping this topic, but is there any chance of a fix for this (such as a toggle to re-enable the old behaviour)? I guess I seem to be the only one who finds this problematic.