CUE 'Sonic CD (USA).cue' primary track: Sonic CD (USA) (Track 01).bin Was able to replicate… Comparing with known magic numbers. You could even get it to scan only the ‘actual game’ track if you know your dump set has a name standard and divides music tracks out of the data track: *.cue => *(Track 1).bin:CRC32 Something similar ( *.cue => *.bin:CRC32) could be done to show the relationship between the ‘index’ file from the ‘metadata key’ for ps1 games if you wanted images there for instance. game/*.exe:CRC32 (for any nf use it as index file and use get the metadata key by looking for executables CRC32 you find under the ‘game’ subdir in the dosbox database (from the filename of the detect file). I’m thinking of two things to ‘solve’ this without chd support everywhere, that wouldn’t solve everything anyway, though i’m no C coder: MAME and chd can’t eat them all fast enough. These dumping formats are not preoccupied with indexability or thinking ahead. Of course, track files are a bad way to get to the actual index file needed to play the game shrug. There are others SNAFUs like one of the sets for the dreamcast using the same gdis because someone in the dumping group had the brilliant idea to name track files the same, and nearly all gdis are the same there because there is no salt on the files. By using a cue, you’re introducing false positives for any hack that targets that game. See first post – “Layer Section (Japan) (6M)” and “Layer Section (Japan) (3M)”.Ĭouldn’t there be a switch in RetroArch to let the user pick up the scan method? (serial or checksums).įor reference, here are the libretro-DAT files I created with CUE checksums:Ĭue files are a bad way to get crcs, mostly because the actual game is on the track where the executable is, and so are any modifications or translations. Case in point Layer Section (in the Saturn set). This unfortunately won’t work in the case other games/sets. Perhaps when there are duplicates found, it should pick the one with the least amount of characters in its title? I originally thought that having the index.js pick up the CRC of the CUE would solve the problem (and it does in a way since all 3 versions are accounted for in the libretro-DAT if you change the script to retain the CUE checksum instead of Track01), but I know understand RetroArch has another way to identify CD-based games (serial/magic number). This was the main focus of my initial post above. For example, in the case of Sonic it is “Sonic CD (USA) (RE125) (Alt)”. Yes, with the current index.js routine, it looks like titles with similar Track01.bin checksums are overridden/assimilated under one single title. Rom ( name "Layer Section (Japan) (6M) (Track 01).bin" size 16779168 crc 07e9d8da md5 4cb2552702a5767be5b791efad43762d sha1 d90ef75e7a8d0ff60fceb58d4e534308b85391ea )Ĭould the script entries be based on the cue checksums instead to make sure all versions are accounted for? Except the differences appear from Track 02.bin. The same is true of “Layer Section (Japan) (3M)” and “Layer Section (Japan) (6M)” in the Sega Saturn set. The difference in this case only appears in Track 13: Once parsed with the libretro-dat javascript routine, there is only one entry under “Sonic CD (USA) (RE125) (Alt)” in the libretro redump metadat: game (ĭescription "Sonic CD (USA) (RE125) (Alt)" In the case of “Sonic CD (USA)” for Sega CD, the official Redump DAT has three entries (tracklist abridged for readability) : Īll versions share the same “Track 01.bin” checksums. It seems that the way index.js currently works at is creating issues for some games with alternate versions being misidentified/ignored.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |