# Unexpected behaviour when replacing variations of feat
**URL:** https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478
**Category:** Support
**Created:** [February 10, 2019, 10:11pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478 "2019-02-10T22:11:51Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@sheepdisease](https://community.mp3tag.de/u/sheepdisease)
#### Post date: [February 10, 2019, 10:11pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/1 "2019-02-10T22:11:51Z")
I ran this action on a group of files and it changed files even where a complete match was not found.
Found example, it changed 'Cliff Richard' to 'Clifeat. Richard' and 'Daft Punk' to 'Dafeat. Punk'.
I've tried it as replace with regular expression (results above) and replace (only as whole word selected) with the latter causing no changes at all.
I don't understand this because in my mind, it should only replace any exact instance of 'ft. |f. |featuring |feat ', yet it seems to be matching partials.
Why is this happening and how can this be corrected?
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [February 10, 2019, 11:06pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/2 "2019-02-10T23:06:11Z")
> [@sheepdisease](#):
>
> ft. |f. |featuring |feat
Your 1st alternative in the above regular expression reads as
```
ft matches the characters ft literally
. matches any character (except for line terminators)
matches the character literally
```
So "Daft " matches
Your second alternative in the above regular expression reads as
```
f matches the character f literally
. matches any character (except for line terminators)
matches the character literally
```
So "Cliff " matches.
Please use a [online regex-checker](https://regex101.com/) to be sure how your regular expressions are working.
---
### Author:  [@sheepdisease](https://community.mp3tag.de/u/sheepdisease)
#### Post date: [February 11, 2019, 6:06am UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/3 "2019-02-11T06:06:19Z")
Thank you, your explanation is very good. That is not at all how I would have imagined it working, in my mind I thought it would look for the letters, space and full stop combined.
That online tool looks good, could you please explain how I would input my example into it to test it? I'm not sure.
Also, I think the correction should be like this:
I anticipate problems with the 'feat' example at the end of other words, can you think of a way of getting around this?
I tested the code in a standard replace and that still doesn't work, so I can't restrict to whole words only.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 11, 2019, 7:46am UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/4 "2019-02-11T07:46:50Z")
> [@sheepdisease](#):
>
> in my mind I thought it would look for the letters, space and full stop
WIth the exception of the full stop which is a special character for regular expressions it worked absolutely as designed.
The problem is as follows:
If you use "regular expressions" it is expected that there is a regular pattern to be treated like "any text followed by a number".
In your case you simply replace one constant text with another constant text. There is no regular pattern.
The only problem I see is some kind of laziness to create an action for each pair of search and replace terms and a proper list of fields.
\_ALL is rather dangerous IMHO as there are albums around that have "Featuring" in the name and I would not want to get them modified by such a routine.
You say, you chose
> [@sheepdisease](#):
>
> replace (only as whole word selected) with the latter causing no changes at all.
I would like to see the syntay you used for this action. If you entered
"ft. |f. |featuring |feat "
as search string, it is absolutely clear that this will hardly ever find any matches as I do not know any title where you find this total string with bar characters in it.
If you created a single replace action with
Search string: ft.
Replace string: feat.
It would have worked.
If you want to use a regular expression and look at the word only, you would have to supply criteria that tell the expression where a word starts. Is it a space character? A bracket? Punctuation?
You would have to add these separators to your regular expression which would lead to just as much effort as writing single simple replace actions.
But hasn't a similar problem been discussed with you already in
> [@Using TAG in actions/combining actions for different tags](https://community.mp3tag.de/t/using-tag-in-actions-combining-actions-for-different-tags/42419/7):
>
> I think I read somewhere that it is recommended to replace a space within any regex with something else to make it clear that it is intended to be a space, can you please tell me what that would be? I can't remember or find anything related. Is it \s?? For example: [#6] T=2 ! Remove Album= F=ALBUM 1= (Album) 2= 3=0 to [#6] T=2 ! Remove Album= F=ALBUM 1=\s?(Album) 2= 3=0 If so, is this correct as an example of what you said to replace the following? [#6] T=2 ! Remove Album= F=ALBUM 1= (Albu…
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [February 11, 2019, 7:51am UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/5 "2019-02-11T07:51:23Z")
> [@sheepdisease](#):
>
> That online tool looks good, could you please explain how I would input my example into it to test it? I'm not sure.
.
BTW: Do you remember your post [Replay gain code - #4 by LyricsLover](https://community.mp3tag.de/t/replay-gain-code/42347/4)
---
### Author:  [@sheepdisease](https://community.mp3tag.de/u/sheepdisease)
#### Post date: [February 11, 2019, 2:15pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/6 "2019-02-11T14:15:56Z")
Thank you both for your replies. I see exactly what you mean.
[ohrenkino] Your explanation makes perfect sense and I see where I have got into difficulties as a result. It's a lack of understanding the difference between how a standard replace and regex replace works and must contain diifferent formatting.
I think that the best approach would be individual standard replacements as you have suggested and restricting to filename, title and artist fields to be safe.
I think that the tool [LyricsLover] has mentioned will really help me understand what is going on, that being said, looking back at the Replay gain code thread referred to does remind me of the useful diagram posted before.
I have overcomplicated the matter by misunderstanding the correct usage of either function and how they respond to input.
---
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [February 11, 2019, 4:18pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/7 "2019-02-11T16:18:03Z")
> [@sheepdisease](#):
>
> It's a lack of understanding the difference between how a standard replace and regex replace works and must contain diifferent formatting.
If you want to learn abot the usage of regex:
There are a lot of tutorials on the web which teach you step for step.
Just search for "regex tutorial".
---
### Author:  [@sheepdisease](https://community.mp3tag.de/u/sheepdisease)
#### Post date: [February 14, 2019, 8:22pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/8 "2019-02-14T20:22:37Z")
Following on from this, it seems that this is the best solution:
Field:
`Artist, _Filename & Title`
Regular expression:
```
(?i)(\s)f(?:ea)?t(?:(?:\.?|\s)|uring)(?=\s)
```
Replace matches with:
`$1feat.`
---
### Author:  [@sheepdisease](https://community.mp3tag.de/u/sheepdisease)
#### Post date: [February 16, 2019, 10:59pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/9 "2019-02-16T22:59:04Z")
After further testing, I am not sure why but there does appear to be a problem.
This screenshot shows that the regex mentioned above adds unexpected data to the fields:
```
$!
```
Do I replace this with a simple space and will that have the desired effect?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 18, 2019, 8:04am UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/10 "2019-02-18T08:04:14Z")
The screendump does not show the source fields.
I would suspect that there is no match as e.g. the filename does not have a space in front of the various "feat" strings.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:27pm UTC](https://community.mp3tag.de/t/unexpected-behaviour-when-replacing-variations-of-feat/44478/11 "2026-02-09T12:27:54Z")