Not enough memory / Runtime error

''If a 32bit executable does not have the LARGEADDRESSAWARE flag set to true, the application can't use more than 2 gigabytes. If you are on a 64bit machine with lots of memory, even if you are stuck with a 32bit process, you should ideally be able to start multiple processes each using 3+ gigabytes.''

I do not think that 4 hours for just 2 TB is normal.
And as the process did not finish, it is hard to say what the cause may be as faults on the drive, which I suspect, have still not been ruled out.

Copied the whole collection over to external drive, tried mp3tag on different PC (i5 3470 / 16GB) ; same result. Not enough memory:
https://gyazo.com/690e5632e818c0becd8767647cae17e7

Doesnt this outrule a faulty drive?

Yes, I would say so.
But again: I can load FAR more than just 5000 files into MP3tag.
So the assumption is not too far-fetched that it has to be some kind of local condition that causes it.
If the fault is still there when the collection is treated on a different hardware, we are more or less back to square one: it is most likely that one of the files has a fault.
And all this happens with the library switched on?

Just tried it on the i5 PC, this time with Library set to Ext. drive/Music folder, same result.
I will now make a copy of the whole music collection folder (327GB).
And delete the FLAC files; so MP3 is left over.
And do the same on the copy, but then delete the MP3 files; so FLAC is left over.
So the folder structure stays intact.
Re-import only MP3 based collection and re-import only FLAC based collection.
To be continued.

Hey All, I'm the friend of Bas... mp3tag ran out of memory at 2GB, so i edited the binary to support the larger address space (4GB). (editbin /LARGEADDRESSAWARE ).

Now we can load more mp3 and flac and it runs out of memory at 4GB.. My conclusion: recompile mp3tag witg 64bit support.

There has been some discussion about 64-bit address space and the conclusion was a different one - the introduction of the library function.
So I repeat the question: is the library in use or isn't it?

I'm not even sure what u mean with 'if is the library in use or not'... most people just right click on a folder and use the shell extension 'mp3tag'... this edge case of Bas is easily solves by allowing mp3tag to address more memory.. if you want to go the 'hard way', you may have to optimize it for 32 bit support... but as we live in 2018, i suggest a recompile and deliver a x64 version. Ofcourse, it may noit be as simple as 'search and replace (int, string whatever) 32 -> 64 but.. you prevent edge cases like Bas and keep users happy...

Let me chime in there.

First, thanks all who're trying to help here! As you've pointed out, it's indeed not a simple search, replace and recompile — so, as long there is no x64 version, can you try out what's described here at:

"Options > Library > Enable", restart and see if it changes anything.

Thanks Florian :slight_smile: and I wish you good luck compiling it to 64bit someday :slight_smile:

and just for the record, his whole mp3 library got loaded, but failed when he tried to 'convert tag to filename'.. it ate all his memory,,,

OK, I see. Can you do me a favor and tick the correct box?

[ ] 1.) The library feature at "Options > Library" was enabled when this happened
[ ] 2.) The library feature at "Options > Library" was not enabled when this happened

Thanks!

Ok, when doing the MP3 files all at once (4000+ files) the memory usage keeps around 160MB.
So all good, no issues. When doing a Filename - Tag; all good.
Enabled or Disabled Library, whatsoever.

When doing the FLAC files all at once (8000+ files) the memory usage gets eaten up, till around 1.800MB.
Then I get the error-message, when importing the directory.
Mind you: The library feature at "Options > Library" was enabled when this happened.
See video demo: https://youtu.be/laAHd6XsH0w

When doing the FLAC files all at once (8000+ files) with the altered binary mp3tag_3gb.exe /LARGEADDRESSAWARE, the memory usage gets eaten up up to 3.800MB before the error-message is showing (using Convert > Filename - Tag).
Mind you: The library feature at "Options > Library" was enabled when this happened.
See video demo: https://youtu.be/iDs9FYAoX_k

I've watched the videos, thanks for that. It's really amazing — I wish I could get a hold on your FLAC folder, since I'm getting totally different results here.

FYI, I've converted a 10.000 files collection to FLAC (including metadata) and when I load this to Mp3tag, the memory footprint in task manager is around ~55 MB.

Can you describe what a "typical" FLAC file looks like in your collection, i.e., are you storing large high-res cover art, or artist biographies or anything else which would explain an avarage >200KB footprint per file?

Mind you, I've deleted all the coverart, since I thought that may be the biggest value/cause of this.
Those video examples are actually done with coverart deleted on all files.

I don't have a particular typical FLAC, but I will make a package with the ones I got (using different FLAC versions) and drop you a mail with link for further inspection.

Thanks, @bascurtiz! I'll look into those then, maybe I can find a memory leak or something related.

You got mail^ - subject: Link to FLAC files

1 Like

I've checked the files and I think the TRAKTOR4 fields are causing the issues. They're around ~120KB in size, put another of those on the undo stack and we're almost at 2GB for ~8000 files.

The files also contain various versions of acoustic fingerprint data (i.e., ACOUSTID_FINGERPRINT and BEATUNESPRINT) which add to the high use of memory.

I don't have a solution for this in Mp3tag right now, but wanted to give this as information for you. If you don't use Traktor, I guess you can safely delete those fields. However, if you're using Traktor they're probably needed for some application-specifc features.

I've been using beaTunes and SongKong indeed.
They do a fingerprint for matching.

I also use Mixed In Key. & I do use Traktor.
TRAKTOR4 tag doesnt ring a bell, but a quick google search, it's Traktors private tag. Or proprietary tag.
Whatever that means lol.

Anywho, glad we finally found what's eating up the memory.

FYI, Mp3tag v2.88 is now LARGEADDRESSAWARE by default.