[F] Tags changing by themselves

Hello

I have been doing using Mp3tag for over 10 years now . And I've noticed that very rarely, tags get mixed up between files. Trough out all these yeas I've only had dozens of cases. Sometimes a whole album [sets of file] gets mixed, and other times just a single file

Here are the "settings":

  • 20 000+ files now
  • 10 000+ files 10 yeas ago
  • a lot of moving between catalogs
  • almost no movement between hard drives
  • coping / movement was done with the use of normal Windows XP and Windows 7 system file handler
  • a do a lot of changes on tags, few times did them on the whole set of files
  • I never export and import tags on the whole set of files
  • I often copy tags between single file [between old and new version of one and the same file]
  • problem is with mp3's [because that was my format of choice till few months back, when I started to use also FLACs]
  • I use Winamp for playing

And the problem is like that: file stays in the correct catalog, namefile doesn't change, but somehow the tags are taken from other files

And I think that there used to change between [file "A" gets "B" tags and the "B" file gets tags of "A" ], but now there are just some random changes [which I can restore by looking into backup for the older version of changed file]

All cases were discovered by me by accident. 5 years ago I thought, it was my fault. But know I'm convinced, that the volume of my set times operations equals a Matrix like glitches. The only unknow for me is, if it's the fault of the Mp3tag

Also I would like to know, given that all of my filenames should have the same signs in them [or at least the first few characters] as the titles in the TITLE tag, what kind of a filter could I use to find errors [inconsistencies between filenames and TITLEs]?

Once you have all tag-fields filled correctly, then you can use this "database" to build the filename.
Any further comparison between the filename and the tag-fields becomes redundant and unnecessary.
You should not invest so much time for checking the filenames, but you should get a good "database" in the tag-fields.
Filenames are "smoke and mirrors" (german: "Schall und Rauch"; have no meaning; be transitory).
Creating the filename is the last step in the whole process of tagging.
You may create any sort of structured type of filename, using data from the tag-fields.
If some filename looks bad, then write it new, using your rules for filenames.

DD.20150214.1915.CET

1] Tagged database was set. The work was done

2] Tagged database is sometimes being corrected and is growing every few days. The further work is ongoing process

3] I'm not checking the filenames. I know that filenames should be only something for operating system to work on

4] Filenames are my backup names; which come in handy when a glitch appears

Just yesterday a found another glitch of that kind. Description:

In the artist folder I have 10 songs from only one of his album [out of 15; 5 I didn't like and so I didn't save them]. They were tagged properly few years ago; they had to be, because I always copy [short] filenames to title tags. But now 5 out of this 10 have title tags mixed up between them- and I know this because filenames are different than titles. So, I have to go to sites like YouTube and search for those tracks [using filenames] and check if the filenames are still correct. And filenames [as I recall] are always correct when this happens, because they don't change by themselves. And when I confirm that, then I can copy filenames into TITLE tags again to restore order. [I forgot, if the TRACK tag gets mixed up too]

So: is it possible to use some filter, to compare filenames with titles? To find possible mismatches?

E.g. this filter
"$if($eql(%album% _ $num(%track%,3) _ %artist% _ %title%,%_filename%),1,0)" IS "0"

checks if the preferred mask for a filename is kept (or not)
You can adapt the part in front of ",%_filename%" to match your conventions to create a filename.

You could check the settings in
Tools>Options>Tags>Tags>Navigation with cursor keys saves tags
(untick)

and in Tolls>Options>General>Editing in File list selects next file
(tick).

It could be that a certain sequence of operations like modification in the tag panel plus navigation in the files list leads to strange results, esp. if you have switched off the messages when saving tags (I think everybody does that after a while ;-))

I used

"$if($eql(%title%,%_filename%),1,0)" IS "0"

and it works for my naming system; almost

Because unfortunately, it show me as errors all my "translations" [if I have a ":" in TITLE tag, I will change it to ".." in filename; and now it shows up after filtering]

So I will have to go throug out and very extended list to find out the real errors. But I will do it and try to find some kind of a pattern or characteristic in those real glitches, when I single them out

[Or maybe there Is a way to improve that code by adding an order to ignore pairs like ":" ".."?]

I will report them in this topic, which will propably take me a lot of time. And maybe in the meantime someone else will stumble upon those kind of glitches and my topic

That's not it. A have them just as you suggest, and probably had them like that from the beginning [something around 2004] and for certain since 2010 [I have a copy of setings from back ten that I just loaded and checked]

You can still apply a
"$if($eql($replace(%title%,:,..),%_filename%),1,0)" IS "0"
(and all the other pairs of your translation convention) to manipulate the contents of TITLE.

See there ...
"Filename - Tag" ICON

Filter:

"$if($stricmp(%TITLE%,$replace(%_filename%,'_','/','...',':.','..',':')),1,0)" IS 1

DD.20150218.1805.CET

Unfortunately something more precised like

"$if($eql($replace(%title%,:,..),%_filename%),1,0)" IS "0"

takes out also all the errors that I'm looking for [for example TITLE "Song: A" when at the same time the FILENAME is something completely different, like "Track 18"]. It would have to be even more advanced. It would have to say to ignore the difference between ":" in TITLE and ".." in FILENAME when these two signs are at the same place [when counting signs from the beginning of TITLE / FILENAME; when not knowing where and if there will be such two signs], but at the same time taking into consideration [displaying] all the "loose" [without it's counterpart] cases of ":" and ".."

So, instead I used the simple

"$if($eql(%title%,%_filename%),1,0)" IS "0"

and then looked and almost 2000 files, comparing TITLE tags with FILENAME; by making the TITLE column very thin [so that it could display only one letter / sign / digit] and putting it next to the FILENAME column. That way I could see right away where something was out of place [or example and "A" between a string of letters "D" running from top to bottom]

And here is what I have found:

BUG EXAMPLE #1

FILENAME "Asche Zu Asche (Live In Sydney 2001)" got all the TAGS from "Asche Zu Asche (Live In Nîmes 2005)". Both files was stored in the same folder. Other files from those two albums have still proper TAGs [so "Asche Zu Asche (Live In Nîmes 2005)" is still correct]. The bug must have acted somewhere between 2011 04 16 and 2013 09 13

BUG EXAMPLE #2

FILENAME "Ameno" from folder "eRa" got all the TAGS from "Cold Wind Blows" from folder "Eminem". Other files from "eRa" folder are still correct, including similar in name "Ameno (Heavy Mix)". "Cold Wind Blows" is also correct and I don't see any changes in TAGS of files stored in the "Eminem" folder. The bug must have acted around a year ago

BUG EXAMPLE #3

FILENAME "The Royal Wedding" from folder "James Horner" got all the TAGS from "The Same Race" from folder "Jerry Goldsmith"

FILENAME "The Royal Wedding [Beginning Excerpt]" from folder "James Horner" got all the TAGS from "The Same Race [Beginning & Middle Excerpt]" from folder "Jerry Goldsmith"

FILENAME "The Royal Wedding [Middle & End Excerpt]" from folder "James Horner" stayed correct. Also the rest of tracks from both albums [that of James Horner and Jerry Goldsmith] are still correct. And what's important, there was no third "The Same Race" track; so it seems that the bug didn't had a third [somehow linked] source of data to copy tags from it to the "The Royal Wedding [Middle & End Excerpt]". And in my collection there are hundred cases of TITLES / FILENAMES having an addition like "... [Beginning Excerpt]" or "... [Middle & End Excerpt]", so it's strange that bug stopped or choosed [a Jerry Goldsmith] folder with not sufficient cases of "Excerpt" files in the first place

BUG EXAMPLE #4

When there were added to my music folder, to the sub-folder "Cruachan", there were only 6 files from the whole album. So all of those files had all TAGS exactly the same, except TRACK number and TITLE; and the TITLE was always the same as the FILENAME. But now only the first song from the album has the original correct TAGS, and the five got mixed up between themselves like that

TAGS from 2 went to 4
TAGS from 3 went to 6
TAGS from 4 went to 2
TAGS from 8 went to 3
TAGS from 6 went to 8

And the TITLES TAGS were [are suppose to be in the correct state] like that:

TITLE 1: A Celtic Mourning
TITLE 2: Celtica (Voice Of The Morrigan)
TITLE 3: The Fianna
TITLE 4: A Druids Passing
TITLE 6: Cattle Raid Of Cooley (Tain Bó Cuailgne)
TITLE 8: Óró Sé Do Bheatha Abhailé

This must have happened before 2010 08 18

[PROBABLE] BUG EXAMPLE #5

FILENAME "Bugs [Middle Excerpt]" got title TAG from "Bugs [Beginning Excerpt]". Both files were stored in the same folder. It was either my mistake or it is the bidding of the bug. I can't be sure, because the only difference [in the state of being correct] between these two is the TITLE TAG- so the bug could have copied all the TAGS from one to another; or it was me, who have copied them and forgot to change the title TAG

[PROBABLE] BUG EXAMPLE #6

FILENAME "On The Beach [Middle & End Excerpt]" got title TAG from "On The Beach". Both files were stored in the same folder. It was either my mistake or it is the bidding of the bug. I can't be sure, because the only difference [in the state of being correct] between these two is the TITLE TAG- so the bug could have copied all the TAGS from one to another; or it was me, who have copied them and forgot to change the title TAG

[PROBABLE] BUG EXAMPLE #7

FILENAME "Odyssey Phase 3" got title TAG from "Odyssey Phase 2". It was either my mistake or it is the bidding of the bug. I can't be sure, because the only difference [in the state of being correct] between these two is the TITLE TAG and the TRACK TAG- so the bug could have copied all the TAGS except the TRACK TAG [or have copied for example only the TITLE TAG] from one to another; or it was me, who have copied them and forgot to change the title TAG [but didn't forgot to change the TRACK TAG]

CONCLUSIONS:

A] the bug exists; but it can be either in the Windows XP [both 32 and 64 bit; and maybe Windows 7 x64] or in Mp3tag [2.61a and lower]

B] the bug doesn't come out only with non "standard" english letters like "î", but acts on every day "normal" letters

C] the "[" and "]" signs doesn't seem to be the factor [as the BUG EXAMPLE #2 shows]

D] the bug somehow stopped executing 2/3 way through when it didn't found a way to act further [as the BUG EXAMPLE #3 shows]

E] the "(" and ")" signs doesn't seem to be the factor for a single file but could be for a whole folder [as the BUG EXAMPLE #4 shows]

F] the bug can either limit itself to one folder [as the BUG EXAMPLE #1 shows] or link completely different files from various folders [as the BUG EXAMPLE #3 shows]

G] sometimes errors come to be on similar names [as the BUG EXAMPLE #3 shows] and other times there seems to be no naming connection at all [as the BUG EXAMPLE #2 shows]

H] in all cases the FILENAMES stayed corrected [to be sure, I've listened to all the tracks on-line]; it's only the TAGS that get messed up

I] those 4 [or 7] bugs don't surprise me at all- I've indeed seen before such a Matrix in my always carefully tagged and handled music files

As I remember ... such problems are resolved since Mp3tag version 2.59.
You should update to the most recent version.

DD.20150223.0650.CET

I hope, that that is the case / solution

And I won't be back anytime in the future with new examples of bugs to report

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.