Total Tracks Correlation?

I'm working on converting a collection that has a lot of partial albums/directories. It would be great if MP3tag could correlate the "14/14" track number to the quantity of files - in order to make sure all are present or not. Or MP3tag could detect gaps in the track sequence?

Some sort of warning that "Not all tracks present" would be good to have in this effort.

And yes, I understand that the results would be imperfect, and really only applicable to the doubled-up track listing probably - unless the program reached out to a DB.

I think MP3tag is a terrific tool, and I would not be making the effort on these collections without it. Thanks!

So far Mp3tag cannot do anything like it as MP3tag does not know anything about albums.
It does not know what the previous file had as data and what the next will have.

What you can do, though:
Copy the original data from TRACK to a user-defined field, e.g. MYTRACK
Run the track numbering assistant to set an ascending order of numbers into TRACK.
Now use a filter like
"$if($eql(%track%,%mytrack%),1,0)" IS 1
and you will find all the files where due to a gap the 2 numbers don't match any more.
Although, admittedly, this method has its limitations if the last file is missing.

If MP3Tag has a whole album loaded in it, it'll know how many files are there, and the Track field frequently shows "1/13" (example) as a track number. I'm only suggesting that the quantity of files be compared to that "13" to create a notification that there's a mismatch.

OK, to get this function working one needs

  • a track number that also shows the total number of files, which is something I would expect to show after the tagging has been completed. Until the total number has been added, I assume, the error message would appear?
  • a number of files that are already reside in a folder. MP3tag has functions to move files to a single place if they are scattered across the file system. As long as this has not happend, the error message would apperar?
  • the number of loaded files matches exactly the biggest number of totals in the track number. So it becomes difficult to load more than 1 album at a time.
  • the number of loaded files matches exactly the number of displayed files so that it would not be sensible to use the filter.

In short: I think there are so many pre-conditions to be met that, at least in my workflow, I would hardly ever find the message a useful hint and I would probably keep it switched off all the time.

If you have really a desperate need: compare the number of loaded files as shown in the status bar with the display of the track number. That would be the easiest way to get the requested information until your suggestion comes to life. And it would save you the bother to click an OK button to acknowledge the the message.

I'm loading one album/directory at a time, so I'm not able to easily comprehend other methods of how the tool's used.

Perhaps if it just looks at an album title to correlate quantity of files to the track number "quantity" it would then show green/red. A warning wouldn't need to be apparent outside of that simple correlation, I think.

When whipping through a collection, I find it good to know if an album is complete versus having holes in it. Perhaps there are other ways to skin that cat, I don't know, but that's my hope.

MP3tag has its special virtues if you treat a lot of files in one go. And a lot of files means much more than just one album.
Again: you see the information more or less at a glance: check TRACK and check the status bar and if the number of loaded files matches the number of total tracks, you have "skinned that cat".
The interpretation whether that is intended or an error is still up to you. It could be that a file is missing or you have more files in that folder than you expected ...
If you are pretty confident that you only have one album in each folder, then the bulk way to do it, would be to renumber all the files with the track numbering assistant and filter for those albums where there is a mismatch. But this I have described already in this post: