Encoded .mp4's Are Corrupted After Tagging

[Superfield]

I do a lot of encoding of .mkv to .mp4 (mostly to hardcode subtitles for compatibility for mobile devices), and I've run into a recurring problem. I like to tag my .mp4's using Mp3tag for organizational purposes, but I've found that my files are often, but not always, corrupted after I've tagged them. I'll just be watching the video and then there'll be a "hole" in the video. I can confirm that the files were just fine prior to tagging.

This doesn't apply to all .mp4's; I've downloaded hundreds of .mp4's from YouTube, tagged them the exact same way, and have never had a single problem with them. And it's not exclusive to my personal encodes, either; some .mp4's that I've downloaded from other sources seem to be more susceptible to being glitched.

This was a major pain until just recently (because I had no way of telling if a file was glitched or not unless I watched it), when I discovered that if I ran the audio of that tagged file back through my encoder and jump to the end, the audio will be glitched if there's a hole in the file. So, I've had to resort to copying any files after encoding, tagging the copy, running the audio check, and then re-copying, re-tagging and re-checking until I get a tagged file that isn't glitched.

What I'm looking for is a way to:
Repair files that have been glitched because of tagging, and/or
Encode/tag files without them getting corrupted.

I use Xvid4PSP 5.10.346 to encode and the latest versions of Mp3tag to tag. I can provide an example of an untagged file that runs fine and a copy of that file after tagging that was glitched.

And for what it's worth, it seems as though doing things one at a time makes the likelihood of the files glitching go down - specifically copying and tagging.

[El Heggunte]

For tagging MP4 files specifically, you could try MP4Box or L-Smash's remuxer.

IF the problem persists, then the cause of the problem is not mp3tag (or the version of it that you're using)
— maybe it's another application that's interfering with mp3tag, or, equally possible, it's a faulty HDD...

[Superfield]

All of the files are being stored and worked with on an external hard drive... How would I check if that's the cause?

[Budman1]

Sounds like possibly it's a timing issue, especially since tagging singly works better. Writing to an external drive sometimes takes longer and Windows is not great about waiting after it hands off a file to be saved but goes on about the rest of the code in some programs.

I'm not sure how MP3Tag is written but my own programs I've written have encountered similar problems and I have had to build a delay into them to allow saved files to be completed and not shown as 'busy' while being written or just failing when subsequent operations are supposed to be performed on them during clean up.

Easiest way to check is with a small file written to a local disk. Then a bunch of small files (same file renamed a bunch?) to a local disk. Then a bunch of LARGE files written to a local disk. If it's a timing issue it will show up.

[Superfield]

So, tag a single small file, then a bunch of small files at the same time, then a bunch of big files at the same time and see if I end up with any errors? I guess I'll try it.

Any ideas on repairing the files? Again, I can provide an example of a glitched one.

[Budman1]

If you have an example it might help and it might answer a lot of questions of how it got glitched.

[Superfield]

Untagged, fine: https://www.dropbox.com/s/sbhflvtglhxftoj/A%20Little%20Snow%20Fairy%20Sugar%2005%20Eng...ed%29.mp4?dl=0

Tagged, glitched at about 17 minutes: https://www.dropbox.com/s/lypzxtqivjqz2h4/A%20Little%20Snow%20Fairy%20Sugar%2005%20Eng...in%29.mp4?dl=0

[Budman1]

Looks like your 'STCO' atom (Chunk Offset Atom) of the MP4 video got hosed just before the UDTA (User data) Atom got added. That's probably why the video jumps from 17:03 to about 17:45 and misses a short portion on the glitched one.

Fixing it will be extremely hard since the structure of an MP4 is intertwined together and VERY hard to decypher:

Atom stbl @ 155491 of size: 321786, ends @ 477277
Atom stsd @ 155499 of size: 94, ends @ 155593
Atom mp4a @ 155515 of size: 78, ends @ 155593
Atom esds @ 155551 of size: 42, ends @ 155593
Atom stts @ 155593 of size: 24, ends @ 155617
Atom stsc @ 155617 of size: 37312, ends @ 192929
Atom stsz @ 192929 of size: 271700, ends @ 464629
Atom stco @ 464629 of size: 12648, ends @ 477277
Atom udta @ 477277 of size: 516, ends @ 477793

Best way is for it not to happen by using another tagging system such as MetaX (NOT freeware) of FFmpeg. I also question updating MP4 with MP3 tagger? The Metadata is different for each. It may have worked but... Check out this page for appropriate Metadata for mp4 based containers:
http://atomicparsley.sourceforge.net/mpeg-4files.html

FFmpeg works okay or seems to. https://www.dropbox.com/s/u6x6zu7gvo4we2q/A%20Little%20Snow%20Fairy%20Sugar%2005%20Eng...ed%29.mp4?dl=0

[Superfield]

Okay, so, I haven't done the full test yet, but I did mass-copy about 30 large video files (all about a half gig) from my external hard drive to my internal and mass-tagged them. And not a single one came back with an error. At this point, it certainly seems as though I just need to be sure to do the initial tagging with the files on my internal hard drive.

EDIT: I also found that, when tagging videos on my external drive, it can take a good 5-10 seconds for the tag to write (for the first time; for an already-tagged video, it's instant). On the internal drive, it's instant.