Music Catalog Metadata Problems: The 7 That Cost Real Money, and How to Fix Them

Why does an acquired catalog take four times longer to ingest than planned?

The proposal prices ingestion per thousand recordings. The reality is that price only holds for catalog you created yourself. Acquired catalog is a different job, and it is the scope failure that recurs in nearly every project of this kind.

Here is what actually arrives. Audio in folders named after the album, or after the mastering engineer, or after nothing. A spreadsheet of titles with an inconsistent artist column. International Standard Recording Codes (ISRCs) present for some recordings, absent for others, and duplicated for a few because the original label registered one and a distributor later assumed there was none. Contributor credits for perhaps a third of the catalog, with the same session drummer under four spellings. Contracts as scans in a shared drive, some carving out territories through side agreements from the 1990s that were never digitised.

This is specific to music because a catalog is not a database that changed hands. It is forty years of decisions made by people who have retired, encoded in identifiers issued by different bodies for different purposes, none designed to be reconciled with each other.

The fix is to price acquired catalog separately and to sequence it by revenue. Rank recordings by the income they already generate, ingest the top slice properly, and let the tail follow. Build a completeness view on day one that shows which recordings lack an International Standard Musical Work Code (ISWC), which have no writer splits, which have missing credits and which have no territory rights record. That view converts an unbounded reconciliation problem into a finite worklist somebody can actually work through, and it produces recovered income before the rest of the platform ships.

What goes wrong when you migrate a spreadsheet catalog into a real data model?

Most catalogs live in a spreadsheet where the release is the row. That layout quietly asserts that a recording belongs to one release, which is false, and every migration problem downstream flows from it. Five specific breakages recur.

• Recordings collapsed into releases. The same recording appears on an original album, a deluxe reissue, a compilation and a territory edition. If migration creates four recordings, you have four sets of streaming history and four royalty destinations for one performance.
• Duplicate ISRCs merged too eagerly. Automated matching that merges without human confirmation corrupts royalty attribution, and unlike most data errors this one is very hard to unwind after money has flowed. Every merge needs to be reversible with provenance showing who did it and when.
• Artist name as identity. Two different artists share a name, one artist releases under three, and a featured credit is stored as part of the title string. Name is not an identity key. Party records with Interested Party Information (IPI) numbers where available are.
• Writer splits that do not total. Legacy sheets routinely carry splits summing to 97 or 104 percent, or splits recorded at the release level rather than the work level. Validate totals at import and quarantine failures rather than rounding them.
• Non Latin script and punctuation. Titles with diacritics, different apostrophe characters or transliterated versions produce duplicates that text matching will not catch and platform validation will reject later.

Model party, work, recording and release as four separate entities with explicit relationships before importing anything. Retrofitting that model after ingestion means re running the whole migration.

Why do platform deliveries start failing months after launch?

Delivery works on launch day because the team tested against the partners they had. It degrades afterwards for reasons that are structural rather than accidental.

Digital Data Exchange (DDEX) is a genuine standard and it helps a great deal, but partners implement profiles of it. A field that is optional in the specification is mandatory in one partner's profile. Message versions differ, so you will be generating more than one version of the same standard simultaneously for years. Partners change requirements on their own schedule, and you find out through a rejection rather than a notice. Handling for pre orders, instant grat tracks, explicit flags, artist role coding and non Latin titles all vary.

The failure is usually architectural. If each partner was implemented as its own code path, partner number eight is where maintenance overtakes delivery, and a spec change requires a release cycle instead of a configuration change. Express partner requirements as configuration driving a validation engine that runs before delivery, not after rejection. Then map every partner error code to a plain language task with an owner and a named field on a named release, so nobody has to memorise what a numeric code means.

The harder half is the silent failure. Acknowledgement is not availability. Build live status reconciliation that checks, after delivery, whether the recording is actually present on each platform in each territory with the expected artist, credits and release date, and raises differences as tasks. Apply the same standard to updates and takedowns: proof of effect, not proof of sending.

What happens when territory rights and chain of title are not enforced?

Rights in a real catalog are never uniform. Two albums owned outright, three licensed for a term, one reverted, a compilation with different territory rights per track, and a handful of recordings with sample clearances that limit certain uses. This is normal. What is not normal, and what causes the damage, is that this information almost always sits in scanned contracts rather than in queryable form.

The costs are specific. Somebody guesses whether a recording can go to a given platform in a given territory today, and the guess produces either a takedown notice or rights that sit unexploited. A term expires unnoticed and you keep collecting income you are no longer entitled to, which is worse than losing it. And when you go to sell or finance the catalog, a rights researcher spends weeks reconstructing what the system should have held, at your cost, during a process where every week of delay works in the buyer's favour.

Model rights as time bounded and territory bounded grants attached to recordings and works, with the contract linked as evidence and the term end date raising a review before it lands rather than after. Then enforce at delivery: a release cannot be sent into a territory where the grant has lapsed. That control converts a legal document into an operational guardrail, and it is one of the strongest arguments for building.

Should you build custom or configure what you already own?

A meaningful share of readers should not build this, and we say so regularly. If you are a label releasing a few hundred tracks a year of catalog you created yourself, with no acquisitions and no territory carve outs, FUGA or Revelator will serve you better than anything custom. They provide partner coverage and a maintained supply chain that you cannot economically replicate, and building your own pipeline to reach parity would be an expensive way to stand still. The same answer applies to most artist services companies.

The constraint is structural, not a quality complaint. These are products with an opinion about how a catalog is shaped: how ownership is expressed, how splits work, what a release can be, which identifiers are authoritative. That opinion is a feature when your catalog matches it. When your catalog carries acquisition history with conflicting identifiers, chain of title running through three owners and territory carve outs, you reshape your data to fit the product and the parts that do not fit go into a spreadsheet beside it. That spreadsheet then quietly becomes the real system, which is the outcome you were trying to avoid.

Build when two or more of these hold. You administer acquired catalog with identifier and chain of title problems. You are a distributor or aggregator where the delivery pipeline is the product and partner economics decide your margin. You administer both recordings and works and need one identity graph across both. You operate territory limited grants that need enforcing at delivery time. Or your operations team spends more than about a day a week chasing delivery errors and status.

How do hidden costs get into the quote?

Five lines are consistently underpriced in this category.

• Partner count. Each additional delivery partner profile is weeks, not days. The first three teach you what the abstraction should be, which means partners one to three cost more than partners four to ten, and quotes that price them uniformly are wrong in both directions.
• Legacy catalog reconciliation. The single most underestimated line. Its cost depends entirely on how inconsistent your inherited identifiers and credits are, which nobody knows until a sample is profiled. Insist on profiling a real sample before the number is fixed.
• Sales report ingestion. Formats vary by counterparty, arrive on different schedules, and matching income back to recordings at scale is its own engineering problem rather than a parser.
• Works registration. If you administer publishing as well, that is effectively a second supply chain with its own counterparties and formats. It should be scoped as its own phase, not treated as a small extension of recordings.

What separates a build that works from one that fails here?

Ask a prospective developer to draw the identity graph before you sign anything. Someone who has done this separates party, work, recording and release, knows that a recording appears on many releases, and will ask unprompted how you want to handle a merge that turns out to be wrong six months later. Someone who draws tracks and albums has built a media library and will discover the real shape of the problem at your expense.

Ask how partner differences will be handled. Configuration driving a validation engine is the answer that survives partner number eight. Code per partner is the answer that does not.

Ask what happens to a delivery that reports success and never appears. If live status reconciliation has not been considered, they have built a sender rather than a supply chain, and your silent failures stay as invisible as they are today. Ask how merges are confirmed and reversed, and insist on human confirmation for anything ambiguous with full provenance retained, because royalty attribution is the one dataset where an unrecoverable mistake keeps costing you every quarter.

Finally, settle ownership in writing before kickoff: the repository, the cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit. For a distributor this is not a formality, because the delivery pipeline is the product you sell.