\s causing $regexp error in format value

$regexp(%_FILENAME%,(.* - )?([\w\s]+) .,$2)
and
$regexp(%_FILENAME%,(.
- )?([a-zA-Z0-9 ]+) .*,$2)

cause error code

REGEXP ERROR: Regular expression

Invalid preceding regular expression prior to repetition operator.  The error occurred while parsing the regular expression: '(.* - )?(+>>>HERE>>>) .*'.

due to bold statements

$regexp(%_FILENAME%,(.* - )?([\w]+) .*,$2)
runs perfectly fine

Try this ...
$regexp(%_FILENAME%,'(.* - )?([\w\s]+) .*','$2')
... and come back and report.

See ...
http://help.mp3tag.de/main_scripting.html
Characters with special functionality

DD.20171025.0438.CEST

That did it. Thanks

No, it doesn't:
Invalid preceding regular expression prior to repetition operator.
The error occurred while parsing the regular expression: '(.* - )?(+>>>HERE>>>) .*'."

Have a look to the square brackets ... these are "characters with special functionality" ...
http://help.mp3tag.de/main_scripting.html

DD.20171025.0933.CEST

A follow-up on using \w and \s in a character class:

I looked at this reference: https://www.regular-expressions.info/refcharclass.html. In the tables for Boost and Perl, I see no mention of using \w or \s in a character class. Instead they say:

All characters except the listed special characters are literal characters that add themselves to the character class.
Their "listed characters" are ^ - ] \ . Based on that, a space character within brackets should be a naked space, not \s. So your second example using [a-zA-Z0-9 ] was correct usage but your first example was not.

I think this is what DetlevD is hinting at....

See also ... https://perldoc.perl.org/perlrecharclass.html
See also ... https://regular-expressions.mobi/charclass.html

There is a list of backslash sequences, which are character classes.
Probably these character classes also work within Mp3tag's "Boost" regexp implementation.

Simplified said ...
\s ... matches any "whitespace character", ... the 5 characters [\t\n\f\r ]

\w ... matches any "word character", ... the 63 characters [a-zA-Z0-9_]
... and perhaps other unicode characters as set by modifiers within the regexp machine.

If someone has the need to define and apply a character class for only the space character, ...
then it is written as this: [ ]

Check this formatstring within Mp3tag:
$len($regexp($char(9)$char(10)$char(11)$char(12)$char(13)$char(32)$char(133)$char(160),'\s',))
==> 0

My hint in a post above ...
"Have a look to the square brackets ... these are "characters with special functionality"
points to a special function within Mp3tag, which leads sometimes to confusion, when creating a regular expression:
within Mp3tag scripting language the "square bracket clamb" is an inline function or an inline operator.

Therefore within a regular expression a square bracket clamp has to be enclosed (devalued) within single apostrophes (... or just simply the entire regular expression).

See also ...
Preventing empty output lines in export
Feature request:
RegEx to remove Square Brackets
http://help.mp3tag.de/main_scripting.html (Characters with special functionality).

DD.20171026.0551.CEST

.

DetlevD, thank you very much for the clarification.

I fully agree with your point about enclosing $regexp expressions in single quotes, which I do always (just in case, following your many examples here). I also understand how \w and \s are used outside of a character class and use them that way myself. My post questioned whether using them within a character class was correct usage.

It appears that your regular-expressions.mobi link does not support either \w or \s within a character class, while your perldoc.perl.org reference does indeed:

Backslash Sequences You can put any backslash sequence character class (with the exception of \N and \R ) inside a bracketed character class, and it will act just as if you had put all characters matched by the backslash sequence inside the character class. For instance, [a-f\d] matches any decimal digit, or any of the lowercase letters between 'a' and 'f' inclusive.
Perhaps the regular-expressions.mobi author simply overlooked this point.

I don't have time this week to run tests on how well all this is implemented in the Mp3tag's "flavor" of regexp, but will do so, at least for my own satisfaction. If I find any unexpected results, I'll post them here.