Can someone try this regexp for me?

As I started to "really" use Mp3tag on Mac I found a problem with a regexp I used thousands of time on Windows. I stripped it down and kept just the regexp:

$regexp(%DISCNUMBER%,'.*/(.*)',$1)

This should return the "divisor" of the disc number (i.e. 3 if disc number is 1/3) but it returns the whole tag (1/3) instead. I already wrote to Florian but he told me that regexp worked for him, so I was wondering if it could be somehow related to OS language settings.

I'm using latest Big Sur Public Beta, OS language and cultural convention is ITALIAN.

You're most likely using that in the context of file renaming. Can you try:

$regexp(%DISCNUMBER%,'.*_(.*)',$1)

The implementation of the field lookup in Mp3tag for Mac replaces invalid characters by an underscore on field access, and by that, circumvents what I call the "AC/DC"-Problem :metal:

Yeah Florian, you're right! But I don't think this is correct. :thinking:
Regular expression is performed on DISCNUMBER field, just the resulting string should be "fixed" depending on the destination tag.
I tried same expression on COMMENT field and I had to put / back to make it work, that makes no sense for me.

I think it's correct, but maybe not the most convenient way for you.

The problem is, that if the resulting string from $regexp() is fixed, there is no way of knowing if, e.g., a / character stems from a field value or from some replacement inside the regular expression with the intention to produce a file path with folder declaration.

An example where one wants to create folders for each of the words inside the artist field:

Artist: AC/DC Two Three
Format: $regexp(%artist%,\s+,/)
Result: AC_DC/Two/Three

If the resulting string would be replaced, you'd end up with

AC_DC_Two_Three

Tell me if I understood:
If destination field is "filename" related (_FILENAME or _DIRECTORY) "fixing" is done on source tag before evaluating regexp.
Am I right? :smiley:

Yes, this is how it's working right now. It's one of the changes for the Mac version, based on countless support requests regarding invalid characters in filenames.

But I can already see where this is going... :smiley:

I can understand it, but this introduces another issue (for me)...
This is for _FILENAME:

$ifgreater($regexp(%discnumber%,'.*/(.*)',$1),1,$num(%discnumber%,1)-$num(%track%,2). $replace(%title%,/,-),$num(%track%,2). $replace(%title%,/,-))

To make it work I have to change the regexp and, correct me if I'm wrong, replace will never find any / to replace, maybe I should think to replace underscores...

Yes, you'd need to replace underscores.

I see three drawbacks with the current approach:

  1. It differs from the behavior of the Windows version and might create confusion for those who reuse format strings.
  2. It's not possible to replace the invalid characters by something else than _
  3. It's not possible to distinguish between underscores that result from replacement of invalid characters and underscores that were already in the field.

However, all that for the benefit of not needing to take care of those special characters : and / in every format string you use.

If you have the NTFS option enabled at Preferences > General, the list of special characters extends to the invalid chars on Windows.

I've just released v1.0.2 and now reverted the new behavior where special characters were automatically replaced on field-lookup.

It caused more irritation than doing good and having no magic there is probably a good way to go.

So I have to put back "/"?! :triumph:
Just kidding...I'll look and check it.

Thanks.

Yes, you have to put back the / — it's unfortunate in the short run but hopefully creates less confusion in the long run :sweat_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.