Releases and recordings
You will meet two pairs of words in Mercury: release and recording, and album and track. Day to day you work with albums and tracks. This page explains why the other pair exists.
Two layers
| Layer | Words | Who owns it | What it is for |
|---|---|---|---|
| Canonical | Release, recording | The organisation that ingested it | The source data: what a metadata CSV creates, what audio and artwork attach to, what codes and composers belong to |
| Catalogue | Album, track | Each organisation that shows it | What clients browse, search, play, tag and download; what groups and published state apply to |
For your own catalogue there is exactly one album per release and one track per recording, and the admin keeps them in step. When you edit a track, fields such as title, codes, BPM and composers are saved on the recording and fields such as published state and tags are saved on the track. The forms show them together, and the admin calls the release a Parent album, so you rarely notice the split.
Why it matters
The split is what makes subpublishing possible. When an original publisher shares a release, the agent organisation gets its own album and tracks pointing at the same release and recordings. The agent can tag, group and publish its copies, while the publisher keeps control of the source data. That is why, on subpublished content, most fields in your track and album forms are read only.
It also means that:
- deleting a track or album you originally published deletes the recording or release, and therefore every subpublisher’s copy;
- audio and artwork are uploaded once, to the recording or release, and every copy uses them;
- codes written back by an agent under a publishing agreement change the shared recording.