ISRC Lookup: A Practical Guide for Real Libraries

Most pages that rank for isrc lookup are built for one job: paste a Spotify link, get one code back. That works fine if you need a single ISRC for a royalty claim. It falls apart the moment your library has 500 files, three folders of unreleased masters, and a distributor CSV that only half matches your file names. This guide is for that second situation: real libraries, real backlogs, and the actual workflow for finding, verifying, and using ISRCs at scale.

What an ISRC lookup actually needs to answer

An ISRC, International Standard Recording Code, is a unique identifier assigned to one specific sound recording, not the composition behind it. It is a unique, 12-character identifier for a specific sound recording or music video, functioning like the passport number for one particular audio master, not for the song itself. The code follows a fixed structure: a country code for the registrant's territory, a registrant code identifying the label, producer, or rights owner issuing the code, a two-digit year the ISRC was assigned, and a five-digit designation code that uniquely identifies the recording within that registrant and year.

For a single track, a lookup tool answering "what's the ISRC of this song" is enough. For a library, the real question is different: which of my 2,000 files already have a code, which ones are missing one, and which files that share a title actually point to different recordings. A clean separation of versions matters here, since the album version, radio edit, remix, and live recording of the same title are each distinct recordings with their own code. A one-at-a-time finder can't answer any of that across a folder of files.

Where ISRCs for tracks you already own actually live

Before reaching for a third-party finder, check the sources that are actually authoritative for your own catalog:

• Your distributor dashboard. Digital distributors, including services like CD Baby, DistroKid, or TuneCore, automatically generate ISRCs when you upload a track, and most let you export the full list as a CSV.
• Your delivery or DDEX files. If a label or aggregator delivered the release, the ISRC is embedded in the delivery metadata, not just visible on a dashboard.
• The file's own ID3 tags. Properly tagged files carry the ISRC in a dedicated metadata frame, so a file that was tagged correctly at the source doesn't need a lookup at all.
• Streaming catalog APIs. Both the Spotify Web API and Apple Music API return ISRC codes in track metadata, which is how most of the single-track finder tools work under the hood.
• MusicBrainz. For older, independent, or classical catalog that never made it into a mainstream streaming index, a fallback to MusicBrainz on a Spotify miss gives better coverage for classical, indie, and older catalog.

One caution worth building into any bulk lookup process: cross-source disagreement about which ISRC belongs to a track is normal, not a data bug, because deduplication collapses variants of a recording onto one canonical track while all of the codes stay attached to it. If two sources return different codes for what looks like the same file, don't assume one is wrong. Check the version first.

An ISRC identifies a track. It doesn't describe one

This is the part most lookup guides skip, because they're written for someone chasing a single code, not for someone managing a catalog. Once you've matched a file to its ISRC, you know exactly which recording it is. You still don't know its tempo, its key, what mood it fits, or which sync brief it belongs in. That's a separate metadata problem, and it's the one most libraries actually get stuck on, because ISRCs are usually assigned automatically at distribution while descriptive tags are not.

If you're preparing a catalog for licensing or delivery, both layers matter together: the identifier that proves which recording it is, and the descriptive tags that let a buyer or a search filter find it. Tag your catalog for sync licensing walks through what that second layer needs to contain.

Building one catalog record: identifier plus tags

The practical fix is to stop treating ISRC lookup and tagging as two separate chores done at different times in different tools. Run both against the same file list and merge the results into one row per track.

This is where TrackTag Studio fits into the workflow. Drop a batch of audio files into TrackTag Studio and it returns up to 35 fields per track: BPM, key, genre and subgenre, mood, emotion, theme, occasion, instrumentation, vocals, song structure, and a full written description, all from the same audio, at Core or Ultra depth depending on how much detail you need. Export that batch as CSV or Excel alongside your ISRC list, keyed on file name, and you have one spreadsheet that answers both questions: which recording is this, and what does it sound like.

BPM and key in that export are measured directly from the audio signal with Precision Mode, not estimated, which matters if the ISRC-holding version and the file in your folder turn out to be different edits with different tempos. See how AI BPM and key detection actually works for the detail on why measured beats guessed here.

Doing this across a real backlog, not one file at a time

A library audit only works if you can see the gap between tagged and untagged files without opening each one. TrackTag's My Library feature connects a local folder and indexes it locally, file names and sizes are read on your own machine and nothing uploads until you explicitly analyze a track, showing every file as Tagged or Untagged with an "Analyze untagged" action to clear the backlog. Pair that view with your ISRC CSV and you can prioritize: tag the files that already have a confirmed ISRC first, since those are the ones actually cleared for licensing or distribution.

For catalogs too large to work through by hand in a browser, the desktop app keeps folders connected permanently without repeated permission prompts, which matters since browser folder access only works in Chrome, Edge and Brave and not in Safari or Firefox. Labels and marketplaces running this at real scale typically wire it through the public API instead, posting a track and getting the same JSON analysis back, or through the Zapier integration to drop finished tags straight into the Google Sheet or Airtable base that already holds ISRC and rights data. An MCP server also lets AI assistants like Claude Desktop or Cursor analyze and search local files by name from inside a conversation, useful for quick spot checks on a folder without opening a separate app.

For a full breakdown of that batch process, see how to batch tag music files. If you're comparing tagging engines on price before committing to one for a large backlog, AI music tagging pricing compared lines up the options, and if your workflow already touches catalog integration platforms like AIMS, the honest tradeoffs are covered in TrackTag vs AIMS. AIMS does real work connecting catalogs to DSPs and reporting systems; where TrackTag differs is self-serve pricing and the depth of descriptive tagging, themes, occasions, structure, and full descriptions, that a catalog integration tool isn't built to generate.

Before you submit anything

A library that's about to go out the door, whether to a distributor, a sync library, or a licensing platform, needs both layers checked at once: every file matched to a verified ISRC, and every file carrying tags a human or a filter can actually search by. Preparing a catalog for library submission covers the full checklist, but the short version is this: don't submit a file with a code and no tags, and don't submit one with tags and no code. Run the lookup, run the analysis, merge them into one record, and only then is the track actually ready.