How the ChartFM catalogue avoids the same song twice
Tens of thousands of tracks, imported from different sources, and one design decision that looks wrong
The ChartFM catalogue holds tens of thousands of songs, and they were not entered by hand. They arrive by import: somebody publishes a chart, searches for a track, syncs a playlist.
That creates a known problem. The same song arrives several times under different names, and if nobody intervenes the catalogue splits into duplicates that divide the points between themselves.
Why the same song arrives under different names
Some examples of what shows up in practice:
- Technical suffixes in brackets, like remaster, live version, radio edit.
- The featured artist inside the title instead of in the artist field.
- Accents, punctuation and capitalisation varying between sources.
- The same track across different editions of the same record.
Each of those variations, on its own, is harmless. Together they turn one song into five rows in the database, and none of them climbs the ranking because the points were split.
First defence: a normalised key
Every song, artist and album stores a second version of its name, used only for comparison. In it the text is reduced to lowercase, without accents, punctuation, featured artists or technical suffixes.
The important part is that this key never appears on the site. The title you read stays the original, with its accents, capitals and brackets. The key exists purely so the system can ask whether two rows are the same thing.
It is the difference between normalising to display and normalising to compare. Systems that confuse the two end up showing mangled titles.
Second defence: memory of what was merged
Normalising solves the problem at the door, but it does not solve history. If an administrator merges two duplicate rows today, what stops the importer from recreating the duplicate next week?
The answer is that every merge records the identifier of the row that was absorbed. When an import runs into that old identifier again, coming from an old playlist or a cache, it resolves to the row that survived.
Without that, cleaning the catalogue would be Sisyphean: each cleanup would last until the next week of imports.
The decision that looks wrong
Here is the interesting part. When the system finds a track equivalent to one that already exists, it reuses the existing one **silently**, with no warning and without blocking anything.
The obvious alternative would be to alert the person: we found something similar, confirm whether it is the same song. It sounds more correct and it is worse.
The reason is that the cost of the two errors is not symmetrical. A duplicate in the catalogue is a nuisance an administrator fixes later. Interrupting somebody mid publication of their chart with a technical question about remasters is a chart that never gets published.
So the policy is clear: when in doubt, reuse and move on. Duplicates are a maintenance problem, friction at publication is a product problem.
What still slips through
No normalisation catches everything, and it is worth being honest about that.
Is a re-recording an artist released years later the same song or a different one? It depends what you want to measure. Does an acoustic version count with the original? A cover by another artist clearly does not, but what about a cover using the same title when the system only sees text?
Those cases have no correct automatic answer. They go to manual review, which is what the merge centre in the admin panel exists for.
Frequently asked questions
- I found the same song twice on the site. What do I do?
- Report it through contact. Merging is an administrator operation, because it involves choosing which row survives and transferring the points history.
- Does merging two songs erase the points of one of them?
- No. The history is transferred to the surviving row, otherwise merging would erase positions from old charts.
- Should a remaster count separately?
- On ChartFM, no. Remasters and radio edits are treated as the same song, because separating them would split one track's points across versions nobody perceives as different.
