# Difference between revisions of "Talk:MAME"

## Chdman.exe not staying open in Windows

Basically whether I double-click the exe, run it as admin or in any compatibility mode, the terminal will open and close within a split second. I haven't seen any functionality within the MAME program itself for launching Chdman. I haven't been able to find documentation of this problem on the Google-visible web, which made me think this was just me. However, I've reproduced the issue on Windows 7, 8.1 and 10 on two separate PCs so far, attempting to open the Chdman program from both 64 and 32 bit MAME binaries of versions 0.195, .182, .150 and .137, to name just a few.

I would have brought this up on MAME's official forum but my new account is on a moratorium until an admin can activate it (probably a day or two). Perhaps Windows has inadvertently killed the functionality of Chdman in recent months?

Jack Ryan (talk) 08:15, 16 March 2018 (EDT)

In that case, it's probably an app without a GUI that's meant to be run in a command prompt. Open a command prompt in the location of chdman by opening cmd.exe, then "cd C:\Path\To\MAME". Then run chdman. --Syboxez (talk) 13:06, 16 March 2018 (EDT)
Syboxez is correct, chdman is a CLI-based program which means you need to run it from the command prompt. Chdman won't stay open because running it with no command(s) will list all the options available and then close (like CLI programs normally do) so that control can be passed back to the user to type more commands as they need to. This is a component of the command-line, not a software issue. While it's true that you can open the command prompt and get to the folder by typing cd "location", you can actually open it in the folder itself by clicking on the address bar in Windows Explorer so that it lets you type a new location in, and then replacing it with cmd (and pressing enter). You should do this in the folder where mame and chdman are installed so that you can immediately run chdman when the prompt opens. To use the program in other folders, you will either to have to type out the full location of either chdman itself or the images you want to work with, or alternatively add the installation directory to your path. -FosterHaven (talk) 18:07, 16 March 2018 (EDT)
Thanks both, Command Prompt does indeed interface with it. The closest experience I've had to this was with DOSbox, so I never would have guessed this one needs CP to be open first. I've been mucking around with it all day to try and convert a Sega Saturn .cue/.bin image pair to .chd so SSF can use it. I was following instructions on both this wiki's MAME page, the last post in this thread and a combination of the two. The closest I got to a conversion was a 124 byte .chd file, and it does not seem to be usable with the CHDSSF loader. Specifically, the line that gave me this result looked like: D:\path\to\games>"D:\path\to\MAME\chdman.exe" createcd -o "Game.chd" -i "Game.bin"|"Game.cue". The resulting line was: Compressing, nan% complete... (ratio=100.0%)
Interestingly, swapping around the .cue and .bin text in the line gives me: Error parsing input file (Game.cue: file not found) Fatal error occurred: 1.
If wondering, the most common result I got with different methods, including following as closely as possible the one listed on the aforementioned MAME page's "Convert files to CHD" section, was: Error: expected option, not parameter, and then a list of "valid" options below. Is it fair to assume the method listed on the page does not work, or am I misinterpreting the syntax? I already worked out that the "\$" is apparently a bad programmer shorthand habit that throws people off occasionally, eh. Jack Ryan (talk) 12:18, 17 March 2018 (EDT)
I believe you are. Chdman does not take the -i parameter like other programs do, as the input is specified right after the output (in the example anyways). You also shouldn't be telling chdman what it already knows; the cue sheet describes how the CD is laid out and will point to the bin file so that programs can lay it out properly (use any text editor and you'll see ".bin" somewhere in it as a track). This is why dragging the cue file onto an emulator like Mednafen works.
The correct syntax in this case is: >chdman.exe createcd -o "Game.chd" "Game.cue"
-FosterHaven (talk) 20:15, 17 March 2018 (EDT)
Thankyou for the clarification. The problem turned out to be the cue file's reference to its bin file's path. On the top line in Notepad was a path pointing to an esoteric location on an F drive for God knows what reason. I fixed the cue text by just pointing it to the bin's relative path in the same folder, and later also got rid of a two-second "PREGAP" that was set to always cut off the start of Track 02 (again... for some reason). Anyway once that first change was made, to my joy chdman converted the cue/bin to a working chd file. I should note though that while the conversion went as it should with the -o and -i in front of the output and input files respectively (and in either order), leaving out the -i always resulted in a expected option, not parameter error. Jack Ryan (talk) 08:41, 18 March 2018 (EDT)
-i started being enforced after a version of the mame-tools package I might not have received (which explains a lot, actually). After reading this guide, which explains this was part of a rewrite sometime during 0.145 or after, I've been left to assume my package didn't get that version. I'll update the guide later. Thanks for bringing it to light. -FosterHaven (talk) 16:46, 18 March 2018 (EDT)

Just to be certain, chdman can only handle conversions from cue/bin archives? Jack Ryan (talk) 12:53, 18 March 2018 (EDT)

For CDs, yes because it is the closest representation of the CD without being the CD itself (the cue sheet can be thought of as the master boot record by specifying multiple tracks or "partitions" with different kinds of data like audio, filesystems, game data, etc). But chdman works with hard drives and laserdiscs as well, so they probably require their own format (or like the guide above shows, can be worked with directly). -FosterHaven (talk) 16:46, 18 March 2018 (EDT)