anthwlock / untrunc

Restore a truncated mp4/mov. Improved version of ponchio/untrunc
GNU General Public License v2.0
2.08k stars 199 forks source link

bad track: 'icod' #62

Closed landross closed 4 years ago

landross commented 4 years ago

Have tried many methods and finally found this branch that runs on Windows, thank you! I'm stuck though with the below. Any pointers will be appreciated. Thanks.

>untrunc -v file000659.mov file000575.mov
Info: version '61c7dda' using ffmpeg '3.3.4'
Info: reading file000659.mov
Info: parsing healthy moov atom ...
ftyp_ = 'qt  '
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'file000659.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2010-08-25T17:16:21.000000Z
  Duration: 00:00:43.91, start: 0.000000, bitrate: 189012 kb/s
    Stream #0:0(eng): Video: aic (icod / 0x646F6369), yuv420p(bt709, top coded first (swapped)), 1920x1080, 187372 kb/s, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc (default)
    Metadata:
      creation_time   : 2010-08-25T17:16:21.000000Z
      handler_name    : Apple Alias Data Handler
      encoder         : Apple Intermediate Codec
      timecode        : 00:00:00;00
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, s16, 1536 kb/s (default)
    Metadata:
      creation_time   : 2010-08-25T17:16:21.000000Z
      handler_name    : Apple Alias Data Handler
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74)
    Metadata:
      creation_time   : 2010-08-25T17:16:21.000000Z
      handler_name    : Apple Alias Data Handler
      timecode        : 00:00:00;00
assuming constant duration of 100 for 'icod' (x1316)
assuming constant duration of 1 for 'sowt' (x2108928)
Warning: using expected sowt frame size of 2*4, instead of 1 as found in stsz
Info: special track found (tmcd, 'Time Code Media Handler')

Info: unknown track 'icod' found -> fallback to dynamic stats
created dummy track 'free'
first_failed: 3 of 100
order: (0, 4)
isTrackOrderEnough: 0  (sz=0)
Error: bad track: 'icod'
anthwlock commented 4 years ago

If you send me the files (healthy+broken) I will take a look. You can upload them on wetransfer. If you think they are too big, try untrunc -sh file.mp4.

anthwlock commented 4 years ago

Any pointers will be appreciated

I found this: https://wiki.multimedia.cx/index.php/Apple_Intermediate_Codec

landross commented 4 years ago

I have sent two files through wetransfer, one good one bad. I think these files are HDV tapes ingested through an old version of Final Cut hence the Apple Intermediate Codec.

anthwlock commented 4 years ago

Detection and size-prediction of the new 'icod' track was straight forward. However your files contain random data sequences at (seemingly) random locations. Luckily they have a purpose: pad the next chunk so it's offset is a multiple of 4096. So their length is predictable.

try https://github.com/anthwlock/untrunc/commit/bf5727bc970c8b52e487bec1e80bac957081e477, good luck!

landross commented 4 years ago

Thank you so much. I used the latest Windows 64 build and was able to recover all the videos, which is great, however wasn't able to recover audio.

Info: Found 33075 packets ( icod: 1374 sowt: 0 tmcd: 1 ) Info: Duration of icod: 45s 845ms (45845 ms) Info: Duration of sowt: (0 ms) Warning: Unknown sequences: 1 Warning: Bytes NOT matched: 3.95KiB (0.0003829%) Info: pruned empty 'sowt' track Info: saving file000575.mov_fixed-dyn.mov

I believe sowt is the audio track, just wondering if there is any chance to recover that. When using MediaInfo on the healthy file: Format : PCM Format settings : Little / Signed Codec ID : sowt

Many thanks again.

anthwlock commented 4 years ago

Oh right, didn't even notice that.. The problem was that the sowt-chunk-starts have no predictable pattern, neither do the icod-chunk-ends. But since your file only has two main tracks, one can use "inverted matches": If no other track matches, it's considered a match. Current implementation of this is not too robust, and only works for fixed size chunks. But that should work in your case. See 389983a55484b29902b5896270510def3d339bb6.

But be aware of some rare, but loud audio distortions. They are caused by "garbage data" inside of the mdat atom. In your case, this garbage data (probably) consists of misplaced mp4-atoms.