No-Intro and Redump names look ugly on purpose. Renaming them to something readable is how people lose the one thing those names were for.
A folder of game dumps has two jobs that pull against each other. It has to prove the dumps are correct, and it has to be readable in a frontend. Most people try to make the filename do both, and the filename can only do one.
This is about discs and cartridges you dumped yourself, and about the naming conventions the preservation projects publish for them.
Look at a canonical name and the parentheses read like clutter:
Super Mario World (USA).sfc
Castlevania - Symphony of the Night (USA) (Rev 1).binThey are not clutter. No-Intro catalogues cartridge-based systems and Redump catalogues disc-based ones, and both publish DAT files. A DAT is a catalogue where every known good dump is listed with its size and its CRC32, MD5 and SHA-1 hashes, paired with exactly one canonical name.
The name is how a verification tool tells you what it found. Rename the file and the checksums still match, but every report you ever run comes back in names that mean nothing to the catalogue. You have quietly turned a verified collection into a pile of files that happen to be correct and can no longer prove it.
The frontend, not the file. EmulationStation keeps display names in gamelist.xml. LaunchBox and Playnite keep them in their own databases. RetroArch playlists are .lpl files that store a label separately from the path.
So the answer is boring. Leave the file named the way the DAT names it, and let the frontend show Super Mario World. You get verification and readability at the same time, and each one has exactly one source of truth.
If you only take one thing from this page: the pretty name belongs in the scraper database, not on disk. Every problem below comes from someone trying to make the filename be both.
The common tags are region and status:
(USA) (Europe) (Japan) (World)
(Rev 1) (Beta) (Proto) (Unl)Two files that differ only by (Rev 1) are genuinely different dumps. Revisions fix bugs, change behaviour, and sometimes break save compatibility with the earlier revision, which is a miserable thing to discover forty hours in.
A rename template that drops the parentheses turns those two files into the same destination name. That is not a cosmetic problem. A batch rename that produces two identical destinations will destroy one of the two files unless the tool checks for the collision before it moves anything. That failure is the same one that eats files during any batch rename, and it is the single most likely way to lose a dump you cannot easily make again.
Point almost any scraper at an old cartridge and it will eventually hand you a modern game. Look up Prince of Persia against a general games database and the 2008 reboot comes back before the 1989 original. The title is an exact match, so a matcher working on title similarity alone takes it and moves on.
The fix is an era gate. Every console has a window during which games were released for it. A Super Nintendo cartridge cannot be a 2008 release. If a candidate's release year falls outside the platform's window, reject it however well the title scores.
That one rule removes most wrong matches on retro platforms, and it costs nothing, because you already know which system the folder is for.
The second problem is that game titles are short. Similarity scoring on a two or three word title is noisy, because a single token changes the result a lot. Aero against Aero the Acro-Bat scores far better than it deserves to.
So treat a high score on a short title with suspicion, and require the platform and the era to agree before you accept it. Similarity is a tiebreaker, not a decision.
Numerals are the other trap. Final Fantasy IV and Final Fantasy 4 are the same game, and Street Fighter II and Street Fighter 2 are the same game, but a plain string comparison says otherwise. Normalise roman numerals to arabic before comparing, or you will both miss correct matches and, worse, land on the wrong installment in a long series.
Most collections live in .zip or .7z files, and that means every game has two names: the archive, and the ROM inside it.
DAT verification cares about the file inside, because that is what was hashed. Some emulators and scrapers read the inner name, others read the archive name, and nothing warns you when the two disagree.
Renaming the archive does not change the name inside it. If you are going to rename at all, decide which of the two is authoritative and make them agree, or at minimum find out which one the tool you actually use is reading.
Redump names disc images like this, and RetroArch expects a playlist alongside them:
Game (USA) (Disc 1).cue
Game (USA) (Disc 2).cue
Game (USA).m3uThe .m3u refers to its discs by filename. Rename the discs without rewriting the playlist and the game boots perfectly, runs for an hour, and then cannot find disc 2.
A .cue file has the same problem one level down, because it refers to its .bin by name. Rename a .bin and leave the .cue alone and you have a disc image that no longer mounts at all.
Any rename that touches a multi-disc set has to rewrite the companion files in the same operation. If a tool moves the images and leaves the text files pointing at names that no longer exist, it has not finished the job.
None of this is exciting, which is rather the point. A verified set that is boring to look at is worth more than a tidy one you can no longer check, because the checking is the part you cannot reconstruct later.
Related: why batch renaming eats files, and the two-phase fix and what breaks when you rename over SMB and NAS shares.
I write media tooling. Media Renamer Pro is my Mac, iPad and iPhone app that does the renaming described here, with a full preview before anything moves and undo for the last saved rename session.
None of the above requires it. The naming rules are the naming rules whatever you use.
Related: batch renaming safely · renaming photos by date taken