Navman MiVue 680 super HD - sandisk 32 GB MicroSd card - can't read

Joined
May 28, 2014
Messages
35
Reaction score
5
Location
Australia
Country
Australia
Dash Cam
i1000 (A10 and F20 chipsets)
Hello,

A friend of mine has handed me a puzzle. He has a Navman MiVue 680 super HD which some very special footage on it.
You can view the footage on the devices display panel (There are hours of it) or even start a fresh recording.
Plug the unit into a PC via USB and a drive letter may/might not pop up and if it does, it's either empty or wants to be reformatted.
Plug into an SD reader and you get an error or sometimes a drive letter may/might not pop up and if it does, it's either empty or wants to be reformatted.
Pop it back into the GPS unit and everything can still be played back.
Change USB cable, change laptops, change SDcard readers, same issues.

It does appear the GPS/Dashcam is fine and maybe the issue is with the card but I am still trying to get my head around it as this card has the footage we need.

I did manage to use data recovery software (on one of the chances it popped up) and got some large 500 mb files back as MP4 but I can't play the files back.
Looking at the file headers, they look like valid Quicktime MOV files. I just can't seem to get them to play with my software (or VLC).
again, on the device the videos play fine. In the recovery, it has read errors for the first 2 % of the SDcard.

So either the navman can skip errors, it might not read/write the first bit of the SDcard or maybe a strange format ?
My recovery software did at one point suggest Fat 12 (Which is floppy disk format). I would suggest it is meant to be fat32.

I believe from the friend, he formatted the card with the Navman.

I an not suspecting format as the main issue, as I also get "disk not found" and sometimes it does not appear under My Computer at all.

all very odd.

so, if people can confirm, yes, the card needs to be Fat32.
what format the video is in and what I can playback with

any suggestions as to the problem or a work around.

I am about to ditch my windows system and try and recover with linux except I seem to have 29 Gb of valid MP4's that do not playback.

Very odd.
 
I should point out the file headers seem to contain ftypqt qt correctly to identify quicktime format,
I also tried MiVue Manager
 
Using profile "dashcam - generic" on https://fix.video

It comes up with
Container: MPEG-4
Video Size: 2304x1296
Codec Video: avc1
Bitrate Video: 12.6 Mb/s
FrameRate: 25.000 FPS
Aspect Ratio: 16:9

Settings on the Navman are

5 min
1296p
30fps

using fix.video it tells me the clips are 5 mins long, gives me a 10 second preview and snapshots at a few intervals so it seems the video is there but somehow corrupted and yet on the Navman, playback is fine
 
My working theory is that Navman do not create normal MP4 files. All Mp4 video file headers contain what are called Atoms. They are key bit of info identifying file type, codec and data.

Technical Info:
I think the problem is that the Atom in the Video container that contains Video Codec info, is missing or maybe after the data section. (Incorrect placement)
I can see the FTYP in the header (magic part is qt) and I can see mdat. this means I know it is a Quick time MP4 and I can see the video data.

Where I expect Moov, I see "skip". This is the section that would describe codec.

I have tried recovery using
Djifix
Grau GmbH video recoverer
Remo
stellar
Yodot

no success
 
I have had a little success using ....

recover_mp4 v1.92 (C) 2011-2017 Dmitry Vasilyev <slydiman@mail.ru>

Analyzing file 'ref.MP4':

'ftyp' 0x0 [20] Major Brand: 'qt ', Minor Version: 0x200
Compatible brands: 'qt '
'skip' 0x14 [16]
Unprocessed 8 bytes
'mdat' 0x24 [553732334]
'moov' 0x21014912 [113064]
'mvhd' 0x2101491A [108] Movie Header: Time scale 29918, Duration 8978000 (300.087 sec)
Rate 1, Volume 1
Creating time: 2015/01/01 0:00:03
Modification time: 2015/01/01 0:00:03
Next Track ID: 3
'trak' 0x21014986 [74716]
'tkhd' 0x2101498E [92] Track #1, Duration 8978000
Resolution: 2304x1296
Creating time: 2015/01/01 0:00:03
Modification time: 2015/01/01 0:00:03
'mdia' 0x210149EA [74616]
'mdhd' 0x210149F2 [32] Media Header: Time scale 29918, Duration 8978000 (300.087 sec)
Creating time: 2015/01/01 0:00:03
Modification time: 2015/01/01 0:00:03
'hdlr' 0x21014A12 [45] Component Type: {0000}, Subtype: 'vide'
'minf' 0x21014A3F [74531]
'vmhd' 0x21014A47 [20]
'dinf' 0x21014A5B [36]
'dref' 0x21014A63 [28]
'url ' 0x21014A73 [12]
Unprocessed 4 bytes 00 00 00 01
'stbl' 0x21014A7F [74467]
'stsd' 0x21014A87 [135]
'avc1' 0x21014A97 [119] Video Sample 2304x1296, 24 bits,
'avcC' 0x21014AED [33] AVC video 2304x1296, Baseline Profile, Level 4.0
'stts' 0x21014B0E [24] Time-to-Sample[1] (#: Count * Duration):
0: 8978 * 1000
'stss' 0x21014B26 [2412] Sync Sample[599] (#: SamplesNumber):
0: 1
1: 16
2: 31
3: 46
4: 61
5: 76
6: 91
7: 106
8: 121
9: 136
10: 151
...
'stsc' 0x21015492 [28] Sample-to-Chunk[1] (#: FirstChunk / SamplesPerChunk / SampleDescIndex):
0: 1 / 1 / 1
'stsz' 0x210154AE [35932] Sample Size[8978] (#: Sample Size):
0: 0x23d08
1: 0x1cd93
2: 0xd700
3: 0x1ab1c
4: 0x827c
5: 0x9065
6: 0x16acc
7: 0x56ac
8: 0x8c73
9: 0x1611d
10: 0x52a6
...
'stco' 0x2101E10A [35928] Chunk Offset[8978] (#: Chunk Offset):
0: 0x42c
1: 0x24534
2: 0x416c7
3: 0x4f1c7
4: 0x6a0e3
5: 0x7275f
6: 0x7bfc4
7: 0x92e90
8: 0x9893c
9: 0xa19af
10: 0xb7ecc
...
'trak' 0x21026D62 [38232]
'tkhd' 0x21026D6A [92] Track #2, Duration 8975848
Creating time: 2015/01/01 0:00:03
Modification time: 2015/01/01 0:00:03
'mdia' 0x21026DC6 [38132]
'mdhd' 0x21026DCE [32] Media Header: Time scale 32000, Duration 9600480 (300.015 sec)
Creating time: 2015/01/01 0:00:03
Modification time: 2015/01/01 0:00:03
'hdlr' 0x21026DEE [52] Component Type: {0000}, Subtype: 'soun', Sound Media Handler
'minf' 0x21026E22 [38040]
'smhd' 0x21026E2A [16]
'dinf' 0x21026E3A [36]
'dref' 0x21026E42 [28]
'url ' 0x21026E52 [12]
Unprocessed 4 bytes 00 00 00 01
'stbl' 0x21026E5E [37980]
'stsd' 0x21026E66 [124]
'ms??' 0x21026E76 [108] Sound Sample v1, 2ch, 4 bits, 32000 Hz
'wave' 0x21026EAA [56]
'frma' 0x21026EB2 [12]
Unprocessed 4 bytes 6D 73 00 11
'ms??' 0x21026EBE [28]
Unprocessed 20 bytes
{0000} 0x21026EDA [8]
'stts' 0x21026EE2 [24] Time-to-Sample[1] (#: Count * Duration):
0: 9600480 * 1
'stsc' 0x21026EFA [28] Sample-to-Chunk[1] (#: FirstChunk / SamplesPerChunk / SampleDescIndex):
0: 1 / 1017 / 1
'stsz' 0x21026F16 [20] Sample Size[0] (#: Sample Size = 0x1):
'stco' 0x21026F2A [37776] Chunk Offset[9440] (#: Chunk Offset):
0: 0x2c
1: 0x24134
2: 0x412c7
3: 0x4edc7
4: 0x69ce3
5: 0x7235f
6: 0x7b7c4
7: 0x7bbc4
8: 0x92a90
9: 0x9853c
10: 0xa15af
...
----------------------

File 'video.hdr' created succesfully
File 'audio.hdr' created succesfully
----------------------

Video statistics:
Sample Size: Min 0x42e5, Avg 0xc070, Max 0x4efd5
Samples Per Chunk: Min 1, Avg 1, Max 1

Count 599, [ 61 9a 08] Size Min 0x46b6, Avg 0xa8b1, Max 0x2956a
Count 599, [ 61 9a 10] Size Min 0x59f2, Avg 0x9d63, Max 0x12981
Count 599, [ 61 9a 18] Size Min 0x5089, Avg 0xab83, Max 0x1ab18
Count 599, [ 61 9a 21] Size Min 0x6617, Avg 0xb7d1, Max 0x18535
Count 599, [ 61 9a 29] Size Min 0x5ccd, Avg 0xb64c, Max 0x1537e
Count 599, [ 61 9a 31] Size Min 0x5da5, Avg 0xb47a, Max 0x16ac8
Count 599, [ 61 9a 39] Size Min 0x51b6, Avg 0xb9f4, Max 0x18f4c
Count 598, [ 61 9a 42] Size Min 0x4472, Avg 0xbfbb, Max 0x159d8
Count 598, [ 61 9a 4a] Size Min 0x61b2, Avg 0xc70d, Max 0x16119
Count 598, [ 61 9a 52] Size Min 0x52a2, Avg 0xc93f, Max 0x1a0ba
Count 598, [ 61 9a 5a] Size Min 0x59d5, Avg 0xc837, Max 0x1622c
Count 598, [ 61 9a 63] Size Min 0x77bf, Avg 0xcc5d, Max 0x1aaef
Count 598, [ 61 9a 6b] Size Min 0x42e1, Avg 0xcc15, Max 0x145ec
Count 598, [ 61 9a 73] Size Min 0x582d, Avg 0xcd04, Max 0x1490e
Count 299, [ 65 88 80] Size Min 0x1a22e, Avg 0x3b18c, Max 0x4efd1
Count 300, [ 65 88 81] Size Min 0x18c81, Avg 0x3abe2, Max 0x4aaee
Count 1, [00 00 00 0a 67 42 00] Fixed Size
Count 1, [00 00 00 04 68 ce 38] Fixed Size
----------------------

Sound statistics:
Sample Size: Min 0x1, Avg 0x1, Max 0x1
Samples Per Chunk: Min 1017, Avg 1017, Max 1017
Fixed Chunk Size: 0x3F9

Now run the following command to start recovering:
recover_mp4.exe corrupted_file result.h264 result.wav --qt --pcmfix 3F9

Then use ffmpeg to mux the final file:
ffmpeg.exe -r 29.918 -i result.h264 -i result.wav -c:v copy -c:a adpcm_ima_wav result.mov
 
I can confirm, a different Micro SD card, can read it as fat32 in a PC or via USB cable and that the other Micro USB card is playing up.
I have no idea why the Navman can see and playback the videos. Must be some sort of defaults in it's operating system that overlooks checks.
I can also confirm, test videos on the new card, play straight away. No weirdness.

So, the dodgy card has likely corrupted the video. It also seems that the MP4 header on the good videos also has the Atoms in weird places. Odd.
 
Back
Top