File naming difference between FLAC converter and Arrange Audio

[SirAtilla]

I see some slight differences between filenames when I use the same Dynamic Naming formula between a FLAC encoder and an Arrange Audio converter. This has to do with restricted character replacement set in advanced settings. Do the two encoders not use the same source of truth? I could send example in a private message along with the File Name Character Replacement settings.

[SirAtilla]

I managed to isolate the issue more specifically - a trailing period in track title is handled differently by the FLAC converter vs Arrange Audio converter.

This is on dBpoweramp on macOS. Source and target both FLAC. Only variable between runs is which converter is used.

Summary

When a track title ends in a period, the FLAC converter preserves that period in the output filename while Arrange Audio strips it. Same dynamic naming formula, same settings, same source file — two different filenames.

Example

Track title tag: S.O.S.

FLAC converter	05 S-O-S..flac
Arrange Audio	05 S-O-S.flac

The character replacement table is not the cause

I initially assumed this was the a . → - rule in File Name Character Replacement in Advanced Settings. It isn't. With that rule removed entirely, the divergence persists unchanged:

. → - present	05 S-O-S..flac	05 S-O-S.flac
no . rule	05 S.O.S..flac	05 S.O.S.flac

Interior periods track the table correctly in both converters. The string-final period tracks nothing — it appears never to reach the replacement stage at all. Note that with the rule present, neither converter produces what the rule specifies, which would be 05 S-O-S-.flac.

This is by naming formula

[IFVALUE]album artist,[album artist],[IFCOMP]Various Artists[][IF!COMP][artist][][]/[album]/[IFMULTI][SETLEN]2,48,,[disc][]-[][track] [title]

[manuelrivero]

That is a very clear reproduction of the issue. Since the interior periods follow the replacement table correctly, while only the final period behaves differently, it looks like Arrange Audio performs an additional filename-sanitizing step before adding the extension.

I agree that both converters should produce consistent results when using the same source file, Dynamic Naming formula and replacement settings. It may help the developers if you also provide the exact dBpoweramp and macOS versions, destination filesystem, and a simplified test using only [track] [title].

Sharing the example publicly was helpful, as other users can now test whether they see the same behavior.

[SirAtilla]

Follow-up: controlled test isolating the behavior

Reference: dBpoweramp 2026-09-05 on macOS 26.6.2 using APFS.

Following up on my earlier post with a controlled test. I created eight tracks whose only variable is the title tag, converted the same source album through both paths with identical settings, and compared the resulting filenames.

Replacement table active, including . → -.

Six of eight are identical. The two that differ are the cases where the title ends in a period: Arrange Audio drops it, the FLAC converter keeps it.

I'm not reporting the general replacement behavior here — whatever the rules are, both converters apply them the same way in six of eight cases. The issue is the two that don't match.

Scale

Across one subtree of my library, 212 files out of 94,742 differ between the two converters, and the trailing period is the only difference in every one of them. Affected titles are anything ending in a period: acronyms (U.S.A., S.O.S., T.N.T.), abbreviations (Excuse Me Mr., Johnson Blvd., Etc.), roman numerals in classical movement titles, and ellipses.

This is invisible under normal use. I only found it by re-encoding the library to a different block size and comparing the two trees filename by filename.

Why it matters beyond cosmetics

On my music transport, the filename is the identity for references. Playlists reference tracks by exact path, and per-track user ratings are keyed to filename. A converter that produces two different filenames from the same title tag and the same settings silently invalidates both. You get no error — just a playlist entry that no longer resolves and a rating orphaned from its track.

I maintain utilities to repair those references, because filenames legitimately change when I correct a title tag. What I can't easily anticipate is drift caused by the tool being internally inconsistent with itself.

Hope this helps