Broadcast Media Asset Management: Why Your Archive Loses the Metadata That Matters

Why archives lose their value slowly and all at once

A broadcaster's archive is an asset on paper and a liability in practice. It costs money to store every year and it earns nothing unless somebody can find the right item, confirm they are allowed to use it, and deliver it in the format the buyer wants. The gap between holding footage and being able to exploit it is entirely made of metadata, and metadata degrades in ways that storage does not.

The way it degrades is undramatic. A migration in 2014 moved assets from an in house database to a MAM and dropped the fields nobody could map. A producer made a version for a compilation and named it with an underscore and their initials. The rights information for a series was held by an acquisitions manager who left. Twenty years later the material is technically present and commercially unusable, because proving you can sell it costs more than the sale is worth.

The daily version of this is smaller and more annoying. An editor needs three shots of a specific location from an old series. They ask on a group chat. Somebody remembers roughly which programme. Someone else restores a file from deep archive at a cost nobody tracks. The clip turns out to be the wrong version, without the textless elements. That whole sequence took two days and it happens every week.

Problem 1: the house schema is yours and every vendor treats it as professional services

Dalet, Avid MediaCentral, Vizrt Viz One and Tedial are serious systems with genuine production and newsroom integration, and they all support custom metadata. What none of them can do is know your schema, because your schema encodes how your organisation thinks: your genre taxonomy, your production numbering, your commissioning references, your territory codes, your compliance categories, the fields your sales team needs that your production team has never heard of.

So schema work becomes a professional services engagement, and it becomes one again at every upgrade and every partner onboarding. The result across the industry is a MAM that holds the fields somebody had budget to configure, plus a set of spreadsheets holding the fields they did not.

A custom layer owns the schema as your data, mapped outward to standards such as EBUCore or PBCore when you need to exchange with a partner, rather than letting a vendor's model define what you are allowed to record. In practice that means the MAM keeps doing storage, proxy generation, search indexing and editorial integration, which it does well, while the authoritative descriptive, rights and versioning record lives in a layer you control and can change on a Tuesday.

Problem 2: versions multiply and nobody models them properly

One programme is not one asset. There is the master. There is a textless version. There is a compliance edit for a pre watershed slot. There are audio configurations: stereo, 5.1, a described audio track, a clean international mix. There are subtitle and caption files in several languages, each of which may exist in more than one revision. There is a version cut for a partner's runtime, one for an airline, one with product references removed for a territory that prohibits them. There is a promo cut from all of it.

Most systems represent this as a folder of related files with names that encode the relationship. That is not a model, it is a convention, and conventions decay the moment a freelancer joins for a busy fortnight. The specific harm shows up at delivery: someone sends a partner the version with burned in text because the file naming did not distinguish it, and the delivery is rejected, which costs a redelivery fee and a slot.

A custom build makes version a first class relationship: this asset is the compliance edit of that master, derived on this date, with these audio and subtitle configurations, valid for these territories and platforms. Then delivery selection is a query rather than a judgement call, and an editor cutting a promo can be shown only the versions they are permitted to use. Getting this model right early is the single highest leverage decision in a MAM project, and getting it wrong is the reason second attempts happen.

Problem 3: rights are held somewhere else and never reach the person who needs them

The person most likely to breach a licence is not a lawyer, it is an editor at four in the afternoon cutting a trail. They do not know that the archive interview they just used was cleared for the original transmission only, or that the music bed carries a limited licence, or that the contributor withdrew consent last year. They have no way to know, because rights information lives in a rights management system or a contracts folder, and the MAM shows them a searchable clip.

This is not a failure of the MAM vendors. Rights modelling is genuinely hard and organisation specific, and it involves contract data that the media systems were never given. But the consequence sits with the broadcaster: usage outside a licence, a takedown, a payment, and a relationship with a rights holder that gets more expensive next time.

A custom layer attaches rights to the asset and its versions and enforces them at the point of use. Search results carry usage status. Adding a restricted clip to a project raises the restriction and who to ask rather than silently permitting it. Contributor consent and music cue information sit alongside the technical metadata. Where restrictions are unknown the system says unknown rather than implying clearance, a small design decision with large consequences. Broadcasters consistently tell us this is the capability they most wish they had bought.

Problem 4: partner delivery specifications are a permanent tax

Every partner wants something different. A broadcaster wants a specific wrapper and shim with its own metadata sidecar. A streaming platform wants a package built to its own specification with particular audio mapping and subtitle formats. Each partner rejects deliveries for reasons that are precise, documented and easy to get slightly wrong, and each rejection costs a redelivery and a delay.

Media operations teams handle this with a mixture of transcoding tools, checklists and one person who knows what each partner is fussy about. It works and it does not scale, and it fails during holiday cover.

A build turns each partner specification into a versioned profile: required version type, technical parameters, metadata mapping, naming convention, packaging, checksum manifest and delivery route. Packaging then runs automatically with pre delivery validation against the profile, so a rejection becomes an exception caught before it leaves rather than an email from the partner three days later. When a partner updates their specification, you update one profile instead of retraining a team.

Problem 5: migration is where these projects actually succeed or fail

Every organisation in this position has a legacy system, often more than one, holding fifteen or twenty years of records. Migration is not a data transfer, it is an archaeology project. Identifiers were reused. Free text fields contain information that belongs in structured fields. The same programme exists three times because three departments catalogued it. Provenance, meaning who recorded what and when, is itself valuable and is the first thing a naive migration discards.

The honest advice is to plan migration as its own workstream with its own budget, to migrate in waves by collection rather than all at once, and to keep the legacy system readable for a defined period. Machine assistance is genuinely useful here, mapping free text into structured fields and proposing duplicate merges, but every proposal needs a human decision and an audit record of who made it. A migration that cannot explain where a field came from has created a new archive with the same disease.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape. A focused first release covering your house schema, unified search across storage tiers, version modelling and a usable interface for media operations runs $100,000 to $250,000 and ships in 16 to 24 weeks. A full platform adding rights aware access, automated partner delivery with profile validation, archive migration and machine generated metadata such as transcripts and shot detection runs $300,000 to $800,000 phased over 12 to 24 months.

What drives price up specifically here: the number of storage tiers and their behaviour, because a request that triggers a restore from deep archive or a tape library needs queuing, cost visibility and expectation management that instant storage does not. The number of partner delivery profiles. Migration volume and the state of the legacy data, the single largest variable in the whole project. And machine generated metadata at scale, since transcribing a large archive has a compute cost that should be modelled per hour of content before anyone commits.

Build versus buy, and when Dalet or Tedial is the right answer

Buy if you are a production company or a single channel broadcaster with a few hundred terabytes, conventional delivery requirements and a manageable version count. Dalet, Viz One, Avid MediaCentral and Tedial will serve you and their configuration will stretch far enough. Building a MAM from scratch to obtain what you can configure is a mistake, and the storage, proxy and indexing plumbing alone is more work than it looks.

Build a layer when two or more of these are true. Your house schema exceeds what your MAM will model and the overflow lives in spreadsheets. Version relationships are encoded in file names and you have had a delivery rejected because of it. Rights information does not reach the people making usage decisions. You deliver to more than about five partners with distinct specifications. Or you are migrating from a legacy system and need the provenance preserved rather than flattened.

Our position, stated plainly: do not replace the MAM, replace the assumption that the MAM is the system of record for meaning. Storage, transcoding, proxy workflow and editorial integration should stay with a vendor who does it every day. Your schema, your versions, your rights and your delivery profiles describe how your organisation makes money, and those belong in something you can change without raising a purchase order.

How to choose a developer for broadcast media asset management

Ask them to model versions on a whiteboard before you sign anything. A developer who has done this will draw master, derived version, audio configuration, subtitle asset and territory validity as distinct relationships, and will ask how you handle a compliance edit that is later re edited. A developer who draws assets with tags has built a document management system and will discover broadcast at your expense.

Ask how they would handle a request for material with unknown rights status. The correct answer is that the system reports unknown and routes to a named owner, never that it defaults to permitted. That single design choice separates people who understand the risk from people who do not.

Ask what they have actually integrated. Object storage lifecycle policies, a tape library, a transcoding farm, a quality control platform and an editorial system are five different problems, and restore behaviour from deep archive in particular breaks naive designs. Ask for the specific system and the specific workflow.

Ask who owns the code and get it in writing before kickoff, along with a documented export path for the metadata itself. You are building the record for material that will outlive several generations of software. At Digital Heroes the client owns the code from the first commit, and for an archive project we would insist on a tested export before go live because that is the difference between an asset and a future migration problem.