Feature suggestion: tag checking/validation

[rboss]

Happy New Year to everyone in the community

Recently, I became aware of an issue affecting my music collection, where tags were being modified by the ReplayGain scanner function of my player of choice (foobar2000, and if you're curious you can read about it in its fb2k forum entry).

To get to the root cause of this I wrote myself an MS Excel VBA macro to read and list ID3 tags from my collection; and while I enjoyed -and learned- from doing it, it gave me the idea of this feature suggestion:

"Why not add some sort of tag integrity check to verify if my/other user's music files' tags are valid across their respective tagging standard(s) (ID3, APE, etc.)?"

Mp3Tag seems the perfect tool to have this function added, and would be a welcomed help for the type of situation I went through.

Also, having tag validation could be of help in cases where hardware players (current or legacy) might run into problems with tags, and a method of verifying the conformity of tags in music files to the standard(s) supported by said players would be needed.

But, if anyone already knows of external applications that can run such a validation, I would be thankful if you could share them.

If not, please consider this suggestion for improving an already excellent tagger.

[ohrenkino]

@rboss

my/other user's music files' tags are valid across their respective tagging standard(s) (ID3, APE, etc.)?"

I am not sure what you mean by checking the validity.
As soon as MP3tag comes across tags that are unintelligeable by MP3tag are already flagged.
If you look for tools that check files for integrity in general, see the already existing thread:

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 If the font size in MP3 Diags is …

[rboss]

@ohrenkino

I am not sure what you mean by checking the validity.
As soon as MP3tag comes across tags that are unintelligeable by MP3tag are already flagged.

In the fb2k forum post I detailed and provided examples of a tagged file where it looks to me that the APIC tag was unintentionally modified, in such a way that it no longer (fully) complies with the ID3 standard. I think if you read it, it should be clearer what I meant with "tag validity".

Since it's been a few weeks without a reply from that source, and since Mp3Tag may be involved, I started this thread for the suggestion and to learn if such a tool already exists.

[ohrenkino]

Have you tried 3.28a

Mp3tag Development Build Status

Date: 2025-01-08 Version: 3.28a Status: Beta Download: 64-bit mp3tagv328a-x64-setup.exe 32-bit mp3tagv328asetup.exe 3.28a (2025-01-08) CHG: use link instead of move drop effect when dropping files to File List to prevent files being removed from the drop source. (#63359, #66931) CHG: use favorite directory as initial directory when changing directory from the empty startup directory. CHG: added workaround to read ID3v2.4 frames with incorrect encoding of unsynce…

which has a modification

@Florian

CHG: added workaround to read ID3v2.4 frames with incorrect encoding of unsynced integers.

[rboss]

@ohrenkino

Have you tried 3.28a

I have just finished installing 3.28a, and getting acquainted with MP3 Diags (which seems to be getting closer to what I'm looking for).

I don't think that the particular scenario of the APIC tag modification is caused by Mp3Tag (I did mentioned in the fb2k forum that Mp3Tag does tag -and restore the 'altered' tag- correctly; the fault (if there is one) appears to lie within foobar.
Nevertheless, I'm going to replicate the same process in 3.28a and see what happens.

[ohrenkino]

@rboss

the fault (if there is one) appears to lie within foobar.

We just had a case where files were downloaded from a public mediatec which had exactly that problem.
Foobar could cope with those files and corrected the tag to V2.3 - because the problem occurs in V2.4 tags.
Then MP3tag got V3.28a and now can do the same.

MP3 damaged or Mp3Tag missing something?

Hi! at this URL https://www.ardaudiothek.de/episode/fruechte-des-zorns-john-steinbecks-roman-als-hoerspiel-serie/fruechte-des-zorns-1-12/ard/13891599/ there is a download for an MP3. (Click the three dots then select "Herunterladen"). Mp3Tag does not recognize the tags that are in the file (as can be seen with a hex editor). Is the Mp3 broken or is Mp3Tag not interpreting the file correctly? All the best, rh005

[rboss]

I repeated the same test described in the fb2k forum post using 3.28a and have had the exact same result.
Again, I still don't believe the fault lies in Mp3Tag.

@ohrenkino

We just had a case where files were downloaded from a public mediatec which had exactly that problem.

The audio file mentioned in that post is actually useful to me to test and improve the VBA macro I mentioned earlier; and I can also use it to illustrate what I mean with "tag validity":

• downloaded the file; loaded it into an hex editor;
• ID3 header states that version 2.4 of the format is used;
• scrolled down to the APIC frame; its size is stated as CC23 hex == 52259 decimal bytes;
• splicing that length of data into a new file and trimming the picture header data I get a correct image.
  So in theory, this frame is correct/validated.

However, the ID3v24 format structure states (very clearly, in fact) that the "size descriptor containing the size of the data [is] (...) stored as a 32 bit synchsafe integer".

This means that -according to the format specification- the integer 52259 should have been syncsafe decoded into the actual size.

And this is what I meant by "tag validation". Although it's not (directly) related to the fault from my original post, this serves as an example of ID3 data not being (fully) valid to its respective standard.

Apologies for all the technical exposition, but after spending weeks working on the VBA macro, my mind is still swimming in the ID3 format and somewhat in coding mode..... I hope this made sense, and the meaning behind my suggestion also makes sense.

[Florian]

The reason why Mp3tag "repaired" your file referenced in the initial post is that Mp3tag doesn't apply unsynchronization for ID3v2.4 frame contents (the frame size always uses unsynced integers).

[2021-04-08] CHG: not using ID3v2 unsynchronization scheme anymore when writing ID3v2.4 due to compatibility reasons with apps that don't implement the standard.

This would make Mp3tag itself subject to be identified by a tag checking component

[rboss]

Yes, exactly! You're absolutely correct - Mp3Tag 'fixed' that file, and therefore it was valid against ID3v2.4.
This goes to show the excellent work you've done when designing the program.

Now, going back to the case of my original post in the fb2k forum, when applying RG info, the APIC frame was (unintentionally) modified, and the file was no longer (fully) valid against ID3v2.4. I was fortunate enough to stumble into this modification with the PHP script, which led to these topics.

In any case, due to the fact that my tagging workflow up until recently had always been 1- MP3Tag, 2- ReplayGain, I'm pretty sure that most of my thousands of music files are not (any longer) fully ID3v2.4 compliant - despite the fact that I had tagged them as such in step 1 of my workflow.

And this serves as a fine example where

@Florian

This would make Mp3tag itself subject to be identified by a tag checking component

Because the purpose of such a tool could also be to validate that files correctly tagged by Mp3Tag remain correctly tagged (by Mp3Tag), and have not been -intentionally or otherwise- changed by other software over time. Or when tagged by another program, to validate those tags against their respective standard.

MP3 Diags does go a long way into doing this, by showing raw tag data; and does a decent job of reporting inconsistencies; but IMO seems to be somewhat catered towards ID3v2.3; and without some previous knowledge about tagging formats can have a somewhat steep learning curve.

What I had envisioned with my suggestion was something along the lines of

On the left side of the picture is what my VBA script can currently do; the grid on the right side is a very rough draft of my idea, where a user-friendly(ier) interface would show which format(s) of tags a track \ set of tracks has, and if those tags are compliant/faulty/broken against its standard.

(By the way, this is the cover image you get when extracted from data with unsynchronisation schema applied but without decoding)