I've been using foobar2000 and mp3tag for a while now, and have recently been spending time correcting tagging mistakes in a large collection of mp3 files, and using mp3tag's tag import facilities - mp3tag is so powerful due to its scripting and batch programming techniques.
I have been fixing lots of tags in some 66000 mp3 files. I wrote them out from mp3tag to a tab separated file, worked on them, then created a text file with separators, and ran convert - text file to tag.
At some point after I had started, I must have deleted one (just one) of the mp3 files. All files from that point on got the tags for the previous track. Track #2 in a given folder got #1's tags.
Looks to me like mp3tag creates a list of the tracks to be re-tagged, works through them one by one. If a file goes missing, it skips that, but doesn't skip the tags intended for the missing file, it applies that to the next file.
This went wrong about 5000 tracks in from the start. Imagine how disconcerted I was next morning, to find 61,000 mis-tagged files.
This was not a disaster because I have a backup and I have the original spreadsheet and text file and I am running the conversion again, having checked that mp3tag and the text file agree exactly on which files are to be converted.
However I reckon this represents a possible bug: does mp3tag check the filename in its list matches the filename on disk during retagging? The answer is no.
I created a text file including the path and filename, assuming mp3tag would need them to identify each track. I notice both fields appear in each mp3 under VLC, under 'extra medatata'.
Later, I took another set of mp3 files. I imported them to mp3tag. I created an export file and used it in Excel to correct lots of mistakes. As a test I deliberately removed one folder's worth of 18 files from the text file I used for 'convert'. At the point where I removed the 18 files, mp3tag started to use the wrong tag for the wrong file. The last 18 files didn't get retagged, and each file was tagged with details from a file 18 above it in the list.
I conclude mp3tag doesn't check that the tag data is being applied to the correct file, it simply works down the list of selected files, and works down the text file, sequentially. Very easy to program, but dangerous for users.
i.e. you have to be VERY careful if this is the case, firstly to make sure that no files are missing either from pm3tag's list or the text file, and to make sure mp3tag's sort order matches precisely the order of the text file. Windows, Excel and Mp3tag don't always seem to sort in quite the same order.
People are likely to use this method if they want to retag files in bulk, and it's very likely that there will be differences due to renaming and moving files while sorting both tags and file storage, differences which might get missed when editing lots of files.
A more robust approach is to check each file name and folder from the text file, and then open the corresponding file from disk. That way, it doesn't matter if the user selects certain files in mp3tag or not. mp3tag would attempt to tag each file mentioned in the text file, based on path and file name, and therefore would tag the correct file. Mp3tag would fail to tag files that were renamed or missing, obviously, but would NOT tag the wrong files, as is possible at the moment.
This is not a programming bug, but a logic problem which, if corrected, would make the feature a LOAD easier for users; it's very likely anyone tagging lots of files at once will end up with the wrong tags on the wrong files as things stand right now, and this modification would make the likelihood of tagging errors much much lower. The only requirement is to have the path and filename in the text file.
I realise that there is currently no requirement to mention path or filename in the text file and this makes the convert - text file to tag option very flexible. As a programmer myself, I can see the option works as originally intended. However I'm looking at this as a usability issue for people with more interest in music than in logic
regards Derek Grainge