Are there any benefits of using Library and 64-bit version?

Salut, ohrenkino! May i ask your help? Currently i have 40,000 files, but all of them has a lot of data in many fields. Is there a benefit for me to turn to 64 bit? Win7x64hun, without use of Library function in Mp3tag.

If you have to load them all at once for a session, then I would make use of the 64-bit version, just to be safe. 40,000 was on the edge that some users reported memory problems without the library.

Not using the library may have its drawbacks especially if you load files that have been treated long ago and would have been registered in the library before if the library had been in use.
Those already known files are then loaded much quicker than into MP3tag than those that have to be scanned again.

And if you start using the library then it would not make much difference with 40,000 files whether you use the 32- or 64-bit version. Except the lack of TAK (at the moment).

1 Like

In such case, will i be notified by Mp3tag or the system? Or is it invisible, so i would not even know about it?

(I tried the Library thoroughly, but i found it not suitable for my needs.)

Lack of memory leads to nasty effects like crashes, non-responding applications, such things.

I wonder what these needs could have been as the library is for the internal housekeeping purposes in MP3tag ...

1 Like

The Library has been refreshing every time, for a long time, even when i have been working only with outdoor files, even though i have set up the Library's folders. Usually i start to edit my new files outside of the Library for the first time. Plus, my files change often outside of the Mp3 tag, mostly in the foobar. Plus, filenames change often (but in Mp3tag). So, totally, i was wasting more time with the Library, than i gained.

I consider this a bug, but since no one else indicated it later, i did not want to bother Florian again. But i give a try again, today.

As you are so negative about the library, something that does not match with my experience at all (initial loading of uncatalogued files: more than 1 hour. Library is now populated. Close MP3tag, open it again, so that nothing is in the cache somewhere, loading the same set of files again: now 8 minutes)
I would like you to perform a test:
Start the clock:
Load the all 40,000 files into MP3tag64 with the library switched off. Take note of the time.
Switch on the library, restart MP3tag, start the clock and load the same set of files again The elapsed time should be roughly the same.
Close MP3tag again, open MP3tag, start the clock, load the same set of files again and see how long that took.
If you find no significant difference, then keep your workflow. Otherwise I would revise it.

Ohrenkino, it looks, like you are misunderstanding me. May be, because of my english? I know, how much Library would be useful. I was waiting for this feature. When it realised, i tried it a lot. In foobar it is extremely useful. But unfortunately, it is faulty, at least for me, in Mp3tag (see bold words). But i give a try again today.

Please be careful with such allegations.

Again: the library is mainly there to reduce the amount of data stored in the RAM.
A welcome side effect is that the loading for files for which the data is already in the library, goes much quicker.
Naturally, all files have to be touched and looked at - otherwise MP3tag wouldn't know which file has been changed in the meantime. And data for changed files has to be added to the library (again) which takes a little more time than for those which haven't changed.
Only in this way can MP3tag show you the really found data and not some phantoms from a previous session.
It is not clear for me what you expected from the library.

You are right, i beg Florian's pardon.
Just now i try again the phenomenon.

So, it is: if...

  • i turn on the use of Library function
  • i set D:\\Art\Music as my líbrary
  • Library is up to date, i close Mp3tag
  • i start to work with music files in D:\\Workspace, and open them in the Mp3tag
    ...then Mp3tag start to refresh the Library. While i use no one file from the library.

Strange, because Florian described it with this words (#2 for your use case):

1 Like

All right, the phenomenon not happens now. I continue to monitor. So it remains: Mp3tag 3.15, 32 bit, with turned ON Library.

Thank you for your help and time, ohrenkino.

LATER

Well, i already know/remember. The above problem has really disappeared, but with Library turned on, to save changes is always much slower, than without. Even then, i calculated: for me (with my habits) it is not practical to use Library. So i turned it off, again. (But leave 32 bit: i trust, i will notice, if there will be a memory problem. I do not load my entire Music directory very often.)

Is this also when you exclude the process mp3tag.exe from Windows Defender`?

From the documentation:

Windows Security intercepts each of the operations performed, so if you trust Mp3tag, making sure Windows Defender doesn’t scan the library database file on each change can speed up things significantly.

Thank you for your attention, @Florian.

I do not use Windows Defender. Its service is disabled in Services. Instead, i use Comodo Internet Security. The real time virus scan is disabled. Now i temporary disabled its firewall and HIPS (host-based intrusion prevention system, looking for processes, as you mentioned with Defender), too. No difference in Mp3tag's behaviour.

Test method
I turned on the Library again. Opened the whole Music directory, Mp3tag scanned it, then i closed the program. After i opened 1 folder from my directory, with 30 FLAC files. Selected all of them.

First method: started a saved Action Group, that adds field NOISY with value=1. Then i deleted this field. In both direction saving is slow.
Second method: started a saved Action Group, that adds to the end of filenames " (mono)". Then with reverse Action Group i deleted the addition. In both direction saving is slow.
Third method: i opened this folder in Total Commander. Selected all 30 files, and with the Multi Rename Tool added to all of them the above " (mono)". Then reversed, opening again the Multi Rename Tool and clicked "Undo the last rename" (it undoes on all the 30 files). In both direction saving is zippy quick.

When i tried in Mp3tag, i monitored Mp3tag.exe in Windows Task Manager: it shows many readings and writings. The system resources (CPU and RAM) were near to absolute free.

In my eyes, things point to writing the Library. My Library is 962 MB (36 thousand music files).

By the way, i did not try it, but interesting question: is there difference with 64 bit exe? Or it does not matter?

An absolutely small letters question.
Foobar's library with the same D:\\Music folder is only 32 MB, if i interpret right, and its location is c:\Users\Itsme\AppData\Roaming\foobar2000\library\

Does this modify a tag field?

Does this modify the filename?

If the answer is "yes" to both then I think you compare apples and oranges.
The action has probably to rewrite the whole file, the manipulation of the filename modifies a single entry in the file allocation table.

Salut, @ohrenkino!

Yes to both. But: i did the third test to compare with the second. It modify filenames, too (and only).

The second method (adding " (mono)" to the end of filename) modifies FAT, too; but, plus, rewrites (it must, and process monitor shows) the big Library file, too.

Of course it rewrites the library - otherwise the link between the data and the file would be lost.
And yes, it is slower to use MP3tag for such things as adding a string constant to a file name as MP3tag first reads all the tag data plus other properties while your file handler only looks at the FAT.

The test would be a valid one if you worked only with MP3tag, with

  • new files that MP3tag has never seen before, library switched off
  • the same new files, this time with library switched on
  • the same files, another attempt to load them with the library switched on.

Each time yout have to take the time and see what is quickest. That would proove it there is a benefit using the library.

And just a personal note: if you really only want to rename files, then MP3tag is probably not the fastest tool. But if you do serious tagging, then I doubt that the file renaming tool is any good.

I mean, with your suggestion, you want to prove, that using the Library is faster to retrieve data. (Or am i wrong?) Of course, i agree, i even tried it (36,000 files: 25 minutes contra 2 minutes.) But i lose much more time with the Library due to slow savings, than i gain with readings data, when files loading. This was, when i meant: "for my individual habits".

Total Commander: in this case, i only used Total Commander as a test. I make all tags' and filenames' changes ONLY in Mp3tag. With Library turned OFF there is no speed problem with both type changes.

If we think about it, it is not really just my individual habits. The job of an Mp3tag is basically WRITING tags. Plenty of tags to read all the time is basically the job of the foobar. So, i do not feel any problem with not being able to use the Library. (Of course, there may be many people, who find it very useful. We all use the program differently.)

I don't know - how many changes could you perform in the 23 minutes that you saved by using the library.
And these 23 minutes will increase, the bigger your collection becomes and they apply each time you load the files.
The comparison between Total COmmander and its functions to rename files and the functions in MP3tag to rename files will only become a real comparison if you also test Total COmmanders tagging abilities.

OK, you claim that you have not benefit from the library (which I still doubt) and you are satisfied the way you work, so everything is fine, I would say.

I think (or for me), the Library would be really VERY useful, if we used it to search for existing records to make it easier to fill out the fields. We have talked about this several times, i am looking for a link right away.

For example: Tag Panel suggestion
Or: Feature suggestion: Allow user to store singer names - #2 by incifinci

Agree, absolutely. As i wrote the same, too.