Duplicate Release Detection
Understand how DIMBER catches duplicate releases before they reach DSPs — and what to do if your legitimate release gets flagged
Catch duplicate release issues before they reach DSPs
Understand how DIMBER identifies duplicate content during QC, why a release gets flagged, and what to do if the flag is incorrect. Duplicate detection protects your catalog before delivery to 150+ DSPs by preventing avoidable conflicts, split streams, and metadata problems.
Why duplicate detection matters
Duplicate releases hurt artists first. When the same recording appears more than once, stream counts can split across multiple versions, listeners can land on the wrong release, and royalty earnings can fragment instead of accumulating in one place.
DSPs also have to deal with the fallout. Duplicate content clogs catalogs, creates conflicting metadata, and leads to a worse listening experience when fans see multiple nearly identical versions of the same release.
DIMBER includes duplicate detection as part of its standard QC process. That QC process also checks loudness, platform fit, and metadata accuracy before a release moves forward.
How DIMBER detects duplicates
DIMBER uses multiple signals because duplicate content does not always look the same on the surface. Some duplicates reuse the same identifiers, while others try to appear new by changing metadata or assigning a different ISRC.
ISRC matching
ISRCs are the primary identifier for sound recordings. Every track on your release needs its own unique ISRC, and DIMBER checks whether that ISRC already exists on another release in the system.
If the same ISRC appears elsewhere, DIMBER flags the release as a potential duplicate. In most cases, reusing an ISRC is only expected when you are re-delivering the exact same recording rather than uploading a new one.
Audio fingerprinting
Audio fingerprinting checks the recording itself, not just the metadata around it. DIMBER analyzes the audio content to detect whether the same recording has already been delivered under a different track title, release title, or ISRC.
This catches cases where someone uploads the same audio again but assigns a new identifier to make it look different. It also helps DIMBER detect duplication even when metadata has been changed enough to avoid a simple text match.
Metadata comparison
Metadata comparison looks for close matches across release details. DIMBER compares track titles, artist names, album titles, and track durations against existing releases in the system.
Close matches do not always mean a true duplicate, but they do trigger a manual review. That review helps catch suspiciously similar submissions while still allowing legitimate edge cases to be assessed by a person.
What happens when a duplicate is flagged
A duplicate flag moves your release into a review path instead of sending it directly forward. The goal is to verify the release before it reaches stores and streaming platforms.
A duplicate flag does not automatically mean rejection. DIMBER's QC team reviews each flagged release manually before making a determination.
When DIMBER flags a potential duplicate, the process works like this:
- The release is held in QC with the status In Review
- DIMBER's QC team reviews the flagged content
- If QC confirms a true duplicate, the release is Rejected with an explanation
- If QC determines the flag was a false positive, the release proceeds to Approved
Resolving false positives
A false positive usually happens when your release shares identifiers or audio characteristics with a recording you legitimately control. The fastest way to resolve it is to explain the context clearly and provide documentation that shows why the release is valid.
You may need to provide proof of rights if you own the recording and it was previously delivered through DIMBER or another distributor. If you intentionally reused the same ISRC, such as after a takedown, explain that in your submission notes. If audio fingerprinting flagged a cover version or remix that is legitimately distinct, include documentation that shows you have the rights to distribute it.
Review the rejection notice
Review the rejection notice in your DIMBER dashboard and identify the specific reason the release was flagged. Look closely for references to ISRC reuse, matching audio, or metadata similarity.
Gather documentation
Gather the records that support your case. Useful documentation includes rights agreements, prior delivery confirmations, takedown history, or licensing proof for a cover, remix, or other authorized use.
Contact DIMBER support
Contact DIMBER support through your dashboard and attach the documentation with a short explanation of the situation. State whether the release is a re-delivery, a licensed derivative work, or a separate release that was flagged incorrectly.
QC reviews the evidence
DIMBER QC reviews the evidence and makes a final determination. If the documentation supports your claim, QC clears the release and it moves forward. If not, the rejection stays in place with the original reason.
Legitimate re-delivery
There is one common case where delivering the same content again is valid: you previously took the release down and are now re-delivering it. That might happen because you updated metadata, changed your distribution plan, or want to send the release to a different set of DSPs.
In that case, reuse the same ISRCs for the same recordings. DIMBER treats that ISRC reuse as a re-delivery signal rather than a new duplicate attempt. If you are planning a re-delivery after removal, read Requesting Takedowns first so the sequence is clear.