Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

Topic: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files (Read 611 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

2024-05-20 09:23:20

I have tagged some M4A files with Musicbrainz Picard. The Performer tag contains multiple values. Picard wrote all of the tags correctly, but foobar2000 only shows the last of the Performer values. I made a copy of one of the M4A files, wrote the Performer tag with foobar2000 and compared the files with AtomicParsley.

The only difference I can see is the case: "performer" vs "PERFORMER". Is this expected behaviour? (I should note that I'm using foobar2000 for Mac, latest preview version.)

Picard:

Code: [Select]

# AtomicParsley 01\ Overture_\ Lore.m4a -t  
Atom "©nam" contains: Overture: Lore
Atom "©ART" contains: 古川毅
Atom "©wrt" contains: 古川毅
Atom "©alb" contains: 人喰いの大鷲トリコ
Atom "©gen" contains: Video Game Soundtrack
Atom "trkn" contains: 1 of 24
Atom "©day" contains: 2016
Atom "----" [com.apple.iTunes;performer] contains: London Symphony Orchestra
Atom "----" [com.apple.iTunes;performer] contains: Trinity Boys Choir
Atom "----" [com.apple.iTunes;performer] contains: London Voices
Atom "aART" contains: 古川毅
Atom "soaa" contains: Furukawa, Takeshi
Atom "soar" contains: Furukawa, Takeshi
Atom "soco" contains: Furukawa, Takeshi
Atom "soal" contains: Hito-kui no Oowashi Toriko
Atom "covr" contains: 1 piece of artwork

foobar2000:

Code: [Select]

# AtomicParsley 01\ Overture_\ Lore\ copy.m4a -t
Atom "trkn" contains: 1 of 24
Atom "©gen" contains: Video Game Soundtrack
Atom "©day" contains: 2016
Atom "©nam" contains: Overture: Lore
Atom "----" [com.apple.iTunes;PERFORMER] contains: London Symphony Orchestra
Atom "----" [com.apple.iTunes;PERFORMER] contains: Trinity Boys Choir
Atom "----" [com.apple.iTunes;PERFORMER] contains: London Voices
Atom "soco" contains: Furukawa, Takeshi
Atom "©wrt" contains: 古川毅
Atom "soar" contains: Furukawa, Takeshi
Atom "©ART" contains: 古川毅
Atom "soal" contains: Hito-kui no Oowashi Toriko
Atom "soaa" contains: Furukawa, Takeshi
Atom "aART" contains: 古川毅
Atom "©alb" contains: 人喰いの大鷲トリコ
Atom "covr" contains: 1 piece of artwork

Re: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

Reply #1 – 2024-05-20 09:48:57

According to this...

https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#performer

Picard doesn't even write performer to m4a files. I've tested this in the past on windows but not checked recently. I guess the page could be outdated???

I know for sure foobar2000 can't read the TCML/IPLS id3 frames Picard writes to mp3 files. If you ask fb2k to write performer, it uses TXXX frames.

edit: I tested the windows version of picard and it seems to match the behaviour I linked to above - they're not written. Testing an mp3 copy of the same album does get written so the performer entries are definitely there for the release I'm testing.

Re: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

Reply #2 – 2024-05-23 05:50:16

That's not my experience. Picard writes performer tags to my M4A files, even if that is not advertised in their mapping table. The atoms are there as the output from AtomicParsley in my initial post shows.

But I checked the files now with another tool, mp4dump, and I can finally see why this discrepancy arises. Picard only writes one PERFOMER tag with one data element per value:

Code: [Select]

        [----] size=8+173
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+33
            type = 1
            lang = 0
            value = London Symphony Orchestra
          [data] size=8+26
            type = 1
            lang = 0
            value = Trinity Boys Choir
          [data] size=8+21
            type = 1
            lang = 0
            value = London Voices
          [data] size=8+12
            type = 1
            lang = 0
            value = Test

Whereas foobar2000 writes an individual PERFORMER tag per value:

Code: [Select]

        [----] size=8+90
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+33
            type = 1
            lang = 0
            value = London Symphony Orchestra
        [----] size=8+83
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+26
            type = 1
            lang = 0
            value = Trinity Boys Choir
        [----] size=8+78
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+21
            type = 1
            lang = 0
            value = London Voices

It would be nice if foobar2000 could read Picard-tagged files as-is with regards to PERFORMER, but it seems like Picard is doing it "wrong".

Re: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

Reply #3 – 2024-05-23 10:33:24

I was too lazy to find/test atomicparsley but have tested it just now. The windows version really does not write performer - this matches the docs. I guess the mac version is different in this regard.

Even the picard UI does not show performer where it clearly does for mp3.

Obviously this is not a reason for fb2k not to read it. I guess you'll have to see if the dev notices this thread.

Re: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

Reply #4 – 2024-05-23 11:14:04

Please post a short sample file with offending tags.

Re: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files

Reply #5 – 2024-05-24 06:28:49

Here's an M4A sample file with performer tags written by Picard:

https://encl.io/t/FZF7OxitnHs#yuo0yl2Ozp3iMN12Wqqbng

The performer tag contains 3 values: Performer 1, Performer 2, Performer 3.

Notice