mp3tag fails while saving and creates huge files


I've been using mp3tag pretty satisfied for a long time now,
but today it started doing something extremely weird and I don't know the cause of it as I didn't change anything:

I edit the tags of M4A files with MP3tag.
When I edit a regular text tag and save the file, everything seems fine, but the file is about 1.42 GB large afterwards.
When I download a cover artwork and try to apply it, it either tells me that the file cannot be opened for writing and leaves the tmp-file inside the folder (which is 1.42 GB large) or it actually saves the cover art into the file which is - what a surprise - 1.42 GB large.

I don't know what's up with these 1.42 GB (or 1.32 GiB if you like), and the exact size varies by a few MB every time, but it's always in this magnitude.

I used v2.66 when this problem began and then updated to v2.71, but this didn't help.
I made sure that no other programs like explorer.exe or WMP blocked the file access.
I have more than enough space left on my disk and it's absolutely healthy.
I deleted the config data from the appdata-folder and used a clean installation, but that didn't help either.

This problem is really confusing me.
Thanks in advance! :music:

Another classic is insufficient access rights / ownership.
You should modify the files with the same user-id as the owner has (or change ownership).


I don't really think that ownership is a problem, because the creation and the tagging of the files is only several minutes apart. Same user, same session, same rights.

Also, for text tags and sometimes for the cover artworks, it does save the file, but the files get extremely big. But MP3tag definitely has rights to save.

I tried to give everybody Full Access though, which has always solved rights based problems in the past, but this also didn't do a thing.

Please provide a m4a test file, which has the original state before blowing up.


This zip file contains two nested zip files: The original m4a and the the changed m4a (I simply set "comment" as the comment).

Link: (

Unsurprisingly, the nested zip files aren't that far apart in terms of the size, which means that the changed m4a file contains a lot of nothing. Sadly, I can't open a 1.4 GB file with Notepad++, so I have no idea what exactly is inside the file.

Just a question: There is a ID3v1 tag at the end of the original m4a file.
What does happen, when you remove the erroneous ID3v1 tag from the m4a file?
Note: You cannot do this with Mp3tag.


Using "Audacity" I have removed the embedded metadata from the original m4a file, ...
then saved the changed sound file ("Audacity" called "FFMPEG" to do this), ...
therefore the codec has changed ...
from "MPEG-4 AAC (Nero AAC codec /" ...
to "MPEG-4 AAC (Lavf52.36.0)".
I have not paid attention to apply the previous high bit rate, ...
therefore the new file got a less bitrate and has become smaller, size now is about 5 MB.
This new m4a file can be treated by Mp3tag without any problem.


I am not sure if this helps in any way:
You can edit the tags in foobar, even add a picture without getting such a lump of a file.
After editing the file with foobar, any further editing with MP3tag keeps the same size ... so perhaps it has to do with the original data.

Removing the comment again leaves the file in the large state.

Thanks, that helped a lot!
Editing the file with foobar did exactly what you said.
Also, an older file of mine didn't show these problems with mp3tag.
I guess, something in my peculiar combination of AudioGrabber / neroAacEnc / neroAacTag recently somehow broke which creates faulty files. I don't remember changing anything in the production chain though. Maybe I'll play around with the tagging options of AudioGrabber a bit until it works again.

But this is still a very interesting behaviour!

I suspect that one of the programs that was used before MP3tag did not write the header correctly and now MP3tag finds (user) data at a position where the file length should be stored or something like that. MP3tag then uses this offset to create a large file with more or less nothing in it.

So, what we found with

is IMHO only a workaround. If foobar leaves the file as it is and even repairs the header in such a way that other programs can deal with the file again, it would be desirable if MP3tag could also act in such a error tolerant fashion.
So perhaps DetlevD's findings with the invalid V1 header is a good hint to what went wrong.
But as I am no expert, I will confine myself to the knowledge that there is a workaround.

I don't know how familiar you guys are with Audiograbber, but I found out what created the problem. This is not the AG forum, but maybe it might be interesting for you aswell.
AG has the possibility to enable custom encoders and taggers. However, it refused to directly interact with neroAacTag no matter what I tried, but with neroAacEnc it works fine.
My workaround was to pass all of AG's determined id3 information to a batch file which I set as the encoder. The batch file then does a little bit of preprocessing (removing the padding from the track number, ...) and afterwards passes the data to both neroAacEnc and afterwards to neroAacTag.
The setting which creates the faulty files is checking the box "Use ID3V1 Tag". The checkbox for the ID3V2 tag doesn't affect the files. However, unchecking this box still lets you do a freedb lookup and all the data still gets passed to my batch, so I don't really know what this box does.

Long story short, I somehow fixed the problem, but I still don't know what exactly created it.

Thanks again for your help!
Of course I agree, it would be nice if mp3tag could repair my files instead of blowing them up.

Ok, so I was totally right with my first inspiration ... the bad ID3v1 tag ... at the end of the m4a data stream.
And also ... it is not a 100 percent bad behaviour of any software in the production process ...
but as usual can happen, ...
here it was only one bad setting, small but crucial, ...
in the configuration of the workflow ... done by the user ...
(citation: "I don't really know what this box does.").

Well, I am with you, ...
Mp3tag should be forearmed against such a faulty condition, ...
or just report a failure note to the user.