Show raw tag data in Extended Fields [Request]

[knowle]

I recently used the Node.js music-metadata package to automate file renaming on a large scale. I found that it was selecting a different string to what I expected for the title field. This turned out to be the result of duplicate ID3v2.4 fields, at least according to the output of music-metadata (some fields redacted):

[
  // These fields are created by Mp3tag
  { id: 'TALB', value: '<string>' },
  { id: 'TPE1', value: '<string>' },
  { id: 'TPE2', value: '<string>' },
  { id: 'TPOS', value: '1/1' },
  { id: 'TCMP', value: '1' },
  { id: 'TIT2', value: '<string: correct title>' },
  { id: 'TRCK', value: '37/37' },
  { id: 'TDRC', value: '2003' },
  {
    id: 'APIC',
    value: {
      format: 'image/jpeg',
      type: 'Cover (front)',
      description: '',
      data: <Buffer>
    }
  },
  // These fields already existed
  { id: 'TXXX:major_brand', value: 'M4A' },
  { id: 'TXXX:minor_version', value: '512' },
  { id: 'TXXX:compatible_brands', value: '<string>' },
  { id: 'TIT2', value: '<string: incorrect title>' },
  { id: 'TPE1', value: '<string>' },
  { id: 'TDRL', value: '<string>' },
  {
    id: 'TXXX:description',
    value: "<long string>"
  },
  {
    id: 'TXXX:comment',
    value: '<string>'
  },
  { id: 'TSSE', value: 'Lavf54.63.104' }
]

music-metadata is read-only, as far as I can tell, and so cannot be used to programmatically remove these extra fields. I have tried using the field mapping in Mp3tag to add, e.g., a "major_brand" field in an attempt to overwrite or remove the TXXX fields in the file. Unfortunately, Mp3tag forces "Source" values in the Field Mappings UI to uppercase, which causes a new "TXXX:MAJOR_BRAND" field to be added to the file rather than the replacing of "TXXX:major_brand".

The only way I have found to fix this metadata issue is to use the "Remove Tag" feature in Mp3tag 2–3 times to remove all fields and then add everything back manually. This is, of course, not a great solution.

I don't know whether duplicate fields or lowercase TXXX labels are even legal in ID3v2.4 or whether software should select the first or last match for a particular field when there are duplicates (Mp3tag selects the first, music-metadata selects the last). That is, I don't know if this MP3 file can be considered corrupt or not. Either way, it would be good to have a facility in Mp3tag to modify raw fields for each supported format without needing to go through the mapping system or remove every field first. I understand that this would be an advanced feature, but without this there is no way to list every ID3v1, ID3v2.3, ID3v2.4, etc. key and value pair like music-metadata can. For what it's worth, the "Extended Tags" window currently gives a false impression of being a list of every metadata field in the file, but this isn't the case.

This aside, thank-you for creating a excellent piece of software.

[ohrenkino]

I think that the basic design of MP3tag will not be the best to implement this.
As you can treat more or less any tag version (wav, flac, V1, V2.3, V2.4 mp4 etc.) and any file type (ogg, flac, wav, mp3, mp4 etc.) the read data has always to be mapped to an internal representation.

@knowle

The only way I have found to fix this metadata issue is to use the "Remove Tag" feature in Mp3tag 2–3 times to remove all fields and then add everything back manually.

If this is the case: which of your other program stacked tags on top of each other? Such a treatment of files is definitely the wrong way.

@knowle

Mp3tag selects the first, music-metadata selects the last).

Where do you see this display?
Have you checked the extended tags dialogue to see how many fields there are?

@knowle

That is, I don't know if this MP3 file can be considered corrupt or not.

Here are links to some utilities to check files for corruption:

How to check files for errors?

It’s required and often helps to reduce support cycles to check files for errors before filing a bug report. Symptoms of erroneous files are often missing or wrong bitrate or length audible blips or skips tags seem to be sticky and cannot be removed There are some really good tools to check the files for errors, namely MP3 Diags — identifies many different issues in MP3 files Website: http://mp3diags.sourceforge.net Download: MP3 Diags - Getting MP3 Diags MP3val — validate and fix MPEG …

AFAIK the case of a tag field name should not matter.

@knowle

For what it's worth, the "Extended Tags" window currently gives a false impression of being a list of every metadata field in the file, but this isn't the case.

In a way you are right that subordinate tag data is not shown. Priority of tags when read is:
APE>V2>V1.
But you see which tag version is now the one with priority in the dialogue title of the extended tags dialogue of a single file or the corresponding column of the default shipment.
If would be intersting to see such problematic file and then find a way to deal with it with the current functions.

[knowle]

I think that the basic design of MP3tag will not be the best to implement this.

How so? An "advanced" version of (or "advanced" tab within) the "Extended Tags" window would be a good location. This UI would show each of the tagging systems present in a file separately and allow the user to, for example, fix discrepancies between tagging systems, remove duplicate entries, or remove ID3v1 tags altogether.

If this is the case: which of your other program stacked tags on top of each other? Such a treatment of files is definitely the wrong way.

No idea – these are MP3s I've had for 10+ years.

Where do you see this display? Have you checked the extended tags dialogue to see how many fields there are?

Here is more-or-less the object returned by music-metadata's parseFile function:

{
  format: {
    tagTypes: [ 'ID3v2.4', 'ID3v1' ],
    trackInfo: [],
    lossless: false,
    container: 'MPEG',
    codec: 'MPEG 1 Layer 3',
    sampleRate: 44100,
    numberOfChannels: 2,
    bitrate: 192000,
    tool: 'LAME 3.98.2',
    codecProfile: 'CBR',
    numberOfSamples: 12210344,
    duration: 273.1337542809143
  },
  native: {
    'ID3v2.4': [
      { id: 'TALB', value: '<album>' },
      { id: 'TPE1', value: '<artist>' },
      { id: 'TPE2', value: '<album artist>' },
      { id: 'TPOS', value: '1/1' },
      { id: 'TCON', value: '<genre>' },
      { id: 'TCMP', value: '1' },
      { id: 'TIT2', value: '<title>' },
      { id: 'TRCK', value: '17/37' },
      { id: 'TDRC', value: '<year>' },
      {
        id: 'APIC',
        value: {
          format: 'image/jpeg',
          type: 'Cover (front)',
          description: '',
          data: <Buffer>
        }
      },
      { id: 'TXXX:major_brand', value: 'mp42' },
      { id: 'TXXX:minor_version', value: '0' },
      { id: 'TXXX:compatible_brands', value: 'isomavc1mp42' },
      { id: 'TSSE', value: 'Lavf52.54.0' },
      { id: 'TIT2', value: '<title>' },
      { id: 'TPE1', value: '<artist>' },
      { id: 'TPE2', value: '<incorrect album artist>' },
      { id: 'TALB', value: '<incorrect album>' },
      { id: 'TDRC', value: '<year>' },
      { id: 'TCON', value: '<genre>' }
    ],
    ID3v1: [
      { id: 'title', value: '<title>' },
      { id: 'artist', value: '<artist>' },
      { id: 'album', value: '<album>' },
      { id: 'track', value: 17 },
      { id: 'year', value: '<year>' },
      { id: 'genre', value: '<genre>' }
    ]
  },
  quality: {
    warnings: [
      //...
    ]
  },
  common: {
    track: { no: 17, of: 37 },
    disk: { no: 1, of: 1 },
    movementIndex: {},
    album: '<incorrect album>',
    artists: [ '<artist>' ],
    artist: '<artist>',
    albumartist: '<incorrect album artist>',
    genre: [ '<genre>' ],
    compilation: true,
    title: '<title>',
    year: <year>,
    date: '<year>',
    picture: [ [Object] ],
    encodersettings: 'Lavf52.54.0'
  }
}

Notice that music-metadata provides a single normalised object of metadata, common, that includes parsed track numbers. It also includes a separate "raw" view of each of the tagging system it finds in the file; native['ID3v2.4'], native['ID3v1'], etc.

For this particular file, there are duplicate entries in the ID3v2.4 tags. When compiling its normalized common object, music-metadata chooses the last TPE2 and TALB tags, which contain the incorrect values. By contrast, the only value I can see anywhere in Mp3tag is the first value – the correct one. Apple Music also shows the correct value, but I would still like to remove these old tags.

The "Extended Tags" window in Mp3tag doesn't do that much – it just shows any fields which are not configured to show in the sidebar or in the file listing. Importantly, it still only shows Mp3tag's internal, normalised view of the track metadata, rather than the raw metadata tags present in the file.

I imagine all of this data is exposed by the library – probably id3lib or TagLib – that Mp3tag uses to parse and modify the tags. I would just like an "advanced" mode UI in Mp3tag that allows modification of the underlying tag values without Mp3tag's normalisation mapping getting in the way, even if that is more standards compliant.

Thanks for mentioning MP3 Diags. Unfortunately there's no macOS version, and I'd like to avoid getting a Windows or Linux machine running just for this.

[ohrenkino]

@knowle

This UI would show each of the tagging systems present in a file separately and allow the user to, for example, fix discrepancies between tagging systems, remove duplicate entries, or remove ID3v1 tags altogether

This is already possible - admittedly not in 1 go but sequentially. You only have to modify which tags are being read (for mpX files). There you can also set which tag versions should be removed.

It would still be helpful to get such a file for which you claim that there are several fields of the same type but only 1 is displayed for further examination.