# Tag Field Titles mA4, MP3 Capitalisation
**URL:** https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122
**Category:** General Discussion
**Created:** [July 16, 2025, 11:55pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122 "2025-07-16T23:55:48Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@shyfx](https://community.mp3tag.de/u/shyfx)
#### Post date: [July 16, 2025, 11:55pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/1 "2025-07-16T23:55:48Z")
Hi,
I got a question...
When writing a new field ABC with value xxx in Mp3tag...:
In Mp3tag the field reads ABC value xxx
In Picard the field for mp3 tracks i read ABC, but for the same field in MA4 it read abc.
When creating in picard field ZZZ and yyy for MA4, in Mp3tag the fields read:
ZZZ and YYY, in picard are those ZZZ and yyy (like I created those fields)
For one reason or another, it looks like Mp3tag write the field in capital characters for mP3 and in lower characters for MA4.
What is the logic behind this? (a standard or something?)
The issue for me when scripting in picard, that Picard make a difference between %ABC% and %abc% when using a field.
when execute script:
$if($eq(%ABC%,xxx),$set(test,yes),$set(test,no))
it will only put yes for mp3 tracks and no for all mA4 tracks.
$if($eq(%abc%,xxx),$set(test,yes),$set(test,no))
it will only put yes for mA4 tracks and no for all mp3 tracks.
How can I deal and fix this?
thnx
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [July 17, 2025, 6:04am UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/2 "2025-07-17T06:04:47Z")
You need to differentiate between what Mp3tag shows in Alt + T (internal field names are always presented in UPPERCASE) and what is written into your music files.
If you look at this official field `ALBUM` [as example](https://docs.mp3tag.de/mapping/#album), you see, that for the music format MP3 the field name `TALB` is written in UPPERCASE letters into your music files, but `@alb` for MP4 (and m4a) is written in lowercase.
The representation in Mp3tag Alt + T is ALBUM for all different field types.
AFAIK this follows the standard for different music formats.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [July 17, 2025, 6:11am UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/3 "2025-07-17T06:11:08Z")
> [@shyfx](#):
>
> How can I deal and fix this?
I'm not an MB Picard expert, but if you need to deal with m4a and MP3, I would suggest to use both MB Picard scripting lines
```auto
$if($eq(%ABC%,xxx),$set(test,yes),$set(test,no))
$if($eq(%abc%,xxx),$set(test,yes),$set(test,no))
```
Alternatively, you could check for which extension (.m4a or .mp3) you want to apply which line with something like this MB Picard scripting syntax:
`$if($eq(%_extension%,m4a),...`
For a more solid solution, you should ask the question 'How do I deal with...' in the [MB forum](https://community.metabrainz.org/).
---
### Author:  [@shyfx](https://community.mp3tag.de/u/shyfx)
#### Post date: [July 18, 2025, 1:31pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/4 "2025-07-18T13:31:09Z")
Indeed,
it is about the standards for different extentions.
I did had time today to dig a little deeper....
You have:
ABC for Mp3
abc for Ma4
Abc for (don't recall format)
So i have to write multiple/duplicate sets of rules that start with...
$if($and($in(%artist%,%100%),$eq(%\_extention%,MP3)),....
$if($and($in(%artist%,%100%),$eq(%\_extention%,m4a)), ....
and possible one for MP4 too.
I did see on the forum from Musicbrainz some people end up with double tags for 1 field... (ARTIST & artist)
thnx
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 18, 2025, 2:00pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/5 "2025-07-18T14:00:25Z")
> [@shyfx](#):
>
> `$if($and($in(%artist%, ....`
Please note that this is no valid MP3tag syntax.
So I think that your problem is really one that should be addressed with the Musicbrainz support as MP3tag takes care to write the correct tokens/atoms/etc. into the file types which in return have to be interpreted by the reading program.
It should not matter at all which way an internal field name appears in MP3tag.
---
### Author:  [@shyfx](https://community.mp3tag.de/u/shyfx)
#### Post date: [July 18, 2025, 3:29pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/6 "2025-07-18T15:29:53Z")
hi,
this is picard script....
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 18, 2025, 3:33pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/7 "2025-07-18T15:33:20Z")
> [@shyfx](#):
>
> this is picard script
It's a little strange to post such code without a corresponding comment.
Is there a special (technical) reason why field names should be identifiable in respect to the case?
Or doesn't it basically matter?
If it does not matter, then I would suggest that you try an action of the type Case Conversion for \_FIELDNAME
> **[Case Conversion – Mp3tag Documentation](https://docs.mp3tag.de/actions/case-conversion/)**
>
> Documentation on the Case Conversion action type that can be performed as Quick Action or as reusable workflow from Action Groups. Mp3tag is the universal Tag Editor.
and see if you get standardized fieldnames out of it.
I would apply that action to all files and then proceed with the standardized names.
---
### Author:  [@shyfx](https://community.mp3tag.de/u/shyfx)
#### Post date: [July 18, 2025, 3:51pm UTC](https://community.mp3tag.de/t/tag-field-titles-ma4-mp3-capitalisation/69122/8 "2025-07-18T15:51:31Z")
some music player excpect those characters i read somewhere, so i going use the standards to avoid problems