# ISRC Clustering: Grouping Related Sound Recordings Across Different ISRCs

> Group an original, its remasters, edits, live versions and remixes into one cluster across different ISRCs, for review and usage matching.

- Segment: Music Rights Organization, Record Labels, Industry Trade Organizations
- Platform: Noctil Platform
- Capabilities: MatchIQ, ProcessEngine, DataFort
- Author: Jacob Varghese
- Published: 2026-11-08
- Source: https://www.noctil.com/use-cases/isrc-clustering-grouping-related-sound-recordings

**In short:** One song can exist as many recordings with different ISRCs: the original, remasters, radio edits, live versions, remixes, reissues and compilation tracks. Noctil's ISRC clustering groups these related recordings into one cluster, because they are versions of the same underlying musical work. Intelligent routing decides what belongs together: identical recordings delivered under several ISRCs are combined, and related but distinct versions are kept separate inside the same cluster. Each recording keeps its own performers, rights owners and rights. The cluster is an operational view that gives reviewers and usage matching the full picture of every recording family, not a statement of shared ownership.

---
_See every version of a recording together, whatever its ISRC. For neighbouring rights societies, record labels, distributors, industry trade organizations and other music rights organizations that review recordings and match usage across large sound recording repertoires._

## The Situation

An ISRC identifies one specific sound recording. But a popular song rarely has just one: over the years it gains remasters, radio edits, extended mixes, live recordings, remixes, reissues and compilation appearances, each with its own ISRC, and sometimes the same recording is delivered again under a new one.

All of these recordings usually share the same underlying musical work, and some share the same artist or label. But they can differ in important ways: a live recording may have a completely different line-up of performers and session musicians, and a reissue or remix may belong to a different rights owner. Rights organizations and labels still need to see them as a family when they review repertoire, research claims and match usage, while keeping each recording's own details intact.

## The Problem

When every ISRC is treated as an isolated record, important connections are lost:

- **Related recordings look unrelated.** A remaster or radio edit with a new ISRC appears as a separate, unconnected recording, even though the musical work behind it is the same.
- **Identical recordings under several ISRCs.** The same recording, re-delivered or reissued, can carry more than one ISRC and be counted twice.
- **The wrong rights owner paid.** Several ISRCs for one recording lead to inconsistent ownership data and performer line-ups. A new ISRC can even be used to claim income for a recording someone doesn't own, and multiple ISRCs are most common on the highest-value recordings.
- **Versions that must not be merged.** A live version or remix is related to the original but is a distinct recording with its own performers and sometimes its own rights, so it can't simply be combined.
- **Usage that names a different version.** A usage line may carry the ISRC of a version that isn't in the repertoire. Without the family view, the match fails and the income goes unclaimed.
- **Slow, partial review.** Reviewers checking a match or a claim have to search for each version separately, and may decide without seeing the whole picture.

## The Solution

Noctil's ISRC clustering, built on MatchIQ and ProcessEngine, groups related recordings and decides how each one belongs in the group.

1. **Find related recordings with MatchIQ.** MatchIQ compares recordings across titles and version labels, artists and performers, durations, labels, release details and the linked musical work, plus audio fingerprint IDs and similarity hashes where they are present in the data, and identifies recordings that belong to the same family, whatever their ISRCs.
2. **Intelligent routing.** ProcessEngine routes each recording to the right place:
   - **Identical recordings** delivered under different ISRCs are combined into one recording, with every ISRC kept as an alternate identifier.
   - **Related but distinct versions**, such as remasters, edits, live recordings and remixes, are kept as separate recordings inside the same cluster, each with its own performers, rights owners and rights.
   - **Uncertain cases** are routed to a reviewer.
3. **Clustering rules for each purpose.** Different tasks need different clusters, and the rules are configurable for each one. Performer line-up review uses tight rules that leave out live versions, extended mixes and remixes, because their performers differ. Rights ownership review and usage matching use wider rules, because an artist's catalog often sits with one owner. The same recordings can therefore be grouped differently for different tasks.
4. **A clustered view for review.** Reviewers see the whole recording family in one place, with each version's ISRC, performers, rights owner and linked musical work, when they check a match, a registration or a claim.
5. **Usage matching across the cluster.** When a usage line carries the ISRC or details of any version in the family, the cluster helps find the right candidates and the underlying work quickly. The match is still resolved to the specific recording, so royalties follow that recording's own performers and rights owner.
6. **Consistent line-ups and ownership checks.** A performer added to one recording can be applied to its identical copies under other ISRCs, so line-ups stay complete and consistent. Unusual ownership claims across a cluster, such as a new claimant on one version of a recording, are flagged for review, checking every recording rather than only large payments.
7. **Clusters that stay current.** New recordings, reissues and ISRCs are routed into existing clusters as they arrive, through DataFort intake.

## The Result

- **Every version of a recording visible together**, whatever its ISRC
- **Identical recordings combined**, so the same recording isn't counted twice
- **Distinct versions kept distinct**, with their own performers and rights intact
- **Faster, more complete usage matching**, with the right candidates found even when a line names a different version
- **Lower risk of paying the wrong rights owner**, with unusual ownership claims flagged across every cluster
- **Complete, consistent performer line-ups** across identical recordings
- **Faster, better-informed review** of matches, registrations and claims

## Frequently Asked Questions

**What is ISRC clustering?**

ISRC clustering is grouping sound recordings that have different ISRCs but belong to the same family, such as an original, its remasters, edits and live versions, because they are versions of the same underlying musical work.

**Why cluster recordings that have different ISRCs?**

So reviewers and usage matching can see the whole family at once. When a usage line or claim names any version, the right recording and its underlying work can be found quickly.

**Are clustered recordings merged into one?**

Only identical recordings delivered under different ISRCs are combined. Related but distinct versions, such as remixes and live recordings, stay separate inside the cluster.

**Do recordings in a cluster share the same owners and performers?**

Not necessarily. A live recording may have a completely different line-up of performers and session musicians, and a reissue or remix may belong to a different rights owner. Each recording keeps its own performers, rights owners and rights. Clustering serves review, research and matching operations, and doesn't merge rights.

**Can the same recordings be clustered differently for different tasks?**

Yes. Clustering rules are set per purpose. Performer line-up review uses tight rules that keep live versions and remixes apart, while ownership review and usage matching use wider rules.

**How does Noctil decide what belongs in a cluster?**

MatchIQ compares titles, version labels, artists, performers, durations, labels, release details and linked works, along with audio fingerprint IDs and similarity hashes when the data includes them. ProcessEngine then routes each recording to be combined, kept as a separate version, or sent for review.

**Can one recording have several ISRCs?**

Yes. A recording re-delivered or reissued can receive a new ISRC. Noctil keeps every ISRC as an alternate identifier on the combined recording.

**Who is this for?**

Neighbouring rights societies, record labels, distributors, industry trade organizations building shared recording databases, and other music rights organizations that review recordings and match usage at scale.
