The safe rule is simple: do not assume a visually identical file is metadata-identical. A transcoder may decode the video and audio and write a new container without copying auxiliary streams or vendor-specific metadata.

Keep the original camera files until the project is finished. If you need smaller working media, make proxies or copies and treat them as disposable. Then test the exact conversion tool on one sample and inspect whether the telemetry is still readable before processing the entire folder.

There is also a difference between remuxing and transcoding. A remux may be able to move existing streams into a new container without recompressing them, but that still does not guarantee every private metadata stream or box will be preserved. A transcode is even more likely to rebuild only the media streams the tool understands.

So I would never use “no quality loss” as proof that telemetry survived.

For an editing workflow, I prefer to leave the source untouched and perform trimming inside the project. That preserves the original file as the reference for any telemetry-dependent operation.

If you use proxies in VSDC or another editor, the proxy should only make preview lighter. Keep the relationship to the original source intact, especially if you plan to extract or display GPS later. One representative test clip is enough to validate the workflow before a big project.

I learned this the hard way with a travel archive. I kept the rendered clips because they looked perfect and deleted some originals. Months later I wanted route overlays and there was nothing useful left to read.

Now my folder has a very boring rule: CAMERA_ORIGINALS is read-only until delivery is done. Proxies, transcodes and exports can be regenerated; the original metadata cannot.

That answers it. I will trim logically in the editor, not destructively in the archive folder. If I ever need a converted master for another application, I will test GPS and gyro on one file first and keep the camera original beside it.