Running mp3tag 2.89a on a Win 10 laptop
When converting file names to tags, my track# are randomly set to 1 or 2 digits (i.e. "1" instead of "01" etc...)
This happens sometimes in the same album: 01 to 05 then 6 to 9...
Before tagging, I ensure my music is organised as follows: \genre\artist - year - album\track# - title (with year on 4 digits and track# on 2 digits)
I have tried "$num(%track%,2) ", but it seems this only works for converting to file names (and not to tag)
The preview shows always track# on 2 digits
The format I use is the following: %genre%%artist% - %year% - %album%%track% - %title%
I have full access on the directories & mp3 files: no read only, archive bit set...
Before converting to tag, I always remove every tag to ensure standardisation of my tags
Any clue would be very welcome!
If you want to modify the contents of the field TRACK,
either: use the track-numbering assistant
or use an action of the type "Format value" for TRACK and format string: $num(%track$,2)
or use the function Convert>Tag-Tag for TRACK and format string: $num(%track$,2)
Actually, what I wanted to ask was why is it sometimes (i.e. not systematically) behaving incorrectly
See the screen shot attached: tracks 1, 5 and 7 are not tagged properly, whereas 2 to 4, 6, 8 and 9 are tagged ok
See also the formatting string I have used
there are some file formats that do not support leading zeros in track, like MP4 files.
Then I would check what tag versions you have in the files: only ID3Vx or also APE tags?
It could be that you see other tags than you write.
You're (almost) spot on: tracks 1, 5 & 7 are ID3v1, all other tracks are ID3v2.3.
There is no APE tag at all, and I only have mp3s (videos are stored elsewhere)
I have been carefully looking at the Tools > Options and found that "Write ID3v2 only if ID3v1 too small" was ticked
Unticking this parm did the job
I still have one worry though: this all means that "Remove tag" is not actually removing the tag, but only the contents of the tag Right?
Thanks a bunch for the useful hint anyway
There is no empty tag. If you remove the content the tag is removed.
But you should not mix the options of "Remove tags" with an action that actually removes a tag. (Red cross-icon or menue or ...).
If you remove the content the tag is removed.
I did not know this; thanks for the info
you should not mix the options of "Remove tags" with an action that actually removes a tag
I'm not too sure to understand what you mean...
What I'm doing is the following:
First I ensure the directory & file names are OK (convert tags to file name + manual updates if needed)
Then I remove all the tags (the red cross)
And finally I'm tagging from the directory & file names structure
Is this not a valid approach?
I would always prefer the other way round: tag the files correctly first, then rename the files and paths.
This is mainly due to the fact that each file system has its own restrictions in respect to allowed characters and lengths of fields.(e.g. ?. *. : are not allowed in NTFS, / and \ may lead to unexpected results and some more)
So in many cases, a filename can simply not store all the information from the tags.
But for a first approach to come from "no data in tags" to "some data in tags", it is definately not an un-common proceedings (hence the functions in the converter ;-))
Well in my case (and I believe many, many, many more), I'm on Windows
The reason why I'm starting from the file structure is that I find it MUCH easier to rename files/directories in Explorer than manipulating the tags with a tool
Also, the usable character set from Windows suits me fine!
As I understand it: a tag is the whole thing of the metadata in a file.
This tag could then be subdivided into fields (and some other stuff).
That what you set in the Tools menu deals with the whole tag for the functions from the edit menu like copy, cut and delete tag and it also deals with the behaviour of MP3tag when it reads the metadata of a file.
If you use the red X in the extended tags dialogue, then you delete a single field. The tag itself stays until you delete the last tag or delete it completely anyway.
Well, often users think that saving a file within MP3Tag will delete tags according to the options for deleting.
To your general approach Ohrenkino already wrote something. It is a "valid" approach but to my opinion it is not very useful.
MP3Tag has many useful abilities to write and change tags (Actions, Websources, Scripts ...).
And most people use much more tag-fields (including me) than they use in the filename and the file-structure.
I did not mean the red cross in the extended tag-menue with deals with single-tag-fields but the red-cross in the main-menue which deletes all tags in the marked files according to the options-settings for deletion.