• Registered: 2011-12-05

Topic: Identical tag mismatches

I'd like to use the plugin "Remove Perfect albums", but I'm having problems as I'm also writing null separated Genre and Mood fields to my UTF-16 ID3v2.4 tags.

My issue is that Picard is reading the mood and genre fields in a different order to the order they're written to the tag - it seems to be rearranging the values in alphabetical order. I'm writing the tags in a specific order, most relevant to least relevant, in case any media players only read the first value. Therefore I'd like to keep the tag order as I choose, and not rearrange my tags alphabetically.

However, this means that Picard sees the two identical tags as different. As an example, here are the values I'm writing to the Genre field of Autechre's Confield:

Experimental; Ambient; IDM; Electronica; Glitch

And here are the values shown in the "Original Value" column when I re-read the files:

Ambient; Electronica; Experimental; Glitch; IDM

There are also a couple of other slight problems that I'd love to see addressed:

1) The format of the genre and mood separated tags is different between the Original Value and New value columns in Picard. The Original Value column shows a semi-colon separated list, and the New Value column shows the values concatenated. To re-use the example above, what I actually see in the New Value column is:

ExperimentalAmbientIDMElectronicaGlitch

2) The Length field frequently doesn't match between the Original Value and New value columns. This doesn't seem to affect the Remove Perfect Albums plugin, but it is annoying when scanning files by eye to see this data row highlighted on most of my tracks.

How would I go about getting these problems fixed?

  • From: Singapore
  • Registered: 2007-02-13

Re: Identical tag mismatches

Well, more generally you'd create tickets at http://tickets.musicbrainz.org/browse/PICARD with as many details to reproduce as possible. Like most things, it's much more likely to be fixed/changed if you've made it easy to see the problem and reproduce with specific instructions, MB release links to tag against, example files etc.

Or submit a patch yourself :-)

0) I don't believe Picard should be changing the tag order that's defined when re-reading files, but if it is intentionally doing this to normalise both sides of the comparison - and we change it - it will mean a great more people will see differences when they re-tag since the alphabetised tag values may then not match the order they are coming back from MB or last.fm+ plugin or wherever. So this may not be able to addressed. Not sure though; you can always create a ticket and we can try and work out what the intended behaviour is.

The other alternative may be to just make the comparison for highlighting ignore the order by default or something like that, but make it configurable. Not sure.

1) Looks like you might be populating the metadata incorrectly for a multi-valued field. (here, right?) If you want Picard to properly handle your multi-valued fields across the UI you should set it as a list of strings in the metadata - not try and insert the separator yourself. Otherwise how can Picard know what your separator is? Picard/mutagen will handle how to write that in a format-agnostic way.

2) This can be caused by a lot of things; including imperfect data in MB (you can correct the data), minor rounding issues (unavoidable) but also by MP3s with bad encodings/invalid VBR headers that cause the length to be calculated incorrectly. Do you have a specific file/example where you think Picard has got it wrong? Or do you really want some kind of configurable tolerance for the length field before highlighting a difference? (e.g. +/- 2 seconds)

voiceinsideyou's Website

  • Registered: 2011-12-05

Re: Identical tag mismatches

Wow, once again thanks for the quick reply, voiceinsideyou! It's great that you're always there to help.

0) If Picard was consistent and alphabetised the list on both sides, that would be a start. I'd still say that it's better to not re-arrange the list, though, on either side - especially the Original Value side. I've checked and can confirm that Picard is saving the values in the order I want, so the tag is in the correct order. It's just that Picard mis-reports the tag values by re-arranging them after it's read them. It'd be great to see this fixed, so I'll submit a ticket later this evening. As you say, another option would be to just make sure that the same values are on both sides, and not compare the order.

1) Wow,being able to use a list for a metadata tag is a feature I didn't know existed - and a very handy one. I'll implement that in my code asap.

2) Yeah, maybe a tolerance of a few seconds in track length would be good. As I said, this one is okay as it doesn't cause any problems with comparing tags, it just rubs my OCD up the wrong way.

  • From: Singapore
  • Registered: 2007-02-13

Re: Identical tag mismatches

I'm a Kiwi, that's what we do... right? ;-)

0) Hmm okay - well probably not intentional then. It seems to warrant further investigation/explanation so maybe open a ticket.

1) Yah, that's why we have all the $*multi functions now in tagger script: http://musicbrainz.org/doc/MusicBrainz_ … /Scripting - to help people script around these lists; transform the data in them etc.

2) Can you create an enhancement ticket?

voiceinsideyou's Website

  • Registered: 2011-12-05

Re: Identical tag mismatches

As a recently naturalised Kiwi (English by birth), I suppose I really should agree with you!

I'll submit a couple of tickets, for 0) and 2).

Cheers!