# \[X\] ID3v2 TXXX tags in »Extended Tags« not shown as are
**URL:** https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337
**Category:** No Bugs
**Created:** [October 16, 2008, 4:56am UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337 "2008-10-16T04:56:01Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [October 16, 2008, 4:56am UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/1 "2008-10-16T04:56:01Z")
While debugging a quirk with SAM Broadcaster (a radio automation software), I realized that TXXX type ID3v2 frames are always shown with an UPPERCASED tag name in the »Extended Tags« view.
This poses a problem since one cannot distinguish between tags like these:
**TXXX{0}XFade{0}&bmp=125,00**
and
**TXXX{0}XFADE{0}&bmp=125,00**
It took me a while to find this out (using advanced stream editors), phew! And that was also my problem: I generated a tag _XFADE_ while it should have been called _XFade_ …
Also, in specifying actions it’s not even _possible_ to enter a field name like »XFade« since it gets uppercased while inputting. (Examples: »Format Value«, »Replace«)
Could we please have the TXXX tag names shown _as they are_ instead of having them uppercased? At least for the »Extended Tags« view?
And get the possibility to _enter_ them as needed (i.e., »XFade« instead of »XFADE«)?
The ID3v2 spec clearly states the »Description« (i.e. tag name of a TXXX tag) is »text string according to encoding«—this definitely includes _any_ character displayable in the selected encoding. So lowercase letters and other characters are probably seldom used, but perfectly legal.
Btw, _editing_ the existing tag _XFade_ re-wrote it as _XFADE_. When _creating_ a new _XFADE_ tag in a file that already contains an _XFade_, you’ll end up with _both_ tags in the file, in »Extended Tags« shown as _two_ entries, both labelled _XFADE_.
I am using MP3Tag v2.41 and have attached a sample (which also contains some other mixed-case tags generated by SAM Broadcaster v4.2.2).
[Moonbase\_\_\_XFADE\_vs.\_XFade\_Beispiel.zip](https://community.mp3tag.de/uploads/default/original/2X/6/604ca0267d777dca4664b20ea4e6840cb424f481.zip) (1.98 KB)
---
### Author:  [@dano](https://community.mp3tag.de/u/dano)
#### Post date: [October 16, 2008, 8:38am UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/2 "2008-10-16T08:38:37Z")
This is just a quick note, there are several ways to change the capitalization of TXXX descriptions:
[/t/2479/1](https://community.mp3tag.de/t/2479/1)
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [October 16, 2008, 2:11pm UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/3 "2008-10-16T14:11:31Z")
Thanks for the hint. I didn’t realize it was a problem since 2005! When will it be changed?
(Because all these workarounds of course dont’t solve the problem of _usability_, i.e., creating/modifying actions, column view, distinguishing between uppercase and mixed-case fields, … And MP3Tag, as I understand, should be a tool for _users_, not code-hacking freaks—meaning: I could _never_ get a »normal« user to handle all this »pathcing here, modifying there«—they just want to work on their TAGS.)
Changing some \*.mta files helped, _until_ I had to change the »XFade« field in »Extended Tags«—it promptly reverted back to »XFADE«.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [October 16, 2008, 2:33pm UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/4 "2008-10-16T14:33:14Z")
> [@Moonbase](#):
>
> ... And MP3Tag, as I understand, should be a tool for _users_, not code-hacking freaks ...
If so then Mp3tag should only display the Tag Panel view - not more anything else!
Uhh, what is this - a tag panel view - never used it before - where can I find it - do you know a workaround ... ?
DD.20081016.1832.CEST
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [October 16, 2008, 2:56pm UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/5 "2008-10-16T14:56:40Z")
No sarcasm needed—I always valued and recommended MP3Tag as _the_ tagging tool for _both_ the »technical« as well as the »normal« user. One of the big advantages of MP3Tag is that it handles (almost) anything and can be made _simple enough_ for the average user (that has other work to do and just needs to TAG stuff, maybe using some actions others wrote) _as well as being sophisticated enough_ to fullfill about 90-95% of the work a »more technical« user has to do.
Please understand my problem: _I myself_ could probably find a way to work around _everything_, it’s just a matter of time, usability and—in my case—also of having to train »average« users into a workflow that should include MP3Tag as their main tagging tool. It’s about _Getting Things Done_ for them, not about »how to be a technician«. _They_ just need to get their files tagged adhering to some standards, so they can be archived, broadcast, and generally be used in a »seamless« workflow—without having to have »specialists« to repair each and every file before it is »usable«.
I think MP3Tag is a wonderful tool to do just that—get things done. And it has served this purpose for many years, beautifully.
One of the big advantages is that the MP3Tag team used to be responsive to user input, and somehow always found a way to improve MP3Tag, adapt it to whatever the »world« (other software) came up with, be it crap or not. Maybe first with a workaround (like dano just did), but eventually always with a fine solution. And I still regard MP3Tag as _the_ one tool that _is_ most flexible and can handle most awkward tagging situations.
Unfortunately, there are so many possibilities of doing things different than we would like to have it, and mixed-case tags are just one of these. All I’m asking for is that maybe we get support for these kind of tags. Be it only to have MP3Tag stay ahead of the crowd and keep its position as #1.
Now how does the community feel about this?
(And yes, DetlevD, I’m also sometimes awfully fed up with Pisa kid stupidity …)
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [October 16, 2008, 4:40pm UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/6 "2008-10-16T16:40:02Z")
Just to confirm dano:
For the time being, I put the »XFade« tag into usrfields.ini (works only if edited in tag panel), and manually edited some \*.mta action files.
This setup works as long as
- _only_ the _edited actions_ or the _tag panel field_ are used to change the value,
- one does _not_ change the field value in column oder extended tag view,
- one does _not_ change the text for the tag panel field »XFade«
- one does _not_ try to modify any actions using »XFade«
Quick hack, works (with a lot to keep in mind) for now, and here.
_Question:_ Is it possible to send colleagues just the _\*.mta_ and _usrfields.ini_ files and have them copy these into their _Application Data/Mp3tag/…_ folder? Would that work so they wouldn’t have to enter all that stuff?
In case someone wants further testing, I append a sample MTA that updates the XFade tag from a (fractional, Mixmeister-generated) TBPM tag, then rounds BPM to the next integer and re-saves it. (All this stuff is needed to seamlessly integrate with SpacialAudio’s SAM Broadcaster.)
[For\_SAM\_\_\_Update\_XFade\_from\_fractional\_BPM\_\_round\_BPM\_to\_Integer.mta](https://community.mp3tag.de/uploads/default/original/2X/c/c7ef9b9bbba04c3c97b7c1f9183351fbf6d3b26f.mta) (469 Bytes)
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 17, 2008, 5:08am UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/7 "2008-10-17T05:08:27Z")
I've marked this post as **No Bug** because simply providing a view on the metadata in the file that does not reflect the contents one by one seems to be no problem for me. It's the way it works.
With Mp3tag I always try to balance between the different needs of the different user groups. Easy things like changing the artist or adding a cover should be easy, difficult things like calculating soundcheck tags from ReplayGain data require some more effort.
It's the same with this issue.
You say
> [@Moonbase](#):
>
> MP3Tag, as I understand, should be a tool for _users_, not code-hacking freaks
This is not entirely true -- it should be a tool for both of them.
> [@Moonbase](#):
>
> _Question:_ Is it possible to send colleagues just the _\*.mta_ and _usrfields.ini_ files and have them copy these into their _Application Data/Mp3tag/…_ folder? Would that work so they wouldn’t have to enter all that stuff
Sure, it's a portable format designed for ease of use 😉
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [October 17, 2008, 9:28am UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/8 "2008-10-17T09:28:29Z")
> [@Florian](#):
>
> This is not entirely true -- it should be a tool for both of them.
I agree—100%. (And you’ve managed extremely well!) 🙂
So may I take the chance to kindly ask for turning this into a »Feature Request«?
I _do_ understand the idea behind the »all uppercase tag handling« as it is now: Reduce the possibility of user error. And I agree, regarding the average user who just wants to tag efficiently.
Maybe one could have some _[\_] Allow case-sensitive tags (caution!)_ option for those of us who need this, and deliver with that option turned off as default?
---
### Author:  [@Moonbase](https://community.mp3tag.de/u/Moonbase)
#### Post date: [October 17, 2008, 9:41am UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/9 "2008-10-17T09:41:19Z")
> [@Florian](#):
>
> […\*.mta…] Sure, it's a portable format designed for ease of use 😉
Feedback: Just tried it out, making some MTAs read-only and just dropping them into _%APPDATA%\Mp3tag\data\actions\ (via a batch file) helps: They appear in the user’s action list at the bottom and cannot be accidentally changed (since read-only). Good thing._
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:24pm UTC](https://community.mp3tag.de/t/x-id3v2-txxx-tags-in-extended-tags-not-shown-as-are/7337/10 "2018-12-28T14:24:26Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.