I believe I found a similar bug. After saving a new Comment field with TagLib, Mp3tag no longer detects an MP4 tag in my file. iTunes and foobar2000 (and TagLib) can still read the file.
Looking in the file with a hex editor, it appears the tag data is all still there, so it seems Mp3tag is breaking where no other major player is, when attempting to read an MP4 tag.
I can send a sample file (before and after) to the developers (Florian or someone else?) if needed. This also affected Mp3tag 2.55a (I'm now using 2.57 which also can't find the MP4 tag).
I had a look at them and it seems that the size from the atom header is invalid for the after.m4a file. You can easily validate this by looking at those numbers:
Total file size 6658750
Atom ftyp @ 0 of size: 24, ends @ 24
Atom moov @ 24 of size: 50624, ends @ 50648
Atom free @ 50648 of size: 4096, ends @ 54744
Atom mdat @ 54744 of size: 6604298, ends @ 6659042
You can see that the mdat atom exceeds the total file size.
Are you one of the developers of TagLib or a contributor? If so, can you investigate this issue?
I haven't contributed very much, just reported several issues since I am intending to use the library for an Android project.
Since my last post I was investigating, but it took longer than I wanted... and I can't reproduce. I managed to only create correct files, when compared with the original "after.m4a" with HxD hex editor, I got "the chosen files are identical. the file sizes are different, though!" Windows says the "size on disk" is identical (6,660,096 bytes) but the "size" differs (6,658,750 vs 6,659,042).
I filed a report on GitHub but since I can't reproduce I don't know what to expect.
You can send a sample file to