Before I start to detail the problems I've run into with 2.44f, I'd like to thank Florian for responding quickly to the Unicode numeric strings issue and releasing 2.44f in a very short period of time.
The bug I've come across in 2.44f is very serious, and has resulted in about 100 corrupted files (fortunately, all restorable from backup).
I don't have a fully reproducible example of the sequence of events yet, but it looks like such a high-impact issue that I thought I'd better report it as soon as possible.
I've been making heavy use of 2.44f over the last couple of days in order to correct about 2500 MP3s with Unicode numeric strings (generated by MP3Tag over the last year or so). 2.44f is the first recent development build to use the correct ISO-8859-1 strings for this format.
Reviewing my files after having completed the task, I've found several "blocks" of files where each file has had the alphabetically preceding (or following) file's tags written over the correct tags. I did back up all of my MP3s just before starting this operation, so my data isn't permanently lost, but a selective restore is still going to be painful.
Here's a "trivial" illustration of the sort of thing that I'm seeing:
File1 Tag1 File2 Tag2 File3 Tag4 File4 Tag5 File5 Tag6 File6 Tag6
In this example, the tags from files 4-6 have been written into files 3-5.
As I said, I don't have reproducible proof that the problem I've encountered was caused by 2.44f, but there's some significant circumstantial evidence.
In order to rewrite the Unicode tags, I constructed an Action Group that clears and then restores the relevant tags. This is done one-at-a-time, and it only affects a few tags, so there's no reason to assume that this is the source of the problem. In some cases, however, this wasn't sufficient to correct the problem (Microsoft's recent "compliance enforcement project" seems to include rejecting files with empty tags, amongst other things). If my Action Group didn't make the file playable, my next action would be to do a "cut all tags" (ctrl-x) and then "paste tags" [Edit: Although I originally said "paste" here, I would always use "undo" if any other action had taken place after the "cut"]. This appears to successfully force MP3Tag to completely rewrite all the tags. This is where the "tag shifting" problem seems to arise, however.
I haven't managed to reproduce the full effect yet, but I have managed to reproduce a set of that result in a corrupted screen display, showing the wrong tags being assigned to files, but they aren't actually written. This is behaviour that is new with 2.44f - I've tested it against 2.44, and that doesn't do this.
This is the set of actions required to show the screen corruption problem:
- Create a group of test files named 0.mp3, 1.mp3, 2.mp3, etc. up to say 9.mp3 .
- Remove all tags from these files.
- Create a title field in each file, each containing just the number of the file (0.mp3 has title "0", etc).
- Start a clean editing session on the group of files using MP3Tag 2.44f.
- Sort the screen display by file name. The Title tags should be in the same sequence, 0-9.
- Select files 5-9.
- Cut the tags (Ctrl-X).
- Without de-selecting the 5 selected files, re-sort the screen display by file name in *descending* order (just click on the "file name" header). The top 5 lines of the display will be (correctly) highlighted, with no data in them.
- Undo the "Tag Cut" operation (Ctrl-Z).
- The screen display now becomes corrupted - the top 5 lines remain highlighted and blank, and the pasted data appears in the bottom 5 lines, overwriting the existing data for files 0-4. Instead of replacing the tag data into the files that it originated from, it has been assigned to the files that now occupy the *screen position* that the data came from. This behaviour is different to that of 2.44, which correctly places the data in the top 5 rows, in reversed sequence.
- Highlight any line. The data displayed on the line reverts to the correct data.
Performing the same sequence using version 2.44 shows the expected correct behaviour - the tag data is shown to be restored to the correct files (in their new screen positions).
This example does just show a screen corruption, and it's not quite the same "cut and paste" operation that I was doing on my "live" data, but it indicates (to me, at least) that there is a problem in this area (parts of MP3Tag not knowing quite where the data should be coming from or going to) that has newly arisen with version 2.44f - enough for me to believe that it wasn't just "finger trouble" that has shifted my data around (I could have believed it if it was just one block of data, but there are several, and it's a consistent "shift-by-1" which would be difficult to do accidentally).
It's my belief that some variant on this sequence of operations, with a single inserted line, or possibly a re-sorting as a result of the "cut" operation, and a slightly different cut/paste/undo(?) sequence has resulted in "shifted" data being written to the files, as well as just display corruption. I know that this is rather speculative at the moment, but the consequences of this type of bug can be very unpleasant.
Until this is resolved, I'd strongly suggest that anyone using 2.44f should keep backup copies of every file opened by MP3Tag (not just ones that are expected to be written).
I'll try to get more concrete information tomorrow.