Have begun delving into the pseudo-language which dBpoweramp uses for file naming, in the CD Ripper and have a couple of questions, please (Release 2024-02-01 on macOS 13.6.4).
If the syntax is as straightforward (although a little ‘proprietary’ - and why not!) as it seems, isn’t it a question of:
- stringing ‘Elements’ together
- sometimes separated by backslashes (
\
), and - putting an empty pair of square brackets (
[]
) to denote the end of a function?
Just that sometimes the backslash seems obligatory, and sometimes not; anyone figured out this aspect of the syntax, please?
To me, it seems particularly hard to read the default string - even when nested Elements placed on separate lines and indented:
[MAXLENGTH]80,[IFVALUE]album artist,[album artist],[IFCOMP]Various Artists[][IF!COMP][artist][][][]/[MAXLENGTH]80,[album][]/[MAXLENGTH]80,[track] [artist] - [title][]
But - practically - for my specific purposes, can anyone see anything wrong with this string, which seems to work:
[album]\CD [Disc]\[track] - [title]
to:
- create a parent ‘Album’ string, which I supply from dBpoweramp’s ‘Album’ field… my collection is all classical music, and Album, rather than artist, makes more sense
- create as many child folders - sequentially numbered - as there are multiple CDs - in multi-disk sets if necessary; but how does dBpoweramp know (how) to count (‘CD 1’, ‘CD 2’, ‘CD 3’ etc)?
- build filenames for each track, for each CD in those child folders using (only) Track number and Title as ripped.
Secondly, and really obscure, in experimenting, the Naming dropdown at bottom right of dBoweramp’s main window has become… ahem, ‘overcrowded’ with trial (and faulty) strings, which are really lost causes.
Can anyone see any reason not to edit:
~/Library/dBpoweramp/XRegistry
and delete the corresponding now unwanted lines?
There’s no CRC (or similar) safety check on launch that might object, is there: there seems to be no other way to get a clean slate.
Thanks in advance to any kind soul who’s explored this!