MP3TAG not "seeing" track number in some MP3 files

I'm trying to update a bunch of my karaoke files (MP3 + G). When I open them in MP3TAG, the track number is not displaying in either the left panel or in the Track column. Yet, the track number shows up in Winamp and in Windows Explorer correctly.

Looking at one of the MP3's file properties in Winamp, track number is present in Basic Info and ID3v1 format but it is NOT showing in the ID3v2 panel (both panels are checked to be included in the file).

These files were not ripped by me but I need to change the file names to include the track number. Something is goofy here. Shouldn't MP3TAG read the track number regardless of whether it is in v1 or v2 format (or both)?

How do I get the track number to show up so I can manipulate it?

UPDATE: OK, I note that changing MP3TAG's Options / Tags / Read and UNCHECK ID3v2 will show the track number correctly. HOWEVER, should I really have to do this for these specific files? Can't MP3TAG read the ID3v1 tag if the ID3v2 tag is blank? Or is it just seeing that there's "stuff" in some of the ID3v2 tags so it only reads whatever's there and ignores ID3v1 completely?

Is there a way to automate this? Like display BOTH ID3v1 & v2 track numbers in the column view?

Best thing to do is delete the ID3v1 tags entirely, Use mp3tag to get all the info (automatically) into ID3v2.3 tags, then use your mp3 mp3tag tagging settings to keep only the ID3v2.3 tags. Not much use anymore for Id3v1 tags other than a few old car stereos.

How would I do this? The v1 tags contain the track numbers which I want to keep. The existing v2 tags do not. But when I open the mp3 files in MP3TAG, it doesn't show the track number unless I uncheck Read v2 in the Tag options. THEN the problem is that some of the fields get truncated (like title) if they are too long.

try this (do some testing before commiting to a batch job on all your files)

Right click on the column headings, then select CUSTOMIZE COLUMNS, then add a column (new) with name "Tag Type" and value of:

%_tag_read%[ (%_tag%)]

then click OK. This will add a column so you can tell what tag is being read (and in parentheses, what tags are IN the file).

load up an album of files that don't show track number.

go to TOOLS > OPTIONS > Tags > Mpeg

READ: tick id3v1 and id3v2
WRITE: tick ID3v2, and tick ID3v2.3 UTF-16
REMOVE: tick ID3v1 and APE
then click OK.

Go back to list of files you selected, select them all (highlight), then click the SAVE icon in upper left menu bar. Do track numbers all show up now? IF not, try highlighting (after the SAVE), and then click the red X next to the save icon. This should remove all but the ID3v2.3 tags. What happens then. Again, experiment until you see that it is working. But what this is supposed to do is read info from all the tags, only write to id3v2.3 tags, and delete all the unwanted tags. You'll be left with only ONE tag in the files (which is the best answer in almost all cases...this is what I do).

Would be nice if this mess was a bit more "automatable". :wink:

I have to click the Red X to remove the v1 tags. More work but manageable. Is there any harm in leaving the v1 tags in there?

Oh and MP3Tag already has the "Tag" column available for selection. No need to add it. Thanks for explaining how to read it though.

not sure how to make it more automatic. you set you options once, and you can fix 100,000 files with one or two mouse clicks all in one batch.

The harm in leaving the id3v1 tags there is exactly what led to your original question (i.e., the "mess"). Some programs might be seeing the id3v1 others might be seeing id3v2. When you edit, maybe only one tag gets edited. No particular harm leaving it there as long as you understand the potential problems in the future. I just find it easier/better to have a single tag in my file with all the correct information. In the old days, one needed id3v1, because some old players, car stereos, tv dlna players, etc. could only read id3v1 tags. I suspect that's rare these days.

The original problem is that apparently some other ingenious tagger wrote two tag versions with different content.
Now then: the priority of tags is like this: APE>V2>V1. When reading a file then the information from the tags is mapped to an internal representation. And as there can be only one TITLE field (and one for TRACK) the last tag defines the contents of a field.
Which means: the last one wins. If you switch off the reading of a tag version, only the others are read.
So if you want to get all of the V1-tag contents, do not read APE or V2.
When you save the tags for such a file, you can set that also V2 is written. But MP3tag will take care that both tag versions have the same contents (in the fields that match).

So it is up to you to decide which contents is worthwhile to be kept. I do not see a lot of potential for automating the user's decision.

Mp3tag has a priority system, when it works with different tag-types.
So the tag-type APE has priority over the tag-type ID3v2, which in turn has priority over the tag-type ID3v1, in short: "APE>ID3v2>ID3v1".

Set Mp3tag "Options/Tags/Mpeg" to read only the tag-type ID3v1.
For sure uncheck all "Write" options.
Refresh the list view to display only values from the tag-type ID3v1.

If you want to copy data from ID3v1 tag-fields into a "higher" tag-type, then you have to export the data into an external text file, then set Mp3tag to read/write the other tag-type, then import the data from the text file into the specific target tag-fields.

Execute this export script ...

$filename($getEnv('USERPROFILE')'\Desktop\Mp3tag.Export.ID3v1.TRACK.txt',UTF-8) $puts(Info,'Important note: Before applying this report script you have to set Mp

3tag to read only tag-type ID3v1 and do refresh the list view.

') $loop(%_path%) "%TRACK%";"%_path%" $loopend()

Execute this import ...

Convert | Text file - Tag | ALT+4
{path to the file}Mp3tag.Export.ID3v1.TRACK.txt
Format string:

Check the result.


Thanks for the explanation. I wonder if some new functions might be usefiul?
For example:

$TagID3v1(%anyfield%) <-- returns value of some field in ID3v1 format

Just thinking out loud here.