Naming & folders · How we test and maintain this guide
Similar names are a lead, not a deletion rule
Duplicate links, duplicate source songs and duplicate files are different problems. The workspace merges exact repeated input links and can skip a song ID already prepared in a run. That does not inspect an existing music folder or identify every re-encoded copy on your computer. Local deduplication is a separate task.
A title can be shared by unrelated takes. A source ID can be shared by several exports of the same work. A file hash compares the complete byte contents, including metadata. Use each comparison for the question it can answer. Start with an inventory and preserve the source records before making a decision about which copies are unnecessary.
A measured case where hashes differ but audio does not
| Operation on our generated MP3 | Complete-file hash | Decoded PCM hash |
|---|---|---|
| Copy with a different filename | Same as source | Same as source |
| Write title, artist, album and track tags | Changed | Same as source |
| Restore a copy of the tagged file | Same as tagged file | Same as source |
The source file was 2,401,219 bytes. The tagged copy was 2,401,323 bytes. A difference of 104 bytes came with different metadata, while our decoder produced the same PCM hash. This is one controlled local experiment, not evidence that every hash mismatch is harmless or that all tagging tools preserve the same content.
Matching complete-file hashes and byte counts provide strong practical evidence of a byte-identical copy. Different hashes need more investigation. They can reflect tags, encoding, artwork, corruption or a genuinely different recording. Listening and source identity remain useful where a byte-level comparison does not settle the question.
Build a comparison before changing the folder
- List each candidate's path, size, source ID if known and role in the project.
- Compare SHA-256 values for suspected exact copies. Keep the exported manifest's values separate from hashes you compute after editing.
- For mismatches, compare format, duration and metadata, then listen where the artistic identity is uncertain.
- Check whether an editor, playlist or other project references a particular path.
- Make a keep/hold decision in the inventory before moving or removing any file.
On Windows PowerShell, a read-only check for one file is Get-FileHash -LiteralPath 'C:\Music\track.mp3' -Algorithm SHA256. Replace the path with your actual file. The command reads the file; it does not change or remove it. Microsoft documents the parameters in Get-FileHash. Compare the whole value, not a few visible characters.
If you use a decoder-based comparison, record the decoder and exact output settings. Different decoding or resampling choices can change the resulting sample bytes. The PCM hashes in our example used the same FFmpeg command for both files. A perceptual-similarity tool answers yet another question and should not be mistaken for an exact-file comparison.
Keep the process reversible
Hold suspected duplicates in a separate review area or retain a backup until the project still opens correctly without the redundant path. Do not mass-delete based only on title, duration or a suffix such as (2). Those shortcuts can remove an alternative take or the only copy with useful tags.
Retain a short decision record linking the kept path to the retired path, comparison used and date. If the files differ only in tags, decide which metadata you need before choosing a keeper. If one file is a lower-quality derivative of a source, preserve the relationship rather than calling the pair identical.
The goal is a collection you can trust and recover, not the smallest possible file count. A source archive, a working edit and a delivery copy may be intentional repetition. Their distinct roles are often worth more than the storage saved by removing one without understanding why it exists.