# Can someone try this regexp for me? **URL:** \ **Category:** Mac\ **Created:** [January 19, 2021, 1:43pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658 "2021-01-19T13:43:53Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Rigido](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rigido/32/8725_2.png) [@Rigido](https://community.mp3tag.de/u/Rigido)\ **Post date:** [January 19, 2021, 1:43pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/1 "2021-01-19T13:43:53Z")
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. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 19, 2021, 2:05pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/2 "2021-01-19T14:05:37Z")
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 🤘 ---
**Author:** ![Rigido](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rigido/32/8725_2.png) [@Rigido](https://community.mp3tag.de/u/Rigido)\ **Post date:** [January 19, 2021, 2:22pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/3 "2021-01-19T14:22:57Z")
Yeah Florian, you're right! But I don't think this is correct. 🤔 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. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 19, 2021, 2:36pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/4 "2021-01-19T14:36:08Z")
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` ---
**Author:** ![Rigido](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rigido/32/8725_2.png) [@Rigido](https://community.mp3tag.de/u/Rigido)\ **Post date:** [January 19, 2021, 2:45pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/5 "2021-01-19T14:45:55Z")
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? 😃 ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 19, 2021, 2:48pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/6 "2021-01-19T14:48:31Z")
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... 😃 ---
**Author:** ![Rigido](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rigido/32/8725_2.png) [@Rigido](https://community.mp3tag.de/u/Rigido)\ **Post date:** [January 19, 2021, 3:00pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/7 "2021-01-19T15:00:14Z")
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... ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [January 20, 2021, 6:08am UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/8 "2021-01-20T06:08:21Z")
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._ ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [March 2, 2021, 3:18pm UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/9 "2021-03-02T15:18:32Z")
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. ---
**Author:** ![Rigido](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rigido/32/8725_2.png) [@Rigido](https://community.mp3tag.de/u/Rigido)\ **Post date:** [March 3, 2021, 9:33am UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/10 "2021-03-03T09:33:34Z")
So I have to put back "/"?! 😤 Just kidding...I'll look and check it. Thanks. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [March 3, 2021, 9:34am UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/11 "2021-03-03T09:34:52Z")
Yes, you have to put back the `/` — it's unfortunate in the short run but hopefully creates less confusion in the long run 😅 ---
**Author:** ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)\ **Post date:** [April 2, 2021, 9:35am UTC](https://community.mp3tag.de/t/can-someone-try-this-regexp-for-me/51658/12 "2021-04-02T09:35:02Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.