[AF] "MovieDataOffset" in MP4 files saved with MP3Tag


I am experiencing a problem with files (MP4) that have been saved from MP3Tag after adding Metadata Tags to the file e.g. Title, Genre etc.

The issue is that when a modified file is played via the Emby for Android app - the libvlc library miss interprets the file and errors out - without any useful info other than it thinks its reached the end of the file. If i play the original file it plays without issue. So something in a MP3Tag edited file is causing it to have a problem. This is not just one file but affects a large number all having been modified by MP3Tag over the last few months.

It appears when comparing the original file with the modified file that the only difference is the MovieDataOffset value changes e.g. from 48 to 1510979 which if this value is bytes is a large jump when i only modified the Title Tag field. Mp3Tag appears to add about 4k to the file size if it has no metadata initially and you add some which is fine to make space for Tags.

I have tested this with numerous files and any modified with MP3Tag will not play properly - the original files play fine.

Any help or suggestion welcome.


There has been a thread where actually the file size got increased (and I was a little off-track):
Perhaps this is something similar.


Hmm Maybe - but its not the filesize that changes (other than first edit>save adds 4k) but the offset of where the data starts that appears off to me and is possibly confusing the android player.

The files play fine on other players e.g. in Chrome so the files are not corrupt as implied in the post you linked too.

If i run a video back thought handbrake after editing in MP3tag it “corrects” the issue and it plays fine via the Emby Android app without transcoding.

So if its not the media offset then its something else that MP3Tag is doing thats causing the issue.

As i have thousands of files edited by MP3Tag running them back through handbrake is not an option.


I’m not aware of the “MovieDataOffset” value. How did you determine the offset change?

Kind regards
– Florian



I used ExifTool to extract the metadata of the files into a easy readable text format.

Test6.txt (3.64 KB)

Test7.txt (3.64 KB)

Test7 is straight from Handbrake and has not been edited by Mp3Tag

Test6 has been edited by Mp3Tag - you will note the last two lines in the text file have “moved” from near the top of the file - see Test7 and the MovieDataOffset has changed. which is expected but the number looks too large to me.

This is the only obvious change to the test6 file i can find that causes issues when trying to play via the android libvlc library. There maybe something else i am missing but once edited and saved in mp3tag the file does not get treated the same by the library - Test7 direct plays and Test6 get transcoded as it has issues reading the file.

Test6.txt (3.64 KB)

Test7.txt (3.64 KB)


Can you try “Optimize MP4” on that file via the right-click menu in Mp3tag and see whether this makes the file readable again?

Kind regards
– Florian



Tried the optimise option and unfortunately this appeared to have no effect other than the media offset value did change a bit

Test8.txt (3.64 KB)

Test8.txt (3.64 KB)


I did some further research on this issue and it seems that the “MovieDataOffset” you’re referring to is simply the byte offset of the mdat atom in the MP4 file. This atom contains the movie data and is located before the moov atom (the movie metadata) in the initial file that is working for you.

After editing the file with Mp3tag (adding tags and maybe also cover data) the moov atom is moved near the beginning of the file (right after the ftyp atom). This is recommended so that streaming applications can display tag information without needing to seek throughout the movie data.

I’ve also had a look at the current libvlc source code and couldn’t find an issue in this regard.

Can you as the Emby people to have a look at this? Maybe they’re using a really old version of libvlc, I’m really out of ideas at this point.

Kind regards
– Florian