Not enough memory / Runtime error

[ohrenkino]

@movtar

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?

64 bit port

No, I don't think mp3tag would directly benefit from x86_64, and there are no new fancy features in the 64-bit APIs yet. I was just wondering whether you plan to switch to 64 bit at some point, since 32-bit versions of some libraries you are using might become underdeveloped and buggy or just go away in a couple of years. Regards, nickless

[movtar]

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...

[Florian]

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:

Mp3tag v2.86 released

I've just released Mp3tag v2.86! This version comes with a wide variety of changes, most notably: Library to permanently store metadata Normally, Mp3tag reads metadata from files when loading files, directories or playlists and stores the data in memory. Then, when you close Mp3tag, the data once read from the files is discarded and must be read again the next time you're working with those files in Mp3tag. This can become both time consuming and memory intensive, especially …

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

[movtar]

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

[movtar]

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,,,

[Florian]

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!

[bascurtiz]

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

[Florian]

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?

[bascurtiz]

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.

[Florian]

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

[bascurtiz]

You got mail^ - subject: Link to FLAC files

[Florian]

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.

[bascurtiz]

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.

[Florian]

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