Forum Thread

PS3 'Corrupted Data' mp4 files -- a possible solution for some

1,867 729 July 1, 2013 at 10:38 PM
I occasionally encounter mp4 files that show as "Corrupted Data" when I copy them to a USB stick and plug it into my PS3. Trying to play one of those files would show "The data is corrupted" or something similar.

Because the mp4 files I've downloaded are almost always in a format the Playstation 3 supports (x264/avc, aac) I've been accumulating them so I could take a shot at figuring out what was wrong. I ran the files through AtomicParsley [] and I noticed two things the "Corrupted Data" files in a PS3-friendly format had in common.

1. They had passed through handbrake (according to the "©too" atom).
2. They had leftover null bytes at the end of the file.

#2 was interesting. AtomicParsley /path/to.mp4 -T 1 shows that as an extra free-type atom. Here's an example:
Atom free @ 290040138 of size: 132, ends @ 290040270
Atom free @ 290040270 of size: 132, ends @ 290040402

~ denotes an unknown atom
Total size: 290040271 bytes; 55 atoms total. AtomicParsley version: 0.9.0 (utf16)
Media data: 288416189 bytes; 1624082 bytes all other atoms (0.560% atom overhead).
Total free atom space: 396 bytes; 0.000% waste.

Note that 290040402 > 290040271. In this particular case there's a single extra null byte in the file (290040271-290040270). As a result of that AtomicParsley (and I assume the PS3's parser) assume that's the start of another atom chunk but in actuality there is no other atom.

I used AtomicParsley to remove all free space. To do that first in the command window you're working in you have to set the environment variable AP_PADDING.
Now if you run AtomicParsley with the --freefree command set to level 1 you can remove free-type atoms at that level:
AtomicParsley in.mp4 --freefree 1 --output out.mp4
Wiping the free atoms has worked for me in all the cases I've tried. Atoms can be nested so you may not be able to do just level 1, and instead have to do other levels. I haven't had to so far and I've successfully fixed about a dozen this way already. There's more on the --freefree command by viewing its help usage which is easier to read from a file:
atomicparsley --file-help > file_help.txt
notepad file_help.txt

In many cases I notice after I wipe the free atoms the mdat atom (the main content) is moved to the end of the file. There is an option to prevent that (--mdatLock) but I haven't needed it. I've tried both with and without and the files are playing for me in either case.



Sign up for a Slickdeals account to remove this ad.

This comment has been rated as unhelpful by Slickdeals users
Joined Mar 2009
Schrödinger's Frog
18,518 Posts
2,087 Reputation
Interesting. I'll have to remember this.
Reply Helpful Comment? 0 0
This comment has been rated as unhelpful by Slickdeals users
Joined Dec 2005
L6: Expert
1,867 Posts
729 Reputation
Original Poster
Well it turns out they haven't all passed through handbrake. I fixed one today "freeIsoMedia File Produced with GPAC 0.4.6-DEV-rev".

The conspiracy continues: I'm starting to wonder if maybe someone is appending null bytes to mp4 files purposely to change a file's hash and make it look original. One of the handbrake files that I fixed I later found another version of the same file with a different hash. Guess what was missing? The extra null bytes at the end. So maybe someone on the internets read my original post and fixed an mp4 file or much more likely maybe someone or something is appending null bytes for some reason. Any thoughts?
Reply Helpful Comment? 0 0
Page 1 of 1
Join the Conversation
Add a Comment
Copyright 1999 - 2018. Slickdeals, LLC. All Rights Reserved. Copyright / Infringement Policy  •  Privacy Policy  •  Terms of Service  •  Acceptable Use Policy (Rules)  •  Interest-Based Ads
Link Copied to Clipboard