mediafile saves track to multiple vorbis comment fields

[aereaux]

Simple reproduction:

Get empty file:

$ ffmpeg -f lavfi -i 'anullsrc=channel_layout=5.1:sample_rate=48000' -t 1 file.flac

Write track field

>>> from mediafile import MediaFile
>>> f = MediaFile('file.flac')
>>> f.track
>>> f.track = 1
>>> f.save()
>>> f.track
1

View result

$ metaflac --list "file.flac"
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4608 samples
  maximum blocksize: 4608 samples
  minimum framesize: 26 bytes
  maximum framesize: 28 bytes
  sample_rate: 48000 Hz
  channels: 6
  bits-per-sample: 16
  total samples: 48000
  MD5 signature: 0dd0e989e9556334ac746c39d72d6aea
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 116
  vendor string: Lavf58.76.100
  comments: 4
    comment[0]: encoder=Lavf58.76.100
    comment[1]: WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x3f
    comment[2]: TRACK=1
    comment[3]: TRACKNUMBER=1
METADATA block #2
  type: 1 (PADDING)
  is last: true
  length: 8164

Specifically the TRACK and TRACKNUMBER fields. This is the case in all the files in my collection that are managed by beets. I haven't noticed this before, but I recently switched to ncmpc (for mpd), and noticed that the %track% format specifier outputs 1, 1. I saw this issue (https://github.com/MusicPlayerDaemon/ncmpc/issues/71) and asked about it in the #mpd irc channel, where they said the problem was with my files having multiple track tags. I don't know how standardized the tag keys are, or where this bug belongs, but I'm filing this issue if it should be fixed here.

Side note: I also noticed this happens for a couple other fields like disc number as well

[sampsyo]

Hi there! Yes, this is actually intended behavior—a consequence of MediaFile's aim to maximize compatibility with a "read any, write all" policy. There's much more discussion in https://github.com/beetbox/beets/issues/350. In short, it seems like most software is content to just show one value if multiple "tag mappings" are present, but ncmpcpp (and apparently ncmpc? Apparently they are more similar than I thought) is a notable exception.

[aereaux]

Ah thanks, I did not find that beets issue when I was looking into this. It sounds like the consensus was that a strict_tags option would be accepted? And that that would require some work in mediafile? I might take a look into implementing that if I get a chance.

[sampsyo]

Yes and yes! It would be great to have help with that. It would indeed need to start with an option on MediaFile itself, which would work similarly to the current id3v23 flag. I'm worried it might be a little tricky to "plumb through" to all the fields correctly, but hopefully it's not too bad.

[aereaux]

OK, thanks for the info. I have for now switched back to ncmpcpp (which has a config option to ignore duplicates) because I figured out how to configure columns there, so I'm not sure when/if I'll get a chance to look at this. It's still on my list for now, though

[jaum20]

I also noted this beahavior with albumartist, which is set for three different fields:

comment[4]: ALBUM ARTIST=Yes
comment[5]: ALBUM_ARTIST=Yes
comment[6]: ALBUMARTIST=Yes

and mediainfo shows:

Album/Performer : Yes / Yes