File limit & Command line usage


  1. Today I wrote a (powershell) script that returned the cover information of all my files to me. I want everything to be .jpg and filter the .png (and a single bmp) out. I end up with a list of folders, in a text file, that I want to open in mp3tag. Unfortunately, I don't manage to add multiple folders to mp3tag from the command line. For a single folder it would be mp3tag.exe /fp:"". But several folders? If I try to loop through the array, it removes the old folder and adds the new one - while I want to append of course.
    As far as I know, the command line feature was never meant by Florian to be public (although I've seen that it's been published meanwhile) and is actually the parameter used for the context integration. Because from the context menu several folders can be added at the same time to mp3tag, I'd conclude that this should be possible from the command line too; without the batch FOR loops I saw elsewhere (and that I really can't get to work). Does anyone have any clues on this?

  2. I found a post where someone asked what the file limit is of mp3tag, but no one could give an answer. I have a pretty big collection and I haven't found the limit yet of files it can load: I did about 180 000 (which took ages - OK, an hour or so - on an i7 with 24GB RAM and consumed 2GB of RAM!), BUT the program returns an error (but doesn't crash) when trying to apply an action to the collection (in my case: extract cover to "folder.jpg"). I had to do it in 3 times 60 000 to make it work. My guess would be that the limit is 99 999 or so. Still, it would be nice if someone (Florian?) could give a definitive answer to this.

PS. Anyone interested in Powershell and ID3 tags: you only need taglib-sharp.dll to get started. Feel free to ask me more info if you can't get started by googling.

Isn't the context-menu handling for Mp3tag now done by DLLs? Perhaps Mp3tag is doing this:

To load multiple folders into the program write the folder paths in a m3u file and load it into Mp3tag.

There is no definite answer to the file limit problem. The only certain thing is that Mp3tag can only use ~3GB of RAM (or whatever the exact value is) due to it's 32bit architecture.

Then it depends on your audio files, how many tags they have,...
Embedded covers for example require more RAM.
And also the amount of columns that are in use matters.

Thank about the M3U approach. I didn't have the time to test it yet, but it sounds as a great solution.

For the file limit: As mentioned, I managed to load 180 000 songs into mp3tag. I can add to it that I used 18 columns and embedded covers. The RAM didn't get above 2GB and the application didn't crash either, so it doesn't look as if the limit was related to the RAM - although I didn't monitor the memory usage at the moment I applied an action to all of those files of course. Blast, I should have noted the error I got back. I'll load the whole collection one of these days again and look at memory an the exact error. It's out of curiosity anyway that I wanted to know this - I seldom have to load my whole collection into mp3tag at once, but I wanted to do a spring cleaning (do you say Fr├╝hlingputz ? ^^)

Just to get the terms right: any 32-bit application cannot use a memory space that extends beyond the odd 3GB - in this context it does not matter whether that address space can be found in the RAM (which is quicker) or on the HDD (which is very slow in comparison) in the outsourcing file (?!).
So it might be just about possible to load so many files but then MP3tag will create a log to foster for the undo-function. And this might then exceed the (physical) limits.
(Just to do that part of the cleaning to explain that more ram banks actually do not help the 32-bit architecture as only a little less than 4GB are used.)

Yes, it is "Fr├╝hlingsputz".