[Laurent Gross]

copy /b 000001.mts+000002.mts joined.mts

Eric, THIS is probably the best answer, although it may need an explanation.

It anyway proves the cameras works, as concatenating the individual files makes the issue disappear. This is the proof all the information is actually recorded and available : the audio, video frames, every single bit is there.

The error is in the process, and I just understood with this post the real use of the Sony Content Management Utility : it brings the interface for concatenating the single MTS files.

So, why do we need to concatenate and why does this fail when dragging every block continuously on the editor timeline ?
I guess the reason is linked to the AVCHD codec itself where, as far as I understand, each video frame is dependant from the previous ones (4 ?). Not sure, I am not a video codec specialist, but I know this is the case for mp3 as well. That said, it is not possible to determine the first audio/video frames until a minimum frame account has been decoded.
As a consequence, if all blocks are concatenated, there is not issue as all frames have their previous frames embedded in the global file (except for the beginning of file which is never an issue).
And when dragging MTS files independantly in any editor, they are considered as independant blocks. Hence unable of determining the previous frames of each block, although WE (film editors) know these are the previous ones. But software does not assumes this.

The VERY good news is that this also works while rebuilding full footage from dual SD slots (e.g. a full 3 hours show recorded with 2 x 16Gb SD with NX5). Concatenating SD1 last file with SD2 first file does work ! No drop at all !

At the end,
copy /b 000001.mts+000002.mts+….+….MTS complete.mts
does work.

All this will save time (and money) when editing multicam shows 🙂

Just created a cow account for being able to add my 2 cents. But I think this is worth the case.