The bin won’t open, and it’s the bin with the sequence you’re delivering to the network on Friday. Or it opens, but every attempt to delete an old MOB throws “can’t delete MOB because it is still being referenced” and no operation on the bin will complete. Or the workspace on Avid Nexis has gone offline mid-conform, and now Media Composer reports every clip in the current bin as offline even though the shared storage is technically mounted. Or you’re an assistant on a broadcast show and the msmMMOB.mdb database in the MediaFiles folder has grown corrupt over months of media coming in and out, and Avid can no longer find perfectly good MXF files that are sitting right on the drive. If you’re in one of these scenarios and the calendar has a lock date, an air date, or a delivery on it, this page is written for you.

Gillware recovers Avid Media Composer projects, bins, and media databases — the .avp project files, the .avb bin files, the msmMMOB.mdb and msmFMID.pmr media database indexes that live inside every MediaFiles folder, and the MXF and OMF media files themselves. This is one of the spokes under our broader video production data recovery page. For other NLEs, see the sibling pages on Premiere, Final Cut Pro, and DaVinci Resolve.

How Avid stores your work — and why it fails differently from other NLEs

Avid Media Composer’s file structure predates every current NLE by many years, and it shows in the design. A project is a folder on disk containing an .avp file and any number of .avb bin files, one bin per file. Every bin is essentially a small standalone database of the clips, subclips, sequences, and effects it holds. When you open a bin in Media Composer, you’re loading that one file. When you save, you’re writing that one file back to disk. Multiple bins can be open at once, and each one carries its own state independently.

Media is stored separately from projects. Every drive that Avid recognizes gets a folder called Avid MediaFiles/MXF/1 (or 2, 3, etc.) at its root. Inside that folder live the MXF media files — one per clip, one per audio track — plus two critical database files: msmMMOB.mdb, which indexes the media assets on that drive, and msmFMID.pmr, which indexes the physical media file IDs. When Media Composer needs a clip, it consults these databases to find which file on which drive holds the material. If the databases are corrupt, Avid loses track of media that is sitting right there on the drive.

This separation of project data (bins) from media data (MediaFiles) is a strength for the workflow — but it means Avid has two independent failure surfaces. Corrupt bins are a project-side problem. Corrupt media databases are a storage-side problem. And a bin can reference media whose database index has rotted, producing the “media is offline” state even when the media exists.

Why an Avid bin goes corrupt

Bin failures cluster around a few reliable causes:

• Bin file was open when it shouldn’t have been. Avid creates a .lck lockfile alongside a bin when someone opens it. If Media Composer crashes, the lockfile can be left behind, and subsequent attempts to open the bin either refuse or produce an inconsistent state.
• Multi-user bin conflicts on shared storage. Two assistants opening the same bin at the same time on Avid Nexis or third-party editing storage can produce a race condition where both editors write back to the bin file, corrupting it.
• MOB reference corruption. The Master Object (MOB) identifiers that Avid uses to link clips across bins and media can develop cross-references that Avid’s own delete logic can’t resolve. The “can’t delete MOB because it is still being referenced” error is a symptom of exactly this state.
• Assertion failures during export or consolidate. Some sequences produce internal assertion failures during export, DNxHD/DNxHR transcodes, or media consolidation — leaving both the sequence and the bin holding it in a partially-modified state.
• Ungraceful shutdown during save. A Media Composer crash, an OS crash, or a power event while a bin is being written produces a truncated or malformed bin file.
• Drive-level corruption. The bin file is intact but the drive holding it has developed bad sectors under those blocks. Media Composer reads inconsistent data and can’t parse the bin.

Why the MediaFiles database goes bad

The msmMMOB.mdb and msmFMID.pmr media database files inside every MediaFiles/MXF/ folder are indexes that Media Composer maintains as media comes in and out. Over a long series or a multi-year facility, these indexes see millions of transactions — imports, consolidations, mixdowns, exports, deletes, offline moves. Over time, the indexes can develop inconsistencies that Avid’s own database code can no longer reconcile.

The symptom is media that appears offline in bins even though the underlying MXF files are visibly present on the drive. Rebuilding the media database — deleting the two .mdb and .pmr files and letting Media Composer regenerate them from the media on disk — is Avid’s own recommended remedy, and it usually works. But there are cases where it doesn’t work: media files whose internal headers are corrupt, media folders that contain thousands of files where the rebuild takes days and fails partway through, and mixed-drive setups where the rebuild misidentifies which files belong to which media set.

When the rebuild fails, the media database recovery becomes forensic. We can examine the corrupt .mdb and .pmr files, extract the intact records, and reconstruct working indexes that Avid can open. We can also fix corrupt MXF header data on the underlying media files themselves so that Avid’s rebuild process treats them correctly.

Avid Nexis and other shared editorial storage

A meaningful portion of Avid work happens on shared storage — Avid Nexis for facilities on the Avid ecosystem, or third-party editing storage from other vendors. Shared storage failures affect both the bins and the media at once, since typically both live on the same workspace.

The failure modes here are RAID and filesystem failures at scale. A Nexis system can drop a workspace offline if enough drives fail, if the metadata engine loses its state, or if a network fabric event interrupts communication between the head node and the storage nodes. Third-party shared storage sees similar failure classes — controller failure, RAID rebuild failure, filesystem corruption.

Multi-drive editorial storage recovery is covered in depth on our video editing RAID and shared storage recovery page. For Avid-specific shared storage failures where both the storage and the bin data need recovery, both processes happen in the same case: we recover the underlying storage array, then recover the bins and media databases from the recovered filesystem.

What recovery looks like for Avid projects

When an Avid project arrives at the lab, we start by examining the project folder and the individual bin files without loading them into Media Composer. A single corrupt bin is an isolated problem; ten corrupt bins in a project usually indicate storage-level damage that affected the entire folder.

For individual bin recovery, the .avb file is examined directly. Avid’s bin format is well understood, and corruption is often localized — a single bad MOB reference, a truncated tail, a malformed effects record. Localized damage is repaired at the record level, with clean records preserved and broken ones either rebuilt or removed. The repaired bin is then tested against a matching Media Composer build.

For MediaFiles database recovery, the .mdb and .pmr files are examined directly and rebuilt when possible. When the underlying MXF media files have header corruption, we repair the MXF headers so that Avid’s own rebuild process handles them correctly on next open.

For projects on shared editorial storage that has itself failed, the recovery starts at the RAID or filesystem level and works upward through the storage, then through the Avid project structure. The full chain — from failed drives to a working Media Composer session — is handled in the same case.

What not to do with a corrupt Avid project or media database

• Don’t keep opening a bin that fails. Every attempt writes lockfile state and can further modify the bin. If a bin won’t open, quit Media Composer and stop.
• Don’t delete .lck lockfiles from bins that are actively corrupt. The lockfile is a symptom, not the cause. Removing it and reopening the bin can produce a “successful” load that saves a corrupted state back to disk.
• Don’t let Media Composer rebuild media databases without a copy. Copy the MediaFiles/MXF/ folders to a separate drive first. The rebuild process modifies the folder contents and reduces what’s recoverable if the rebuild itself fails.
• Don’t run “Bin Rebuilder” or third-party bin repair tools before contacting us. Some of them work; some of them make the damage permanent. If the project matters, image the drive before running any of them.
• Don’t restart or power-cycle a shared editorial storage system after a suspected failure without capturing state. Restarts can trigger recovery routines that write over the pre-failure state on disk.
• Don’t reformat, rebuild, or reinstall over the drive holding the project. If the project or media database is gone entirely, deleted-file recovery from unallocated space is often the last remaining option.

Working with Gillware on an Avid recovery

Gillware handles Avid Media Composer projects across the versions currently in the field, on both freelance workstations and facility installations. Our engineers work with individual bin corruption, MediaFiles database failures, Avid Nexis workspace outages, and third-party shared editorial storage. For projects where the underlying storage has failed, the full recovery pipeline — RAID reconstruction, filesystem repair, bin recovery, media database rebuild — happens in the same case.

Broadcast and network delivery deadlines drive our turnaround policy on this work. If a lock date, an air date, or a client screening is at risk, tell us at intake and we’ll prioritize the queue where the physics of the recovery allow.

Return to the routing hub: video production data recovery.