On broadcast media, a clip is not a file. An AVCHD clip is a stream file plus an index file plus a playlist plus a global index, and a P2 clip is separate video, audio, and metadata objects bound together by a unique identifier. Drag a single file to a desktop and you can destroy the relationship that gives it meaning, which is why most broadcast camcorder video recovery failures are self-inflicted in the first ten minutes.
Stop, image the media read-only, and work only from that copy. The rest of this page explains what each format expects and where salvaging is still possible.
What makes professional media different from a consumer card
A consumer camera writes one self-contained file per shot: a JPEG or an MP4 that carries its own index in a header and survives being moved, renamed, or copied to a different folder. A camcorder in AVCHD, XDCAM, P2, or SxS mode does not work that way. It writes a clip, a logical object assembled from several files that live in different directories and reference each other by name, sequence number, or a 32-byte identifier. The recording is complete only when every one of those pieces agrees.
The second difference is how much of the design exists to protect the operator. Broadcast formats are built for a world where a card can be ejected in a hurry, handed to an assistant, and ingested by an editor who is not the shooter, on a different continent, with different software. The index files, material identifiers, and proxy folders all exist so the editing system can reassemble the camera’s intent without human judgment. Break those structures and the editorial system stops trusting the media entirely, reporting the clip as offline or corrupt even when the video payload is intact and playable in a media player. That gap, between what a decoder can see and what an editor will accept, is the central fact of this page. The underlying container mechanics are covered in camera video file formats.
The four formats and the folder rules you must not break
| Format | Typical media | What a clip actually is | The structure that must stay intact |
|---|---|---|---|
| AVCHD | SD/SDHC/SDXC in consumer and prosumer camcorders | /AVCHD/BDMV/STREAM/00012.MTS, an MPEG-2 transport stream carrying H.264 with AC-3 or LPCM | BDMV/CLIPINF/00012.CPI index plus BDMV/PLAYLIST/*.MPL and the top-level INDEX.BDM |
| XDCAM EX | Sony SxS cards | MP4 or MXF essence under /XDROOT/CLIP/ with sidecar metadata in /XDROOT/SUB/ | The XDROOT hierarchy and its MEDIAPRO.XML and GENERAL records |
| P2 (AVC-Intra, DVCPRO HD) | Panasonic P2 cards | Separate MXF objects: one per video track, one per audio track, plus clip metadata | /CONTENTS/ with VIDEO, AUDIO, CLIP, ICON and PROXY subdivisions, linked by UMID |
| XDCAM HD on Professional Disc | Sony optical disc media | MXF essence plus user metadata on a UDF volume | The disc’s UDF file system and the PROAV directory tree |
Why moving one file can invalidate an entire clip
In AVCHD, the .MTS stream and its .CPI index are partners. The .CPI records the byte offset of every access unit in the stream, which is what lets an editor scrub, cut, and relink without decoding the whole file. Copy only the .MTS and it will often play perfectly in a desktop player, because players decode sequentially and never ask for an index. Import it into an editing application and the clip may appear offline, silent, or as a single frame, because the application asked for the index and found nothing. This is the most common “corrupted AVCHD clip” report, and in most cases the file is not corrupted.
P2 goes further. There is no single clip file to copy. A thirty-second AVC-Intra clip arrives as a video MXF, up to four audio MXF objects, at least one metadata object, and a thumbnail, scattered across CONTENTS/VIDEO, CONTENTS/AUDIO, CONTENTS/CLIP, and CONTENTS/ICON. The glue is a Unique Material Identifier (UMID), a 32-byte value written into every one of those objects. Copy the video file alone and you have a playable stream with no audio, no metadata, and no way for the ingest tool to match it to anything. Flatten the objects into a single folder and you have all the data and no structure; the ingest tool reports the media as invalid.
The reverse mistake is equally common. Operators copy the entire BDMV folder to a network share, then rename the top folder to something descriptive. Internal playlists reference clips by index and path position, and some ingest tools key off the volume label or parent folder name. Renaming can make a healthy card unreadable to the editor.
Salvaging AVCHD when the index is missing
Here is the counterintuitive part for anyone who has only worked with consumer media: an AVCHD .MTS file is a standard MPEG-2 transport stream, and a transport stream is self-synchronizing. It is built from 188-byte packets that each begin with a sync byte, and it carries its own program association and program map tables. A demultiplexer can therefore lock onto an .MTS file with no external index at all, recover the video and audio elementary streams, and remux them into a plain MP4 or MOV.
The practical consequence is significant. If the CLIPINF index is gone but the STREAM payload survives, the footage is not lost, it is merely unindexed. A remux, which is a container rewrite with no re-encoding, typically takes seconds per clip and produces a file that plays anywhere and imports normally. Camera metadata such as date, timecode, and recording mode has to be read from the transport stream’s own tables rather than from the missing .CPI, so it returns in reduced but generally usable form.
The same reasoning applies to the .MOD and .MOI pairing on some JVC and Canon models: the .MOI is the index, and its absence does not prevent the .MOD from being decoded. When an index cannot be regenerated, remuxing the raw stream is the first thing to try, and it is cheap: no re-encoding, no quality loss, no generation loss. Where the payload itself has gaps rather than a missing index, repair corrupted video files covers what can be rebuilt from surviving frames.
P2, SxS and XDCAM: where the media binds to the device
Professional media is not a generic removable volume, and that changes both the failure modes and the options.
P2 cards carry a physical write-protect switch that the camera reads. A card left in the protected position will appear to accept a recording and then fail to commit it, producing an empty clip. P2 media also uses a custom on-card layout rather than plain exFAT, so a generic file system utility can destroy a healthy card by “fixing” a structure it does not understand. Never let an operating system repair a P2 card.
SxS and XDCAM EX cards use industry-standard file systems, so the risk shifts to host behavior: an operating system mounting the card, finding an unclean volume, and offering to repair it. The camcorder is often the better tool. Sony’s media salvage function and Panasonic’s clip repair routine operate on the card’s own on-device structures and rebuild the manufacturer’s index format exactly, which no third-party tool can do. Running the camera’s own routine first is standard practice and occasionally restores clips no desktop tool would find.
XDCAM HD on Professional Disc is a different problem entirely. The medium is optical, its file system is UDF, and the drive mechanism is a precision component no longer manufactured in quantity. A scratched or dirty disc, or a drive that cannot achieve focus, is a hardware failure rather than a data failure, and belongs to a laboratory with the matching drive. If the disc mounts at all, copy the PROAV tree with a tool that preserves the directory structure exactly.
Across all four formats, the discipline that prevents most of this is documented in DIT data management: two verified copies before a card is released, checksums rather than file counts, and a rule that no card is formatted on anything other than the camera it came out of. For wider production-side failures, see cinema camera footage recovery and the large-media variant in cinema camera storage recovery.
What to do before you call a recovery lab
Order of operations matters more than tools. First, stop writing to the media and take it out of the camera. Second, image it at the sector level to a file on a separate drive, using a tool that can read a failing device without retrying endlessly; every later experiment runs against the image, never the original. Third, try the camera’s own salvage routine if the manufacturer provides one and the card still mounts. Fourth, attempt structural recovery on the image. Only after those steps does a physical problem justify a laboratory.
If the media is not detected at all in the host it came from, or mounts and then disappears repeatedly, that is controller behavior and no desktop tool will improve it. The dividing line between structural and physical work, and what a lab actually charges for, is set out in data recovery lab worth it. For the standard procedural path, continue with camcorder video recovery and the professional-card variant CFexpress card recovery.
If the media is still detected by a computer and the loss is structural rather than physical, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive.
Frequently Asked Questions
Can I recover an MTS file if the AVCHD folder structure is gone?
Yes, usually. An MTS file is an MPEG-2 transport stream carrying its own synchronization and stream tables, so it can be demuxed and remuxed into a standard MP4 or MOV with no external index. You lose index-based metadata such as precise timecode and access-unit markers, but the video and audio payload returns without re-encoding.
Why does my camcorder clip play in VLC but show as offline in my editor?
That is the classic missing-index symptom. Media players decode sequentially and never request an index, while editing applications need the access-unit index to scrub, cut, and conform audio. In AVCHD terms, the .MTS survived and the .CPI did not. Remuxing the stream into a self-contained container rebuilds enough indexing for most editors to accept it.
Does formatting a P2 or SxS card in a computer damage it?
It can. P2 media uses an on-card layout that generic file system utilities do not understand, and letting an operating system repair or reformat it may destroy structures the camera needs. Always format professional media in the device it will be used with, and never allow an operating system to run a repair on a card holding material you have not copied and verified.