# Listing all tagged fields in the tag panel

**URL:** https://community.mp3tag.de/t/listing-all-tagged-fields-in-the-tag-panel/71949
**Category:** Support
**Created:** [October 11, 2026, 5:26pm UTC](https://community.mp3tag.de/t/listing-all-tagged-fields-in-the-tag-panel/71949 "2026-10-11T17:26:58Z")
**Posts on this page:** 1
**Showing post:** 9

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [October 16, 2026, 11:18pm UTC](https://community.mp3tag.de/t/listing-all-tagged-fields-in-the-tag-panel/71949/9 "2026-10-16T23:18:05Z")

</div>

### 1 Unicode vs. 5 ANSI

> [@7stones](#):
>
> I don't use unicode in my scripts is that I don't like surprises when I use them on various computers.

Agreed in general, but since this is an Mp3tag internal use case that works regardless of whether the user font is able to display the character/emoji, I do not see any risk here.

> [@7stones](#):
>
> I don't think the length of `‹†×‡›` has any impact on performance.

Real world impact? Probably not. But it's easier to create a negated character class `[^🦖]` to match anything but the delimiter than to do the same with `‹†×‡›` since `[^‹†×‡›]` does not match the delimiter whole and instead matches each symbol it consists of. So you have  
a) 5 comparisons instead of one per character in the string and  
b) 5 times the risk of the character actually being part of a legitimate tag.  
Or if you use lookarounds it's more complex, verbose and often requires more comparisons as well.

### Uppercase tag names

> [@7stones](#):
>
> my field names are all upper case, so I don't need to correct that.

I thought so too, but Mp3tag automatically displays tag names as uppercase in the Extended Tags window. I was a bit surprised to see non-uppercase tag names when using `$list()`. My own rips done with dBpoweramp for example don't have uppercase tag names.

```hex
00000110 65 33 38 30 63 2d 31 25 00 00 00 54 69 74 6c 65 |e380c-1%...Title|
00000120 3d 44 61 72 6b 20 43 6c 6f 75 64 73 20 57 69 74 |=Dark Clouds Wit|
00000130 68 20 53 69 6c 76 65 72 20 4c 69 6e 69 6e 67 73 |h Silver Linings|
00000140 25 00 00 00 41 6c 62 75 6d 3d 44 61 72 6b 20 43 |%...Album=Dark C|
00000150 6c 6f 75 64 73 20 57 69 74 68 20 53 69 6c 76 65 |louds With Silve|
00000160 72 20 4c 69 6e 69 6e 67 73 09 00 00 00 44 61 74 |r Linings....Dat|
00000170 65 3d 31 39 39 35 0e 00 00 00 53 74 79 6c 65 3d |e=1995....Style=|

```

### Feedback

> [@7stones](#):
>
> Some may not like it, but it gives you perfect columns - and it's very easy to edit this last part of the script if/when new special cases arise.

The only one who has to like it is you. I also thought about using abbreviations but decided against it because I process files from many sources with a huge variety in tags (some are nightmare fuel).

I crafted my version specifically to have a one glance overview into what I'm dealing with without having to open and close the Extended Tags window each time. If exotic tags I'm about to delete aren't displayed properly, I don't care. With the alternation in my version I can align all tags that I deem useful/standard perfectly and the majority of exotic tags are displayed well enough.

> [@7stones](#):
>
> I'm fully satisfied with the handling of line breaks.

Your new version looks clean, good job!

### v2.0 and my continued descend into madness

After reviewing my [breakdown](https://community.mp3tag.de/t/listing-all-tagged-fields-in-the-tag-panel/71949/6#p-245761-breakdown-1) with a fresh head I noticed some superflous/redundant steps and also that my regexes highly depend on the result of the previous regex, making them less modular and harder to understand than I'd like.  
Which _naturally_ lead to me overhauling my entire approach.

v2.0 (because of 🦕 and 🦖):  
Field: `_FORMAT`  
Name: `List of fields`  
Value:

```auto
$replace($regexp($regexp($regexp($regexp($sort($regexp($list(🦕,:$repeat($char(9),4),🦖,\\),(?<=🦕)('['a-zA-Z_ #\d']'+:\t++(?='['^🦖']'{68})'['^🦖']'{67})'['^🦖']'*,$1…),🦖),\r?\n,↵),(?<=🦕)('['^:']'{1','31})(:\t+'['^🦖']'{1','36})(?=🦖),\U$1\E$2\r\n),(?|(?<=🦕)('['a-zA-Z_ #\d']'{32','}:)\t+('['^🦖']'+)(?=🦖)|(?<=🦕)('['a-zA-Z_ #\d']'+:)\t+('['^🦖\n']'{36','}))(?=🦖),\U$1\E\r\n $2\r\n),(?<=🦕)(?|(LYRICIST:\t{4})\t*|(COMMENT:\t{3})\t*|('['A-Z_ #\d']'{1','7}:\t{4})\t*|('['A-Z_ #\d']'{8','16}:\t{3})\t*|('['A-Z_ #\d']'{16','23}:\t{2})\t*|('['A-Z_ #\d']'{24','30}:\t)\t*|('['A-Z_ #\d']'{31}:)\t*),$1),🦕,,🦖,)

```

Type: `Multiline`  
Rows: `3`

This yields 1:1 the same result as the first version I posted unless the tag name contains `0-9` or `#`, in which case this version ought to work better. I also do not notice a difference in display speed (although this version is even more verbose).

> **Breakdown v2.0**
>
> The main difference in this approach is that I didn't use a T-Rex as the sole delimiter, but instead wrapped each tag name-value pair into an opening Sauropod and a closing T-Rex, retaining this clear separation all the way to the last step, which makes reviewing intermediate results easier and also improves the flexibility of the steps. I also reordered the alternation from short to long since it technically requires fewer steps this way, but there's no way that would be noticeable. Another change is that tag names can now contain `a-zA-Z_ #\d` to allow for things like `ALBUMARTIST2` or `CATALOG #`. I might add more symbols if I encounter tags in the wild that contain them.
> 
> Field: `TEST1`  
> Format string:
> 
> ```auto
> $list(🦕,:$repeat($char(9),4),🦖,\\)
> 
> ```
> 
> Creates the initial tag-value pairs, separated by `:` and 4 tabs, wrapped into 🦕 and 🦖.
> 
> Field: `TEST2`  
> Format string:
> 
> ```auto
> $sort($regexp(%test1%,(?<=🦕)('['a-zA-Z_ #\d']'+:\t++(?='['^🦖']'{68})'['^🦖']'{67})'['^🦖']'*,$1…),🦖)
> 
> ```
> 
> Trims tag values that are longer than 67 chars, appends `…` when a value was trimmed and sorts the result alphabetically.
> 
> Field: `TEST3`  
> Format string:
> 
> ```auto
> $regexp(%test2%,\r?\n,↵)
> 
> ```
> 
> Replaces both Windows and Linux style newlines in tag values with `↵`.
> 
> Field: `TEST4`  
> Format string:
> 
> ```auto
> $regexp(%test3%,(?<=🦕)('['^:']'{1','31})(:\t+'['^🦖']'{1','36})(?=🦖),\U$1\E$2\r\n)
> 
> ```
> 
> Adds newlines after tag value pairs where neither the tag name exceeds 31 chars nor the tag content 36 and also converts the tag name case to uppercase.
> 
> Field: `TEST5`  
> Format string:
> 
> ```auto
> $regexp(%test4%,(?|(?<=🦕)('['a-zA-Z_ #\d']'{32','}:)\t+('['^🦖']'+)(?=🦖)|(?<=🦕)('['a-zA-Z_ #\d']'+:)\t+('['^🦖\n']'{36','}))(?=🦖),\U$1\E\r\n $2\r\n)
> 
> ```
> 
> When tag value or name exceed the length limits, this moves the value to a new line, prepends 8 spaces and also converts the tag name case to uppercase.
> 
> Field: `TEST6`  
> Format string:
> 
> ```auto
> $regexp(%test5%,(?<=🦕)(?|(LYRICIST:\t{4})\t*|(COMMENT:\t{3})\t*|('['A-Z_ #\d']'{1','7}:\t{4})\t*|('['A-Z_ #\d']'{8','16}:\t{3})\t*|('['A-Z_ #\d']'{16','23}:\t{2})\t*|('['A-Z_ #\d']'{24','30}:\t)\t*|('['A-Z_ #\d']'{31}:)\t*),$1)
> 
> ```
> 
> This handles the actual formatting/padding. Depending on the length of the tag name, the 4 initially added tab characters are partially removed to adjust the padding.
> 
> The numbers I use come from me creating test tags with `Z` (medium size uppercase) letters from 1 `Z` all the way to 31 `ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ`s and noting down how many tabs were required to align the tag values in Mp3tag.  
> This depends on the font used and can vary from tag name to tag name. `COMMENT` for example did not fit, which is why I added a specific match for it. As long as the specific case comes before the general case in the alternation, outliers can be fixed this way.
> 
> Field: `TEST7`  
> Format string:
> 
> ```auto
> $replace(%test6%,🦕,,🦖,)
> 
> ```
> 
> This removes the opening Sauropod and the closing T-Rex at last.
> 
> Test actions for v2.0. Rename it if you want to keep/compare both version.  
> [\_\_ALLFIELDS\_TESTS.mta](https://community.mp3tag.de/uploads/short-url/zYA4AyKp2Dyg02HgLzEN6tuYxU5.mta) (1.1 KB)

### Additional idea while writing this

Instead of showing all tags, yet another regex could be used to filter out tag-value pairs that are already present as normal fields in the tag panel (title, artist, album, year etc.). That way instead of showing all tags, it could only display "invisible" (without opening the Extended Tags window) tags.  
Perhaps I'll try that another day. Sadly I'm out of dinosaur emojis for a v3.0.

---

_[View the full topic](https://community.mp3tag.de/t/listing-all-tagged-fields-in-the-tag-panel/71949)._