manage large number of songs in a single directory

Hi,
Thank you for your nice and useful program !
I have to open with Mp3tag a Directory containing about 27000 songs. Is it possible ?
If not, which is the largest number of songs that can be easily managed by a single session of Mp3tag ?
p.s Win 7 64 bit/8 gb ram/AMD 645 Athlon II X4 Quad-Core/SSD Corsair Force 120 GB
Thank you
Matteo

Have you tried it to load the files into Mp3tag?

There is no limit in respect to an absolute number of files. But as MP3tag is a 32-bit-application the maximum amount of addressable memory is some 3gb.
If the data of the tags and filenames and stuff takes up more than this amount of memory adresses then you have reached the limits.

There has been a repeated discussion in this forum about the maximum number - and some have succeeded to load 80,000 files, others even more than 100,000.

Thank you for your answer.
I didn't try it yet.
It's seems that I shouldn't have any problem with less than 30000 songs.
I'm sorry I didn't find previous topic about this question.
Regards
Matteo

i have a pretty large number of files that i wanted to work with all in one directory. i think the total number of files is around 177k. when i open the program and it is loading the directory it freezes up at about 98k or so and i get an error window that asks me to submit a file that supposedly resides in a directory that doesn't actually exist. i'm copying some of my collection to another external hard drive right now, hoping that the new directory will be small enough for the program to work with.

The problem is that mp3tag is a 32-bit application.
32bit address some 3.5 GB of address space. If that is filled, no more files can be loaded.
You 98k of files is about as much as you could expect.
And in general: what does windows do e.g. for displaying such a long list of files?
I would say that a little more fragmentation in the structure would be advisable.

I cannot load my music directory and it has several hundred sub-directories so editing them one by one is not practical. I also cannot see how to bulk-load several of the sub-directories at one time. Am I missing something?

It only has 42,000 songs (much less than some users) but it keeps saying out of memory - so this is because MP3Tag is 32-bit? are there any plans to make it 64-bit or does someone know a 64-bit tag editor? thanks

You can select a set of folders in the explorer and drag them into mp3tag.
The amount of files depends also on the absolute quantity of data in the tags. E.g. if your pictures are fairly big, you have a lot of lyrics in them and so on can lead to the behaviour.

What you should also do: check the files with mp3val to see that the files are not courrupted and therefore cause errors.

yeah, i was really tired when i posted that. it is pretty well fragmented. it's actually my itunes music folder, so it's broken up by artist and album

thanks for the help! i'll try dragging and dropping folders into the program and see if that makes things better.

brilliant! I never thought of that. Thanks heaps.

... or select all the wanted subfolders in the explorer and invoke Mp3tag via context menu.

This seems to be true in practice.

A few days ago I did some tests using Mp3tag v2.62 on a 2GHz 2GB WinXP machine with a big amount of files.
Results are:
1.
One folder with 175769 dummy test mp3 files (each of 5 Byte filesize) has been the limit for the Windows Explorer resp. the disk subsystem.
Mp3tag was able to load all files, but it took rather long time.
Mp3tag was able to embedd a JPG picture of 59 KB filesize into 81567 files, then stopped by memory failure.

Having 10000 subfolders with each having 20 dummy test mp3 files (each of 5 Byte filesize), given 200000 files, Mp3tag was able to load all files, much faster than from one big folder.

While loading a JPG picture of 59 KB filesize there were several Mp3tag breakdowns because of memory failures.

Especially when setting the Filter, e. g. ...
"%_covers%" IS ""
NOT "%_covers%" IS ""
%_covers% PRESENT
NOT %_covers% PRESENT
... Mp3tag instantly got a memory failure.

After several attempts with smaller groups of files, all files got the picture embedded ...
(50000 + 50000 ... machine cold start ... + 100000).

Mp3tag load time was about 35 minutes for all 200000 files with embedded 59 KB picture, overall about 11.5 GB.

Because of the limits given by the machine, it was not possible to work with this big amount of files in a satisfying manner.
There are several error logs I have to send to the developer.

DD.20140819.1127.CEST

It seems while the memory limit for a 32-bit application running on a 64-bit windows platform is somewhere under 4GB, only 2GB is available to the user side of the process.

This could be resolved if the application (Mp3Tag) was compiled with the /LARGEADDRESSAWARE flag set. Thus, then we could use up to around 3GB, which should give those running into problems plenty of extra space.

Aside from just setting the flag, I think the developer would also have verify that the app's pointers aren't limiting themselves to a 2GB address space.

Is this something we might look forward to?