As mp3tag is currently a 32bit application it underlies the restrictions of some 3 GB address space. Minus the amount occupied by the OS (about 500 MB) does this leave some 2.5 GB for data for tags.
The amount needed for each track varies according to the length of tags and the size of the embedded pictures. So about 60000 files is about right, give or take the odd 10000
Just for fun, I loaded 70,100 files (mp3, flac, wma). It took almost 10 minutes.
Filters and column sorting were sluggish but not unreasonable. The vertical slider in the files pane worked once and then stopped working.
Edit: There was no problem with the vertical slider. Instead, my desktop sidebar was interfering with the Mp3tag window.
Created 100 000 zero-length mp3 files each tagged with a 1-character Artist field. MP3Tag 2.46a read them all in just a few minutes - column sort takes about 12 secs. No problems with scrolling, just a little sluggish.
Test edit of file number 100 000 wrote to the correct file, with no 64K wraparound - the danger here was that if 16-bit values had been used for indexing the file list, tags might have been written to the wrong file, but all seems OK!
Looks like we're good to keep on ripping for a while!
I tried it on 404,000 files and the progress bar looked to be about 50% before it said I had insufficient memory. All I want to do is change the file names to the titles I revised within iTunes and then add Album name so I can get the various versions of a song without one overriding the other. So looks like I need to break into 6-7 batches to overcome the memory issue. But do the iTunes titles get added to the tags in the actual file, or are they staying in the iTunes library and not editable?
In iTunes, it was once necessary to change the tag type to force iTunes to write the database data to the tags.
It was also a valid change to change from V2.3 to V2.3 - so no data is lost.
6 or 7 batches may be a little too much. 3 should work.