ISRC vs. Album + Label: SoundExchange's Two Ways to Identify a Recording

Every line of a SoundExchange Report of Use has to say which recording was played. There are exactly two accepted ways to say it, and knowing the difference is what turns a station's play log into a compliant report. This is the rule, verbatim, and how one lookup gives you whichever identifier you need.

The rule, verbatim

SoundExchange states the identifier requirement plainly in its 2025 webcaster guidance:

Read the two sentences together and the rule is: a line is compliant if it carries either (a) the recording's ISRC, or (b) both the album name andthe marketing label. Album-or-label on its own is not enough – the fallback is the pair. Filing specifics and thresholds are SoundExchange's to define; point questions there. SonoVault's job is only to hand you accurate identifiers.

Why ISRC is the cleaner path

An ISRC is a single twelve-character code that names one exact recording. Album + label is looser: two fields, both required, and both prone to spelling drift (“Virgin” vs “Virgin Records” vs “Virgin France S.A.”). When you have the ISRC, use it.

There is one wrinkle worth internalising: one song carries many ISRCs. The radio edit, the extended mix, the remaster and the regional release are each a distinct recording with its own ISRC. You must report the ISRC of the recording that actually aired— which is why the identifier should come from your real catalogue or airplay log, not a guess. (This is the same reason cross-source ISRC “disagreement” is expected rather than a data error.)

How SonoVault gives you both

A SonoVault track record carries the ISRC and the album and label in the same object, so a single lookup covers you whichever path you file under. The representative isrc sits at the top level; releases[].title is the album and releases[].label.name is the marketing label:

{
  "id": "315587001",
  "title": "One More Time",
  "isrc": "GBDUW0000059",          // ← the recording identifier
  "releases": [
    {
      "title": "Discovery",          // ← album name
      "label": { "name": "Virgin" }   // ← marketing label
    }
  ]
  /* artists, genre, duration … */
}

The same shape comes back from /v1/tracks/isrc/:isrc and /v1/tracks/:id. You never make a second call to get the fallback fields — they are already there.

When the ISRC is genuinely missing

Some recordings simply have no ISRC in any source. On those, the representative isrc comes back null— and that is exactly the case the album + label fallback exists for. SonoVault still returns the album and label, so the line stays reportable:

{
  "title": "Digital Love",
  "isrc": null,                 // no ISRC on this record …
  "releases": [
    { "title": "Discovery", "label": { "name": "Virgin" } }
  ]                                     // … but album + label still identify it
}

Getting it at scale

For a whole month's play log you don't look tracks up one at a time. Paste the station's track list into the Bulk Lookup tool, tick the ISRC and Label columns, and download the enriched file as CSV:

# /bulk-lookup export — one line per track, ISRC and Label filled in
input,title,artist,isrc,label
One More Time,One More Time,Daft Punk,GBDUW0000059,Virgin
Digital Love,Digital Love,Daft Punk,,Virgin

Every row now carries an ISRC where one exists and the label where it doesn't — both identifier paths, in one pass. For the full end-to-end walk from an automation export to a SoundExchange-ready file, see Add ISRCs and Labels to a RadioBoss Export, and for the pillar overview of the whole filing, see What a SoundExchange Report of Use Requires. If you are new to how ISRCs relate to the underlying song, the ISRC vs ISWC explainer covers it.