Forums  ›  Emulators: Mame  ›  TechTips
 

Questions about CHDs

I am currently trying to get CPS3 games to run on MAME and this requires CHDs for each game.  Usually when I encounter CHDs they have the proper MAME file name along with the chd file extension name.  Here in the Retroroms CHD directory is seems that all the files were extracted out of the CHD file and listed separately.

Will MAME run the games with the files in this format?  It would seem it will look for the exact file name and extension for the CHD, no different from how it looks for other rom files under their specified MAME file names.

Don't hate, emulate!

The CHD is inside those rar files. You just need to extract them with eg. 7-zip.

I extracted them, ran a scan, and MAME says bad SHA-1. Maybe I am doing something wrong? I am pretty sure others on this site can get CPS3 games to run on MAME using the CHDs from this site...I guess undecided

Don't hate, emulate!

for what MAME version? What game/CHDname? ......then I can check it ;-)

I ran the scan on the most current version of MAME 0.217 for Street Fighter III: New Generation (Euro 970204), Street Fighter III Second Impact: Giant Attack (USA 970930), Street Fighter III Third Strike: Fight for the Future (Euro 990608), and Red Earth (Euro 961121). These are the parent roms and the file needed with each game's corresponding CHD checks out good.

Don't hate, emulate!

I have tested Street Fighter III: New Generation (Euro 970204) for MAME 0.217

In the XML-Output is:

<machine name="sfiii" sourcefile="cps3.cpp">

<description>Street Fighter III: New Generation (Euro 970204)</description>

<year>1997</year>

<manufacturer>Capcom</manufacturer>

<rom name="sfiii_euro.29f400.u2" size="524288" crc="27699ddc" sha1="d8b525cd27e584560b129598df31fd2c5b2a682a" region="bios" offset="0"/>

 

<disk name="cap-sf3-3" sha1="20aa46f8ffeb235205dc95cfd8fba42c7d102355" region="scsi:1:cdrom" index="0" writable="no"/>

 

I have tested on the server with chdman the cap-sf3-3.chd, here is the output:

[mucciadmin@server .temprmu]$ chdman verify -i cap-sf3-3.chd

chdman - MAME Compressed Hunks of Data (CHD) manager 0.146 (Jul 31 2016)

Raw SHA1 verification successful!

Overall SHA1 verification successful!

[mucciadmin@server .temprmu]$ chdman info -i cap-sf3-3.chd

chdman - MAME Compressed Hunks of Data (CHD) manager 0.146 (Jul 31 2016)

Input file:   cap-sf3-3.chd

File Version: 5

Logical size: 55,794,816 bytes

Hunk Size:    19,584 bytes

Total Hunks:  2,849

Unit Size:    2,448 bytes

Total Units:  22,792

Compression:  cdlz (CD LZMA), cdzl (CD Deflate), cdfl (CD FLAC)

CHD size:     35,173,219 bytes

Ratio:        63.0%

SHA1:         20aa46f8ffeb235205dc95cfd8fba42c7d102355

Data SHA1:    1156ae04c4dd6dfa67ce110634ccd46bb6881b8d

Metadata:     Tag='CHT2'  Index=0  Length=92 bytes

 

              TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:22792 PREGAP:0 PG

 

ok and now it is your turn!

 

 

Everything checks out on your end. In order for me to verify your results, I need a not too technical explanation of how you scanned and verified the CHD  for Street Fighter 3.  I had MAME run a standard games list audit using Emu Loader v8.8.2, but I don't know how to use the chdman tool to verify the CHDs I have.

 

 

Don't hate, emulate!

I have shorten your reply ;-)

Lets go thru your questions:

- I need a not too technical explanation of how you scanned and verified the CHD  for Street Fighter 3

Its not too technical, I have used the tools that MAME has included: mame64.exe and chdman.exe

In the first step Im checking what information MAME is given me for this game with "-listxml". I have only pasted the important part of it to have the information what chd is needed and the checksum for this chd-file.

Second step is using "chdman.exe" to check the file (Verify) if it is ok. The next step is to show me the information about this chd-file (info).

This information (SHA1) I have compared with the information that MAME provides with "-listxml". 

 

- How does MAME know which game it can emulate? Right it has the information for that:

"mame64.exe -listxml" gives you the information. All games with all the roms and chds are listed there for each game. It includes also checksum SHA1/CRC for checking a file if it is the right one.

In the folder "hash" are the softwarelists for systems. Example: Mame can emulate the C64. For this system they have tested software added in a software list. This lists are added to the folder "hash", example C64 Cassettes Software are in "c64_cass.xml"

 

- I had MAME run a standard games list audit using Emu Loader v8.8.2, but I don't know how to use the chdman tool to verify the CHDs I have.

In the background Emuloader also uses the "-listxml" parameter for MAME to verify the roms/CHD for a game. Thats the reason that you must "refresh" Emuloader when you are adding a new MAME. Emuloader has it own verify-tool to check the information from the output -listxml" against all files.

 

I have written a guide covering some topics for MAME -> mameguide.info

I have the CHDs found on this site along with some I found on another site in the rom directory.  MAME should be able to find the ones that check out good during a scan right?

Don't hate, emulate!

roms and CHDs have to be in a rompath otherwise MAME would complain when you start the game

 

roms and CHDs have to be in a rompath otherwise MAME would complain when you start the game

 I got Street Fighter 3: New Generation to work.  I will try the other games I listed and let you know if they work too.  I ran a different scan in Emu Loader and the CHDs checked out good.

Don't hate, emulate!

Street Fighter 3 2nd Impact: Giant Attack and Street Fighter 3 3rd Strike: Fight For The Future also both work and run the normal CPS3 boot up process.  Now this is where things get weird. Red Earth will not run its clone Warzard runs just fine.  Red Earth is listed as the parent ROM of Red Earth. I thought that clones cannot work unless the parent ROM also works.  It gets even more weird. The parent ROM JoJo no Kimyou na Bouken: Mirai e no Isan AND its clone JoJo's Bizarre Adventure don't work despite of the fact that MAME lists all required files as being present.

Don't hate, emulate!

Need your help.
I have the following case: Software list "dc.xml".
In this there is the following entry:

    <software name="18wheelr">
        <!-- http://redump.org/disc/18129/
        <rom name="18 Wheeler - American Pro Trucker (USA).gdi" size="225" crc="3460f287" md5="95f6a45db8722322c1a435e76b7de72b" sha1="2d542bef13f37103723c316f99d93d2f7c1daf65"/>
        <rom name="18 Wheeler - American Pro Trucker (USA) (Track 1).bin" size="1058400" crc="d1a18678" md5="4bd9dce3c5606b086b64b88ef9610eb7" sha1="c7794a4af576c2adfa9f099984ca91839dfbe6c7"/>
        <rom name="18 Wheeler - American Pro Trucker (USA) (Track 2).bin" size="1589952" crc="8557fcaa" md5="824ff123fbce45b5883962eb3fa43cab" sha1="a3705cb0ce53c7adf906c5af76887406984de6a9"/>
        <rom name="18 Wheeler - American Pro Trucker (USA) (Track 3).bin" size="1185760800" crc="41d83a31" md5="16b0672b221ed0d0eecb6a9d6e8783f9" sha1="fc4ce908933d90cf3624737349208caca5533700"/>
        -->
        <description>18 Wheeler: American Pro Trucker (USA)</description>
        <year>2001</year>
        <publisher>Sega</publisher>
        <info name="serial" value="51064"/>
        <info name="release" value="20010518"/>
        <info name="ring_code" value="(F2297) 51064 06   Technicolor"/>
        <info name="barcode" value="0 10086 51064 5"/>
        <part interface="cdrom" name="cdrom">
            <diskarea name="cdrom">
                <disk name="18 wheeler american pro trucker (usa)" sha1="c03adc04607282f755d10abb9b69975b74b25869"/>
            </diskarea>
        </part>
    </software>

My files are:

18 Wheeler - American Pro Trucker (USA).gdi - sha1:2d542bef13f37103723c316f99d93d2f7c1daf65
18 Wheeler - American Pro Trucker (USA) (Track 1).bin - sha1:c7794a4af576c2adfa9f099984ca91839dfbe6c7
18 Wheeler - American Pro Trucker (USA) (Track 2).bin - sha1:a3705cb0ce53c7adf906c5af76887406984de6a9
18 Wheeler - American Pro Trucker (USA) (Track 3).bin - sha1:fc4ce908933d90cf3624737349208caca5533700

The Result of the created CHD is:

==========================================================================
== Date 02/11/2020
== Time 12:15:38
==========================================================================
Input file:   18 Wheeler - American Pro Trucker (USA).chd
File Version: 5
Logical size: 1,344,333,888 bytes
Hunk Size:    19,584 bytes
Total Hunks:  68,645
Unit Size:    2,448 bytes
Total Units:  549,156
Compression:  cdlz (CD LZMA), cdzl (CD Deflate), cdfl (CD FLAC)
CHD size:     161,712,301 bytes
Ratio:        12.0%
SHA1:         9a4edd2c2868b27d9a3c9c9ea92fa614ebb15452
Data SHA1:    b93911ff46fab949b2921a34b16ac9668a67dba1
Metadata:     Tag='CHGT'  Index=0  Length=94 bytes
              TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:450 PAD:0 PREGAP:
Metadata:     Tag='CHGT'  Index=1  Length=96 bytes
              TRACK:2 TYPE:AUDIO SUBTYPE:NONE FRAMES:44550 PAD:43874 PREGA
Metadata:     Tag='CHGT'  Index=2  Length=97 bytes
              TRACK:3 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:504150 PAD:0 PREG


Now I have these files and the SHA1 of the rips is correct with the one specified in the comment-header of dc.xml. If I now convert the gdi file to chd with chdman 0.149 then RomVault does not recognize the chd. Which chdman do I have to use to make it work? I read that there are probably inconsistencies in the different chdman versions. So far it had worked, but now I don't understand anything.

Any help are appreciated.

TIA and Cheers ;)

OK Guys, after a little search and inspect I found a solution.

I used chdman version from MAME 0.175 to create the chd. Same files like before but the result will now be recognized.
The chdman version after 0.175 -> 0.176 will not work because the change of the structure is not the right one.

Here it is the new Resultoutput created with chdman v.0.175:

==========================================================================
== Date 02/11/2020
== Time 22:14:33
==========================================================================
Input file:   18 wheeler american pro trucker (usa).chd
File Version: 5
Logical size: 1,344,333,888 bytes
Hunk Size:    19,584 bytes
Total Hunks:  68,645
Unit Size:    2,448 bytes
Total Units:  549,156
Compression:  cdlz (CD LZMA), cdzl (CD Deflate), cdfl (CD FLAC)
CHD size:     161,630,136 bytes
Ratio:        12.0%
SHA1:         c03adc04607282f755d10abb9b69975b74b25869
Data SHA1:    35dddb33a399ee5eb0362492a24b6401df78baea
Metadata:     Tag='CHGD'  Index=0  Length=96 bytes
              TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:450 PAD:0 PREGAP:
Metadata:     Tag='CHGD'  Index=1  Length=98 bytes
              TRACK:2 TYPE:AUDIO SUBTYPE:NONE FRAMES:44550 PAD:43874 PREGA
Metadata:     Tag='CHGD'  Index=2  Length=99 bytes
              TRACK:3 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:504150 PAD:0 PREG

Maybe some will be found it usefull.

Happy hunting and gaming.

Cheers ;)

 

OK Guys, after a little search and inspect I found a solution.

 I hadn't heard of this before but I guess you found it here: https://github.com/mamedev/mame/issues/2517


Looks like in an ideal world lots of the SL CHDs need to be remade from the source files using chdman > 0.176.

 

Looks like in an ideal world lots of the SL CHDs need to be remade from the source files using chdman > 0.176.

Yes, sad or not?

Isn't it insane that the check with chdman0.149 runs correctly with created chds from version 0.175? Why does it not pack it properly?

It is blatant that only if you have a gdi file that looks a little different and actually the files that make up the CD are the right ones you cannot reproduce the right chd. Pack the search and the whole thing with the right chdman and then test whether it is finally the right file or not and then repeat the whole process is f*****g awesome. Well, whining alone does not help, so far I have no choice but to go through the files one by one and no downloading a package. That will take years.

 

The next abnormality in the creation.

The following test was done:

Example: Aero Dancing F (Japan) (Taikenban).chd
The archive is from: Sega Dreamcast Redump at Archive.org

The following is in the dc.xml:
<! - http://redump.org/disc/27130/
<rom name = "Aero Dancing F (Japan) (Taikenban) .gdi" size = "210" crc = "e081d152" md5 = "77488246e00500d8dc652c5d2607d194" sha1 = "6ea760f21dcf4d0491335b3e3bf66f877d7afbf5"/>
<rom name = "Aero Dancing F (Japan) (Taikenban) (Track 1) .bin" size = "2154432" crc = "747899c8" md5 = "4254b40d9bae69d6531feb74ff32306e" sha1 = "372d7b4a3217e7769974c2be7f5ccff258f076fe"/>
<rom name = "Aero Dancing F (Japan) (Taikenban) (Track 2) .bin" size = "37716672" crc = "593fb5ea" md5 = "130e6981084b5c2aa9730bfe512f1f45" sha1 = "f96e2c38b4e665edf4396938001adfa1b5f0965e"/>
<rom name = "Aero Dancing F (Japan) (Taikenban) (Track 3) .bin" size = "1185760800" crc = "b0c4335d" md5 = "ab4e6134c57af0c462759c011ce9779e" sha1 = "0f6f86ce9666b71b37ad1683a6c7e70f8eb6fd9b"/>
->

NOTE: Differencies marked as BLUE.
The files: ...(Track 1).bin, ...(Track 2).bin, ...(Track 3).bin are used in both chd creations, and are identical with the sha1 of the dc.xml (marked as pink)!


You will find out that In the file: Aero Dancing F (Japan) (Taikenban).7z there is no GDI-file included, but a CUE-file.
If you convert this as chd with chdman 0.175 you get the following:

====================================================== CHD created with .cue file
== Date 02/12/2020
== Time 01:15:10
==========================================================================
Input file:   Aero Dancing F (Japan) (Taikenban).chd
File Version: 5
Logical size: 1,275,662,592 bytes
Hunk Size:    19,584 bytes
Total Hunks:  65,138
Unit Size:    2,448 bytes
Total Units:  521,104
Compression:  cdlz (CD LZMA), cdzl (CD Deflate), cdfl (CD FLAC)
CHD size:     607,789,517 bytes
Ratio:        47.6%
SHA1:         75ece6637ef91029d5ce7e6ef7177a422f8aab72
Data SHA1:    a1bd3eab241dd42f9cf54c268595354f308c5adf
Metadata:     Tag='CHT2'  Index=0  Length=88 bytes
              TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:916 PREGAP:0 PGTY
Metadata:     Tag='CHT2'  Index=1  Length=89 bytes
              TRACK:2 TYPE:AUDIO SUBTYPE:NONE FRAMES:16036 PREGAP:150 PGTY
Metadata:     Tag='CHT2'  Index=2  Length=91 bytes
              TRACK:3 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:504150 PREGAP:0 P

and this created chd was not recognized.

The cue file looks so:

REM SINGLE-DENSITY AREA
FILE "Aero Dancing F (Japan) (Taikenban) (Track 1).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "Aero Dancing F (Japan) (Taikenban) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
REM HIGH-DENSITY AREA
FILE "Aero Dancing F (Japan) (Taikenban) (Track 3).bin" BINARY
  TRACK 03 MODE1/2352
    INDEX 01 00:00:00

 

If you download the file Sega Dreamcast Redump.org GDI-Files and extract the gdi file from redump.org under downloads and then create it with
chdman 0.175 you get the following:

====================================================== CHD created with .gdi file
== Date 02/12/2020
== Time 01:15:10
==========================================================================
Input file:   Aero Dancing F (Japan) (Taikenban).chd
File Version: 5
Logical size: 1,344,324,096 bytes
Hunk Size:    19,584 bytes
Total Hunks:  68,644
Unit Size:    2,448 bytes
Total Units:  549,152
Compression:  cdlz (CD LZMA), cdzl (CD Deflate), cdfl (CD FLAC)
CHD size:     607,789,568 bytes
Ratio:        45.2%
SHA1:         1cad8b87da985cda2c86fb1edb8e6390703071a7
Data SHA1:    94c5e109a5729463481141749baa907b5e1e05c3
Metadata:     Tag='CHGD'  Index=0  Length=96 bytes
              TRACK:1 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:916 PAD:0 PREGAP:
Metadata:     Tag='CHGD'  Index=1  Length=98 bytes
              TRACK:2 TYPE:AUDIO SUBTYPE:NONE FRAMES:44084 PAD:28048 PREGA
Metadata:     Tag='CHGD'  Index=2  Length=99 bytes
              TRACK:3 TYPE:MODE1_RAW SUBTYPE:NONE FRAMES:504150 PAD:0 PREG

and this will be recognized.

The gdi file looks so:

3
1     0 4 2352 "Aero Dancing F (Japan) (Taikenban) (Track 1).bin" 0
2   916 0 2352 "Aero Dancing F (Japan) (Taikenban) (Track 2).bin" 0
3 45000 4 2352 "Aero Dancing F (Japan) (Taikenban) (Track 3).bin" 0

Cheers... this will take some time to acomplish.

The xml says that their CHD was created using a gdi so of course it won't work if you use a cue file instead.

 

The xml says that their CHD was created using a gdi so of course it won't work if you use a cue file instead.

I know that, but do you know that you only need that gdi file and you can download and convert all to the right chd files from the archive.org?
I mean, come on. We talk here about 1-2kb of the TOC Information to reproduce the right ones. No one had told me how this can be doable.
The Tracks are the same.

Tested 10 additional files from that archive and all works with that method above I mentioned.