[Feature Request] allow multiple discs names to be named as cdX where X is a number about ralibretro HOT 8 CLOSED

I'm not a fan of breaking standards and creating problems just to work around someone else's poor design.

from ralibretro.

The achievement identification code largely relies on the file extension to determine which hashing algorithm to apply. If the extension isn't recognized the entire file (up to the first 64MB) will be hashed.

from ralibretro.

This is the recommended approach for storing multiple disc by retropie fellas as per https://retropie.org.uk/docs/Playstation-1/
I think recalbox also uses the same "hack" to circumvent the issue

What if there was a name convention like "game name.chd.cd1, game name.chd.cd2 and so forth? This way you could tell if the game is a chd or a bin looking for the prefix...

Another option could be to rely on magic numbers/file header to identify the CHD instead of trusting the file extension. There are a limited number of file formats supported anyway for each emulator so it shouldn't be overkilling....
Can't you just simply acknowledge that whatever is listed on the m3u is a "disk file", disregarding on the file extension and then apply the magic numbers approach just in case you have to decompress a chd to calculate the checksum?

from ralibretro.

m3u files aren't just for CD-ROM/DVDs. PC-88 is known to use it for multiple floppy disk games. We wouldn't want to try to use CD-ROM hashing algorithms on floppy disks.

Using a multi-part extension isn't a great solution as the extension is still "cd1", and the second period is assumed to be part of the game title. We'd still need a case to match "cd1" to check for the secondary extension.

As long as the extensions are standardized (i.e. "cd#"), I guess it could be reasonable to support them using the same logic as the "chd" extension.

from ralibretro.

There's still the potential problem of deciding if the "cd#" file is a "cue", "chd", "iso", "gdi", or "bin" file, so maybe the nested extension is desirable.

from ralibretro.

Most cores also don't support this naming scheme, by the way. It's come up a few times where people want it standardized instead of fixing the root problem in the frontends using this approach.

from ralibretro.

Would putting the chd files in a subdirectory prevent the frontend from processing them? m3u's support both relative and full paths.

from ralibretro.

Would putting the chd files in a subdirectory prevent the frontend from processing them? m3u's support both relative and full paths.

That worked, thanks

from ralibretro.