MKPSXISO - A PlayStation ISO Maker to Replace BUILDCD

[LameGuy64]

Anyways, presence/absence of those RIFF headers might cause problems. Unless mkpsxiso is automatically removing them when present?

I have not seen a file in a PSX CD that contains a RIFF header so far. MKPSXISO does not strip RIFF headers from any files (in fact, STR and XA files have no RIFF headers whatsoever).

I looked at the xa.bin headers in hxd, and from I can tell it looks like the xa is further down. So it's basically a non-standard header.

Maybe there's more data than just xa in there.

Possible. I've been testing my new isodump tool and while it is capable of extracting most CD-XA and STR files correctly, I notice it won't extract certain XA/STR files correctly on certain games, likely a case of the data being encoded differently and I need to tweak my isodump tool to take such things into account. I'm going to have to study how the files are encoded to the disc and figure out a way to extract it properly.

If you guys want, I can release isodump early on with source if it helps.

[47iscool]

A release of this new tool would be great.

I could test and report back later.
Edit: Found something but it's in Italian:
https://assemblergames.com/threads/psx- ... ize.55133/

[LameGuy64]

Okay, here's isodump: https://github.com/Lameguy64/isodump

I recently discovered that CDmage will actually inject a RIFF header when you extract an XA file with it which in turn, allows you to play it on Windows Media Player! Though you can only listen the first XA channel and I don't think you can listen to the other XA channels with Windows Media Player that I'm aware of.

[nocash]

Normally the RIFF headers are injected by the Windows operation system. For example, if you use windows explorer to copy a file from cdrom to harddisk, and then open the harddisk file in a hex editor. In fact, I think you won't even need to copy the file: You could directly open the file on CDROM in any hex editor, and, under windows, you would see the RIFF header there, too.

Don't know if other operation systems are doing something similar, too. And don't know what the RIFF header is good for, except, it's telling you that file contains 930h-byte sectors (with stuff like copies of the cdrom's MM:SS:FF:MODE header values in each sector (which is meaningless but still present even when you've copied the file to harddisk)), and maybe it's also containing some useful info extracted from the file's cdrom directory entry (some sort of file-fype, or file-/channel-info, or whatever).

Wouldn't be bad if your tool could deal with those RIFF headers. Either throw a warning message and tell users to dump the raw file without header, or you could try to remove the header and convert the file to raw data (maybe you could also use the header to auto-detect the file type).

[47iscool]

Tried isodump. Games won't boot after extracting with the tool. Alsofor some games it won't dump all of the files.

Not complaining though because I know it's a WIP.

[LameGuy64]

Tried isodump. Games won't boot after extracting with the tool. Alsofor some games it won't dump all of the files.

Strange, the game I used to test (CTR) did boot when rebuilt with MKPSXISO from the dumped files but some things such as some XA audio got borked in the rebuilt copy.

What are the games in question where isodump won't extract some of its files? I think the type of files isodump cannot extract are DA audio files for now as I was focusing mostly on XA/STR stuff. Also, MKPSXISO currently does not support injecting CD-DA tracks as DA files similar to what some PSX games have.

[47iscool]

MegaMan Legends is one such game where only some of the files were extracted.

[spacorn]

Hey, LameGuy64, thank you very much! This tool has made possible a small project I've been trying to make for a long time.

I have a question about one of its features. The readme file mentions "Supports CD-DA audio tracks from uncompressed WAV files". I suppose that means separate audio tracks. But what about uncompressed audio tracks inside the main data track?

I'm currently working on a hack of a game that has a .DA audio file in the root of the data track (I confirmed it works as an uncompressed 16b WAV file). When loading the original game disc on CDmage, this file has the "FM" flag, just like the STR videos.

I know I have to define the "type" of the files on the XML (data, xa, str)... If I build my modified disc image (in-game TOC taken care of, everything else works) defining this track as a "data" track, the part where this audio file should play runs completely silent.

Is there a separate "type" tag for this kind of audio files? What's the correct way to define them in the xml file so they are written correctly as streamed audio on the built disc?

Thanks in advance!

[LameGuy64]

Hi spacorn, glad to hear you found my mkpsxiso tool to be very useful for your project.

mkpsxiso only supports audio tracks as separate CD audio tracks with the first track being data only. You cannot really store an audio track inside the main data track as the PlayStation needs it to be mapped in the TOC as an audio track. DA files are just 'pointer' files that point to a audio track and said track is also mapped in the TOC as a CD audio track as the PlayStation cannot play CD audio without it being mapped in the TOC.

Does the game try to play an audio track using the LBA location of those DA files or does it use the CD TOC instead?

Currently, there's no support for such file types but I'll consider adding DA file support once I find the time to update mkpsxiso.

[spacorn]

Hi spacorn, glad to hear you found my mkpsxiso tool to be very useful for your project.

mkpsxiso only supports audio tracks as separate CD audio tracks with the first track being data only. You cannot really store an audio track inside the main data track as the PlayStation needs it to be mapped in the TOC as an audio track. DA files are just 'pointer' files that point to a audio track and said track is also mapped in the TOC as a CD audio track as the PlayStation cannot play CD audio without it being mapped in the TOC.

Does the game try to play an audio track using the LBA location of those DA files or does it use the CD TOC instead?

Currently, there's no support for such file types but I'll consider adding DA file support once I find the time to update mkpsxiso.

Thanks for your quick response!

I'm pretty sure the game loads the audio straight from the file because when I replace the file on the original unmodified game with a different renamed WAV file (using CDmage, "Import file"), the new audio plays in-game perfectly (even though I don't touch any of the separate CDDA tracks of the game).

However, if I try the same process of importing a different (or even the same, umodified) audio file on my mkpsxiso modified build (with said file defined as XA type), CDmage doesn’t let me replace it (“file must have CD-XA format”) even though it’s the same renamed wav file that works on the original. This led me to the conclusion this file is neither a data type file nor a standard XA audio file (as I mentioned, in the original unmodified game the file has the same "FM" tag than XA/STR files).

I'm also guessing the game loads it from it's own TOC (a section inside the game's main executable). If I purposely write a wrong LBA for this audio file, the affected “scene” (ending credits) doesn’t even load. I guess the file is being found and loaded and just can't be played.

The game is Mega Man 8 by the way, and the audio file in question is END1.DA, which sits in the root of the data track, and at the end of the TOC.

If this is something that needs to be addressed as a new feature, well, count this as a very heartfelt request! And thank you so much for everything your tool has made possible for me so far!

[LameGuy64]

Released version 1.18 which comes with a bunch of internal tweaks and bugfixes. I also added support for DA audio files like what many PS1 games featuring CD audio tracks had as well as adding support for raw audio files (it assumes any file that isn't a WAV as raw audio).

Download it here

[spacorn]

Thank you very much, I'm very grateful and humbled by how quickly you addressed this. I'll try it as soon as I get home!

[spacorn]

I'm sorry, the new version is not working for me. When running it, with or without parameters, I'm not getting anything, not even a message printed on the command line.

Is everything ok with the provided binary file? I notice it's about half the size v1.15 had (228kb vs 471kb)

[LameGuy64]

That's odd, it works fine for me. Did you get any error messages when trying to run it?

[spacorn]

The first time I tried it I didn't get any error messages, and no lines were printed on the command line. Now after running it with elevated rights, I get an error message "libgcc_s_dw2-1.dll" and "libstdc++-6.dll". If I use a copy I have of those DLLs taken from another programs, I get a 0xc00007b error code.

This is Windows 10 x64 by the way. It could be just a dependencies problem on my end, but I haven't been able to get past it. I never had this problem with any past version.

[LameGuy64]

Ah, looks like my code changes to mkpsxiso to use more C++ features caused that issue. I'll fix the download to include the necessary dll files in a bit.

[LameGuy64]

Just updated the download to include the missing dlls. Get it here.

[spacorn]

I figured the cause was something like that, as I'd seen those dlls included on other programs. I just couldn't get it to work taking them straight from something else.

Thank you so much, now the program is running perfectly and building my image with no issue! I can't test my project at the moment but once I get back from work I'll let you know how it goes!

[spacorn]

It worked out perfectly! Thank you so much for taking the time to answer my questions and adding this feature!

Good luck with any project you're currently working on! I'm gonna start visiting these forums more often

[spacorn]

I’ve now completed two small rom hack projects using your tool, including the one I mentioned before, and have a third one well underway

Now, in case use case testimonies are welcome, I want to share a few things. None of these have prevented me from getting fully functional discs. They’re just a few oddities I’ve encountered along the way.

#1 Incorrect reading of file structure in IsoBuster
When I load a disc image made with mkpsxiso in IsoBuster, inside the first subfolder there are duplicate listing of any subsequent subfolder present in the root.

The LBAs are correct, and the disc is completely functional, this only affects the way they’re shown within this program.
This does not happen when I load the original game rip of the same game.

It could be just a problem of Isobuster itself (I don’t have this problem using CDmage, for example), but I thought it would be interesting, since it could be a sign of something mkpsxiso is doing differently to original PSX discs.

#2 LBA orders I can’t replicate on the XML

The games I’ve been working with have weird file orders where the LBA can go inside a subfolder, then back the root, then back inside he first subfolder, etc.
Example: Mega Man X6
When ordered by LBA, the file list looks like this:

Code: Select all

\STR\, LBA 23
\XA\, LBA 24
\STR\CAPLOGO.STR, LBA 25
\XA\DEMO.XA, LBA 961
\XA\BGM.XA, LBA 25.217
\SYSTEM.CNF, LBA 195.657
\STR\X6OP.STR, LBA 195.658
\SLUS_013.95, LBA 210.930
\ROCK_X6.BIN, LBA 211.185
\ROCK_X6.DAT, LBA 211.998
\ZNULL.DAT, LBA 236.858

On these cases, I can’t replicate the file order exactly when rebuilding with mkpsxiso (since I can’t make an empty folder first, move on to other files on the root, then back to filling the first folder. I can't have duplicate directory entries on the XML)

#3 Problems loading the last file before a DA audio track

(While the others have happened since v1.15, this obviously happened on v1.18)
When testing my Mega Man 8 mod after switching to v1.8, I encountered a freeze in a place I didn't have problems before. It was on a certain boss fight, at the moment the game loaded a file called "W_DEVIL.PAC". This didn't happen when building the disc with v1.15.
I realized the problematic file was the last file in the table of contents (before the .DA file at the very end)

Code: Select all

\STDATA\W_DEVIL.PAC, LBA LBA 142.493
\END1.DA, LBA 142.558

Since the problem started after the .DA file was properly implemented as an audio track, I added a big dummy file at the very end to see if it affected anything.

Code: Select all

\STDATA\W_DEVIL.PAC, LBA 142.493
\ZNULL.DAT, LBA 142.558
\END1.DA, LBA 160.646

Surprise, the boss fight loaded perfectly after that.

#4 DA music track has some sound on real hardware.
I wasn't sure if this was worth mentioning or not since it could be caused by number of other reasons (bad media, bad burn, bad console laser, etc), but I'll mention it just in case.
When testing my project in Retroarch Beetle PSX, the music played just fine, but when playing it on my PS2, the music had some glitched bits in the last parts of the track.
Also, it seems the track is starting to play at a different time in emulators than in hardware (again, could be an emulation problem. Seems like emulators ignore the default 2 second offset at the start defined by default in the CUE sheet when building the disc, whike hardware uses it.)