# Testing mp3tag behaviour

**URL:** <https://community.mp3tag.de/t/testing-mp3tag-behaviour/42469>\
**Category:** Support\
**Created:** [July 26, 2018, 7:12pm UTC](https://community.mp3tag.de/t/testing-mp3tag-behaviour/42469 "2018-07-26T19:12:14Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [July 27, 2018, 8:41am UTC](https://community.mp3tag.de/t/testing-mp3tag-behaviour/42469/4 "2018-07-27T08:41:09Z")

</div>

> [@sheepdisease](#):
>
> $replace(%ALBUMARTIST% === %ARTIST% === %ARTISTS%,'^(abba|adda|ab

I suggested before that you should test your expressions with the Convert\>Tag-Tag function.  
The example that you give mixes IMHO the syntax for regular expressions and a normal replace. So it would be better to give an example that has been tested.  
The field ARTISTS is a user-defined field and no standard field - this could be intentional or not, I don't know, it just strikes me.

> [@sheepdisease](#):
>
> so looked through the data folder

I am not sure what you saw in the data folder but this is by far not the complete list of fields nor does it mean that \_DIRECTORY is actually part of the tag data that goes with the file. As soon as you move the file, you get new data in this pseudo-field, something that should not happen to ordinary field data.

---

_[View the full topic](https://community.mp3tag.de/t/testing-mp3tag-behaviour/42469)._