Failed recovering the file about untrunc HOT 3 CLOSED

Just send me the files, I will have a look at them.

from untrunc.

Thank You for replying and your support.

Just wow, I had to learn the art of MP4 container how encoding are packaged. It is super interesting.
I have successfully recovered 100% of the video, I was able to watch the recovered video right at the moment I shutdown the camera.

Using epic reverse engineering tactics (I dislike it)
I spent 8 days x 13 hours = 104 hours in total to learn all of this.

I created some tools in pure c code to do this. So far I have only spent time in recovering the 1 first track which is the video. The video file was seriously corrupted, the "mdat" atom had the wrong payload header, this leads me to think that the camcorder must provide the correct mdat payload during the end of the video recording session. The camcorder seems to not complete the video session, I possibly haven't turned off the camorder and therefore video file ended corrupted.

Next is to recover the 2nd track which is the audio. I'm sure the process is same as to the first track.

I used some MP4 parser tools like:
mp4analyser.py and MP4Box.js

MP4Box.js have an online platform which the videos can be played and analysed:
https://gpac.github.io/mp4box.js/test/filereader.html

Atomic Parsley

bento4 "mp4dump".

The hex editor I used was "imhex" and "rehex".
I used rehex to do range selection of hex code.
Imhex to do searching of binary.

For some reason bento4 "mp4edit" makes it difficult to replace moov atom, it creates a new mdat atom when replacing/inserting moov atom. So I had to manually copy and replace the moov at to the corrupted video using a hex editor.

I created few c programs to find, evaluate, extract and write the start code offsets in the mp4 file (which uses H254 codec encoding, it seems to not use the MP4 annex-b protocol):
0x658880 and 0x219A00

The c program does all the important tasks in 5 seconds for a 20 min video.
I literally created a new moov atom from scratch.
The most important atoms in the moov atoms are:
stts atom
stss atom
stsz atom
co64 atom

I also had to modify the duration in the atom, since a valid working video from the same camcorder has a different duration. The corrupted video length is different. I had to create some few simple formulas to calculate accurate values for many parameters.

The co64 offset first starts with the start codes of "0x658880" frames and then continues with "0x219A00" frames. The process repeats for each sample. Each sample contains 15 frames.

I'll now focus in recovering the audio, if I can't do it I'll email them to you.

I'll possibly make an open source github, the processes I use seems to be exactly the same how some automated commercial video recovery implements. They look into the mdat and extract data from there on (this is what I'm assuming).

Honestly for $17, I would seriously spent the money and save 8 days, however the commercial guys didn't give me the proper audio which is just as important if not more important than the video. (had some police incident that I recorded with my bodycam)

Also ChatGPT helped me a lot if finding and correcting bugs and giving some ideas.

Here is the recovered atom structure:

$ AtomicParsley /home/user/Desktop/corrupt_video/20230309064234_000001_modified.MP4 -T

Atom ftyp @ 0 of size: 28, ends @ 28
Atom skip @ 28 of size: 14700, ends @ 14728
Atom mdat @ 14728 of size: 1345570428, ends @ 1345585156
Atom moov @ 1345585156 of size: 458575, ends @ 1346043731
     Atom mvhd @ 1345585164 of size: 108, ends @ 1345585272
     Atom trak @ 1345585272 of size: 458459, ends @ 1346043731
         Atom tkhd @ 1345585280 of size: 92, ends @ 1345585372
         Atom mdia @ 1345585372 of size: 458359, ends @ 1346043731
             Atom mdhd @ 1345585380 of size: 32, ends @ 1345585412
             Atom hdlr @ 1345585412 of size: 45, ends @ 1345585457
             Atom minf @ 1345585457 of size: 458274, ends @ 1346043731
                 Atom vmhd @ 1345585465 of size: 20, ends @ 1345585485
                 Atom hdlr @ 1345585485 of size: 44, ends @ 1345585529
                 Atom dinf @ 1345585529 of size: 36, ends @ 1345585565
                     Atom dref @ 1345585537 of size: 28, ends @ 1345585565
                         Atom url  @ 1345585553 of size: 12, ends @ 1345585565
                 Atom stbl @ 1345585565 of size: 458166, ends @ 1346043731
                     Atom stsd @ 1345585573 of size: 150, ends @ 1345585723
                         Atom avc1 @ 1345585589 of size: 134, ends @ 1345585723
                             Atom avcC @ 1345585675 of size: 48, ends @ 1345585723
                     Atom stts @ 1345585723 of size: 24, ends @ 1345585747
                     Atom stss @ 1345585747 of size: 9972, ends @ 1345595719
                     Atom stsc @ 1345595719 of size: 28, ends @ 1345595747
                     Atom stsz @ 1345595747 of size: 149336, ends @ 1345745083
                     Atom co64 @ 1345745083 of size: 298648, ends @ 1346043731
------------------------------------------------------
Total size: 1346043731 bytes; 24 atoms total.
Media data: 1345570428 bytes; 473303 bytes all other atoms (0.035% atom overhead).
Total free atom space: 0 bytes; 0.000% waste.
------------------------------------------------------
AtomicParsley version:   (utf8)
------------------------------------------------------

from untrunc.

I was able to to recover about 97% of the audio.

For my purpose seems to be 100%.
There seems to be some sync issue. However I can extract the audio and sync it with the video.

Recovering the audio is much more difficult and tricky than recovering the video. Because find the child samples is more random and difficult to find in simple search.

The child audio samples have no specific set identification, it's identification varies for each child sample.
However it doesn't vary by much and can be identified to as much as 97% of the audio track.

By the way I had to create my own tools to do this.

The parent audio samples always starts with the hex code: 0x0012C35
While child audio samples uses some form of algo to be identified:
child sample hex structure: [01 aa bb] where "bb" is always constant of the following hex values 35, 55, 9F, F5 and "aa" is random.

from untrunc.