Repair a corrupted BlackVue dashcam video

BlackVue names every segment YYYYMMDD_HHMMSS_XY.mp4, and that two-letter suffix is worth decoding before anything else, because it tells you which recording mode wrote the file and which physical camera it came from. The first letter is the mode, the second is the channel:

• N = Normal (continuous driving), E = Event (a G-sensor jolt or a manual button press), P = Parking (motion or impact while parked), M = Manual.
• F = Front camera, R = Rear camera (3-channel models like the DR970X-3CH add an interior channel).

So 20260714_083012_NF.mp4 is a normal front-camera clip; ..._PR.mp4 is the rear camera in parking mode; ..._EF.mp4 is a front-camera event. Two practical consequences: the front and rear are separate files, so a two-channel incident is two clips to check and repair independently; and the _P segments are the ones most likely to be broken, because parking mode is exactly when power gets cut (see below). The files themselves live in /BlackVue/Record/ on the microSD card.

A dashcam is the harshest environment a video file ever lives in. Two things about how BlackVue records make the last clip fragile:

Parking mode cuts power on purpose. A hardwired BlackVue (via a Power Magic kit or a battery pack) keeps recording after the ignition is off, but a voltage cutoff — commonly set around 12.0–12.3 V on a car so it doesn't flatten the starter battery — pulls the plug the moment the battery dips. An MP4 writes its index (the moov atom that maps every frame) only when a clip is finalized. Trip the cutoff a second before that, or switch off the ignition mid-segment, and you get a file full of real footage with no map to it. That's why the interrupted _PF/_PR and last _NF clips are the usual casualties, and it's the repairable case.

The microSD card is worked to death. A DR900X/DR970X writes 4K H.265 at a high bitrate, continuously, looping over the card and running hot behind the windshield. Consumer cards wear out fast under that load, and a card with failing sectors returns garbage for parts of a file. This is the harder case: where the card physically lost the bytes, no software can invent them back — recover the card first, then repair the file.

When the moov index is missing, it can be reconstructed by scanning the surviving video data and rebuilding the sample tables the camera would have written. For that, a healthy clip from the same BlackVue is gold — but "same" is specific: match the channel and mode too, because a front 4K stream and a rear 1080p stream carry different codec configuration and resolution. Repairing a broken _NF? Use another _NF from the same camera as the reference; for a rear clip use a good _NR/_PR. Matching the model, resolution and framerate settings makes the rebuild faithful rather than a guess. You'll be asked for a reference only when the file actually needs it.

Because BlackVue splits recording into short per-minute segments, you almost always have a neighbouring healthy clip of the right type on the same card. Grab one and keep it handy — and remember to repair the front and rear files separately, since each has its own container.

Dashcam video is often evidence: an accident, an insurance claim, a dispute. It also contains other people's number plates, faces, and — through the embedded GPS track — your own location history. Upload-based repair sites take a full copy of that onto servers you can't inspect, governed by terms you didn't write — a bad fit for material that may end up in a claim or a courtroom.

Here the repair runs entirely in your browser: the file is read from your disk, rebuilt in the tab, and saved back. Nothing is transmitted, and you can prove it — open your browser's Network tab and watch that 0 bytes of the clip leave your machine. That's not a policy promise; it's the mechanism.