Tag Field Titles mA4, MP3 Capitalisation

General Discussion
1

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

2

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, 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.

image
image693×628 19.7 KB

AFAIK this follows the standard for different music formats.

3

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

$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.

4

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

5

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.

6

hi,
this is picard script....

7

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

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.

8

some music player excpect those characters i read somewhere, so i going use the standards to avoid problems