Building on Ubuntu 16.04 64-bit.

Compiler throws several error: ‘nullptr’ was not declared in this scope and error: ‘std::__cxx11::string {aka class std::__cxx11::basic_string<char>}’ has no member named ‘back’ from several files unless -std=c++11 is added to the CXX_FLAGS (i.e. CMake doesn't add that itself so they have to be manually added to flags.make).

Also throws error: ‘class tinyxml2::XMLDocument’ has no member named ‘GetErrorLineNum’ for main.cpp. This documentation specifies ErrorLineNum() instead and changing it to that clears the issue.

After fixing those, mkpsxiso compiles properly.

happens regardless if its via header or regular text file

It took me a moment to track down this bug, but basically it was causing invalid ISO file name entries (they would either be blank or a mix of random characters).

For reference, I am using the lastest v1.19 source material and compiling with vs2017 in Windows 10/x64.

I easily fixed it by assigning entry.id:

entry.id = temp_name; entry.id.assign(temp_name.c_str());

...and verified ISO output as working properly.

Thank you for maintaining this application, LameGuy! :)

If any given directory/folder contains more than 32 files, mkpsxiso will crash just as it appears to be finalizing the disc.

As a result, the cue sheet is not generated and the BIN image appears to be useless.

Hello - thanks for this tool, it's going to be completely invaluable for my work on FFVII modding. The traditional workflow of manually updating files in CDMage (a beta app written for Win9X) and juggling disc images was a major pain for mod development. Now with mkpsxiso, I can simply keep files in git and script .cue/.bin generation for emulator playtesting.

Issue

However, I have noticed an issue: when building my projects with the latest release of mkpsxiso, the games boot as PlayStation titles but promptly crash. Builds do however work with the v1.26 release.

When I do a hex diff of the .bin files I see changes appearing around the 0x7650 mark - these values are zeroed out in my broken_build.bin but nonzero in my working_build. I am not really au fait with CD archive formats, but if I understand correctly and the .bin is just a set of mode2 2352 byte sectors packed end to end, then 0x7650 -> 30288 decimal -> 2064 bytes into the 12th sector.

My understanding of the PSX format is that these sectors are zeroed, but must still have the appropriate ECC data. According to #24 emulators can be sensitive to the encoding on these sectors, so perhaps that's the issue.

That said, there are other differences - I can dig further into the diff if needs be. But those may be non-functional differences.

Please let me know if there's any other info I can provide

Hi, is there a way to specify a game ID? Maybe as an identifier?
something like ie: "SLUS-1234"
Thanks!

Thank you for the fantastic tool. I'm really glad that people don't have to resort to leaked copies of old commercial software anymore.

I've run into a weird issue while trying to rebuild a game that made heavy use of nested directories. Looking back on other disc images I've generated with mkpsxiso, they actually had the same problem, but it didn't cause me enough grief to notice in the earlier cases.

If the filesystem contains nested directories with depth of 3 or greater, most (if not all) content written to the image after the first most-deeply-nested part of the directory tree is unreadable by most tools. i.e. trying to access the content with the image attached via VirtualCloneDrive will fail, and games running in ePSXe will be unable to access it either. WinISO can access the content, so I suspect it's some sort of subtle corruption of the filesystem as opposed to an obvious flaw.

I've uploaded a minimal test case here: https://www.beneaththewaves.net/noindex/other/mkpsxiso-nested_dirs.zip. It includes both the source files and a bin/cue image created with the current version of mkpsxiso. I tried going back as far as 1.14 and the issue still occurred there.

Steps to reproduce:

1 - If desired, rebuild the bin/cue image using the XML and files in the archive linked above. It will be necessary to update the paths in the XML file, of course.
2 - Attach the image via VirtualCloneDrive.
3 - Observe that the following files can be accessed:
- \TEST.TXT
- \LEVEL01-01\TEST.TXT
- \LEVEL01-01\LEVEL02-01\TEST.TXT
- \LEVEL01-01\LEVEL02-01\LEVEL03-01\TEST.TXT
- \LEVEL01-01\LEVEL02-01\LEVEL03-02\TEST.TXT
4 - Observe that the following directories cannot be accessed, and will generate a "Location is not available" error in Windows:
- \LEVEL01-01\LEVEL02-02
- \LEVEL01-02
5 - Observe that this issue does not occur in VirtualCloneDrive with images generated using other tools.

I've recently discovered that CD Audio tracks got broken in 1.22 where such tracks cannot be played properly or at all on a emulator and possibly real hardware.

I'm going to look into this issue and get it fixed when I find the time.

There are many games that have size and LBA values directly from the PSX-EXE (Executable), would there be a possibility implement that when the ISO is created? So the values would be recalculated internally in PSX-EXE too.

It would make sense to use XML project filename instead of hardcoded "mkpsxiso".
Also it leads to some inconsistency when you specify -o key. BIN name is overriden, but CUE name still taken from the XML project.

baseElement->SetAttribute(xml::attrib::IMAGE_NAME, "mkpsxiso.bin");
baseElement->SetAttribute(xml::attrib::CUE_SHEET, "mkpsxiso.cue");

I extracted the bin of Soul Blade (USA) v1.1 with dumpsxiso, and then tried to rebuild the iso with mkpsxiso, but when adding the big XA file, the program throws a std::system_error with message what(): Resource temporarily unavailable.

Previous versions, such as the ones I build from my fork: https://github.com/marco-calautti/mkpsxiso
rebuild the bin without issues.

The recent rewrite has added a lot of changed code that I fear has not been properly tested, and thus regressed the tool, rather than improving it. I have encountered similar problems with other games, which now I cannot remember, while with previous versions everything was fine.

If the last file is a multiple of 2048, then an extra empty sector is added to the image at the end. You can check it through IsoBuster

I recently updated from v1.26 to v2.04 and my previously working XML files are now displaying "File not found" errors. The path shown in the log shows that the base directory I defined using the src_dir attribute for "directory_tree" is not being used to locate the files, the path shows the same base directory as the XML file.

Not a major problem. Could work around it by rewriting everything to use absolute paths or moving the XML elsewhere. Just wanted to report because it seems like an unintended regression.

When I tried running a simple font demo in PCSX-Redux, it couldn't find the bin file. Turns out the culprit was here:

<iso_project
	image_name="build/langs.bin"
	cue_sheet="build/langs.cue"
>

I'm keeping source files in a directory/folder and the built files in a subdirectory/subfolder. And the xml file isn't built/generated, so it's in the same directory as the source code, the directory that I'm calling mkpsxiso from (through make).

The langs.bin file in the build directory ends up like this:

FILE "build/langs.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00

I think if the cue and bin files are in the same directory, it would make sense for the cue file to just reference the filename of the bin file, like this:

FILE "langs.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00

I haven't rebuilt mkpsxiso after the CMake updates to this project and PSn00bSDK, so it's possible that games built with CMake avoid this issue. But I thought I should concentrate on the demo rather than adapting it to using CMake, so I thought I'd at least write somewhere that this can happen, in case others make some game and wonder why it works in some emulators but not others.

Edit: I had posted the same cue file contents twice in the above post. I've fixed that now. I've also looked into what happens if I call mkpsxiso from the target directory, and it works with some tweaks, which I'll put in a comment.

The instructions say:

"make -f Makefile.chr This will convert all the character jsons in iso/ to chr files that contain mapping and art data."

I run that and I get:

make -f Makefile.chr  ✔
make: Makefile.chr: No such file or directory
make: *** No rule to make target 'Makefile.chr'. Stop.
   ~/{/PSn00bFunkin-1.0 

Did i do something wrong? I tried twice with -x and -s and another time with only -s and it just extracted the files no indication of an xml being created of failed to be created.

E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin>dumpsxiso -x E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\ -s E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\xml\ E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\1.bin
DUMPSXISO 2.03 - PlayStation ISO dumping tool
2017 Meido-Tek Productions (John "Lameguy" Wilbert Villamor/Lameguy64)
2020 Phoenix (SadNES cITy)
2021-2022 Silent, Chromaryu, G4Vi, and spicyjpeg

Output directory : E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\
ISO descriptor:

   System ID      : PLAYSTATION
   Volume ID      :
   Volume Set ID  :
   Publisher ID   :
   Data Prep. ID  :
   Application ID : PLAYSTATION

   Volume Create Date : 1999083112000000+0
   Volume Modify Date : 0000000000000000+0
   Volume Expire Date : 0000000000000000+0

ISO contents:

   Extracting SYSTEM.CNF;1...
E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\SYSTEM.CNF
   Extracting SLUS_006.60;1...
E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\SLUS_006.60
   Extracting DATA.BIN;1...
E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\DATA.BIN
   Extracting STRA.BIN;1...
E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\STRA.BIN
   Extracting XA.BIN;1...
E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\output\XA.BIN

E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin>dumpsxiso -s E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\xml\ E:\Desktop\mkpsxiso-2.03-win64\mkpsxiso-2.03-win64\bin\1.bin
DUMPSXISO 2.03 - PlayStation ISO dumping tool
2017 Meido-Tek Productions (John "Lameguy" Wilbert Villamor/Lameguy64)
2020 Phoenix (SadNES cITy)
2021-2022 Silent, Chromaryu, G4Vi, and spicyjpeg

ISO descriptor:

   System ID      : PLAYSTATION
   Volume ID      :
   Volume Set ID  :
   Publisher ID   :
   Data Prep. ID  :
   Application ID : PLAYSTATION

   Volume Create Date : 1999083112000000+0
   Volume Modify Date : 0000000000000000+0
   Volume Expire Date : 0000000000000000+0

ISO contents:

   Extracting SYSTEM.CNF;1...
SYSTEM.CNF
   Extracting SLUS_006.60;1...
SLUS_006.60
   Extracting DATA.BIN;1...
DATA.BIN
   Extracting STRA.BIN;1...
STRA.BIN
   Extracting XA.BIN;1...
XA.BIN

Original ISO

Remake ISO

I did not change the size of these STR files.
In the PSX ISO, the display size of the STR file in the directory is the LBA number multiplied by 2048.
The actual file size is the LBA number multiplied by 2336.

45636096/2336=19536
19536*2048=40009728

I can't find mkisoxml anywhere in the binary or source code for any platform.

If you tell dumpsxiso.exe to unpack e.g. a cuesheet, it crashes instead of failing gracefully.

As it says on the tin. The game has three .bin tracks - the first is the game data and the next two are the two audio tracks. I am unsure if I am doing something wrong as I am new to this tool.

I have tried the following two processes:

PROCESS 1 - REBUILDING WITH DUMMY AUDIO:

1. Run dumpsxiso -s export.xml -S "T kara Hajimaru Monogatari (Japan) (Track 1).bin". This creates dummy .wav files.
2. Run mkpsxiso -y -c final.cue export.xml
3. Open the resulting .cue file in Duckstation to a blank screen.

PROCESS 2 - REBUILDING WITH GAME AUDIO

1. Run dumpsxiso -s export.xml -S "T kara Hajimaru Monogatari (Japan) (Track 1).bin"
2. Copy T kara Hajimaru Monogatari (Japan) (Track 2).bin to DA/BOSS.BIN and T kara Hajimaru Monogatari (Japan) (Track 1).bin to DA/YT.BIN
3. Edit export.xml and edit the lines:

<track type="audio" trackid="02" source="DA/BOSS.WAV"/>
<track type="audio" trackid="03" source="DA/YT.WAV"/>

to

<track type="audio" trackid="02" source="DA/BOSS.BIN"/>
<track type="audio" trackid="03" source="DA/YT.BIN"/>

4. Run mkpsxiso -y -c final.cue export.xml
5. Open the resulting .cue file in Duckstation to a blank screen.

Interestingly, in both cases, the .cue file mkpsxiso generates is ever so slightly different than the original.

Please find comparisons below:

original.cue

FILE "T kara Hajimaru Monogatari (Japan).bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 00 11:10:47
    INDEX 01 11:12:47
  TRACK 03 AUDIO
    INDEX 00 13:43:63
    INDEX 01 13:45:63

final.cue (using dummy wavs)

FILE "mkpsxiso.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 00 11:10:46
    INDEX 01 11:12:46
  TRACK 03 AUDIO
    INDEX 00 13:43:62
    INDEX 01 13:45:62

final.cue (using original files)

FILE "mkpsxiso.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 00 11:10:46
    INDEX 01 11:12:46
  TRACK 03 AUDIO
    INDEX 00 13:45:62
    INDEX 01 13:47:62

Just wanted to share the up2date build commands for ubuntu/debian:

apt install build-essential cmake libtinyxml2-de pkg-config
git clone https://github.com/Lameguy64/mkpsxiso && cd mkpsxiso
cmake .
make

heres my two attempts of compiling this build. any help?

PS D:\FNF-osumania-projects\PSXFunkin\mkpsxiso> git submodule update --init --recursive --remote
PS D:\FNF-osumania-projects\PSXFunkin\mkpsxiso> cmake -B build -DCMAKE_BUILD_TYPE=Release
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (3.3s)
-- Generating done (1.0s)
-- Build files have been written to: D:/FNF-osumania-projects/PSXFunkin/mkpsxiso/build
PS D:\FNF-osumania-projects\PSXFunkin\mkpsxiso> cmake --build build --config Release
[ 2%] Building CXX object CMakeFiles/tinyxml2.dir/tinyxml2/tinyxml2.cpp.obj
[ 4%] Linking CXX static library libtinyxml2.a
[ 4%] Built target tinyxml2
[ 6%] Building CXX object CMakeFiles/iso_shared.dir/src/shared/common.cpp.obj
[ 8%] Building CXX object CMakeFiles/iso_shared.dir/src/shared/fs.cpp.obj
[ 10%] Building CXX object CMakeFiles/iso_shared.dir/src/shared/mmappedfile.cpp.obj
[ 13%] Building CXX object CMakeFiles/iso_shared.dir/src/shared/platform.cpp.obj
[ 13%] Built target iso_shared
[ 15%] Building CXX object CMakeFiles/mkpsxiso.dir/src/mkpsxiso/cdwriter.cpp.obj
[ 17%] Building CXX object CMakeFiles/mkpsxiso.dir/src/mkpsxiso/edcecc.cpp.obj
[ 19%] Building CXX object CMakeFiles/mkpsxiso.dir/src/mkpsxiso/iso.cpp.obj
D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\iso.cpp: In static member function 'static int iso::DirTreeClass::GetAudioSize(const std::filesystem::__cxx11::path&)':
D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\iso.cpp:76:80: error: too few arguments to function 'ma_result ma_decoder_get_length_in_pcm_frames(ma_decoder*, ma_uint64*)'
76 | const ma_uint64 expectedPCMFrames = ma_decoder_get_length_in_pcm_frames(&decoder);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
In file included from D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\miniaudio_helpers.h:4,
from D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\iso.cpp:7:
D:/FNF-osumania-projects/PSXFunkin/mkpsxiso/miniaudio/miniaudio.h:10005:18: note: declared here
10005 | MA_API ma_result ma_decoder_get_length_in_pcm_frames(ma_decoder* pDecoder, ma_uint64* pLength);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CMakeFiles\mkpsxiso.dir\build.make:105: recipe for target 'CMakeFiles/mkpsxiso.dir/src/mkpsxiso/iso.cpp.obj' failed
mingw32-make.exe[2]: *** [CMakeFiles/mkpsxiso.dir/src/mkpsxiso/iso.cpp.obj] Error 1
CMakeFiles\Makefile2:310: recipe for target 'CMakeFiles/mkpsxiso.dir/all' failed
mingw32-make.exe[1]: *** [CMakeFiles/mkpsxiso.dir/all] Error 2
Makefile:154: recipe for target 'all' failed
mingw32-make.exe: *** [all] Error 2
PS D:\FNF-osumania-projects\PSXFunkin\mkpsxiso> cmake -S . -B ./build -DCMAKE_BUILD_TYPE=Release
-- Configuring done (0.4s)
-- Generating done (1.1s)
-- Build files have been written to: D:/FNF-osumania-projects/PSXFunkin/mkpsxiso/build
PS D:\FNF-osumania-projects\PSXFunkin\mkpsxiso> cmake --build ./build
[ 4%] Built target tinyxml2
[ 13%] Built target iso_shared
[ 15%] Building CXX object CMakeFiles/mkpsxiso.dir/src/mkpsxiso/iso.cpp.obj
D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\iso.cpp: In static member function 'static int iso::DirTreeClass::GetAudioSize(const std::filesystem::__cxx11::path&)':
D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\iso.cpp:76:80: error: too few arguments to function 'ma_result ma_decoder_get_length_in_pcm_frames(ma_decoder*, ma_uint64*)'
76 | const ma_uint64 expectedPCMFrames = ma_decoder_get_length_in_pcm_frames(&decoder);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
In file included from D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\miniaudio_helpers.h:4,
from D:\FNF-osumania-projects\PSXFunkin\mkpsxiso\src\mkpsxiso\iso.cpp:7:
D:/FNF-osumania-projects/PSXFunkin/mkpsxiso/miniaudio/miniaudio.h:10005:18: note: declared here
10005 | MA_API ma_result ma_decoder_get_length_in_pcm_frames(ma_decoder* pDecoder, ma_uint64* pLength);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CMakeFiles\mkpsxiso.dir\build.make:105: recipe for target 'CMakeFiles/mkpsxiso.dir/src/mkpsxiso/iso.cpp.obj' failed
mingw32-make.exe[2]: *** [CMakeFiles/mkpsxiso.dir/src/mkpsxiso/iso.cpp.obj] Error 1
CMakeFiles\Makefile2:310: recipe for target 'CMakeFiles/mkpsxiso.dir/all' failed
mingw32-make.exe[1]: *** [CMakeFiles/mkpsxiso.dir/all] Error 2
Makefile:154: recipe for target 'all' failed
mingw32-make.exe: *** [all] Error 2

Reported via e-mail, not checked in detail but posting here so I don't forget - reportedly repacking Tomba! (USA) comes about 150 sectors short. It could be a data post-gap or something else.

ERROR: Name entry for file 'DEBUGTEXTURE.TIM' is more than 12 characters long on line 8.

the ISO 9660 standard says this (https://www.ecma-international.org/publications-and-standards/standards/ecma-119/):

At Level 1 the following restrictions shall apply to a volume identified by a Primary Volume Descriptor or by a
Supplementary Volume Descriptor:

- each file shall consist of only one File Section;
- a File Name shall not contain more than eight d-characters or eight d1-characters;
- a File Name Extension shall not contain more than three d-characters or three d1-characters;
- a Directory Identifier shall not contain more than eight d-characters or eight d1-characters.

At Level 1 the following restrictions shall apply to a volume identified by an Enhanced Volume Descriptor:
- each file shall consist of only one File Section.

10.2 Level 2
At Level 2 the following restriction shall apply:
- each file shall consist of only one File Section

10.3 Level 3
- At Level 3 no restrictions shall apply.

Level 2 has a 31 character limit.

I can confirm that real PSX hardware can read a Level 2 ISO 9660 disk.

If I build a CD with mkpsxiso, then extract the contents to a folder, I can create a new image from that (using imgburn) including a .TIM file with 16 characters in the file name. I tried it in an emulator and the texture loaded without issues. I burnt that same image to a CDR and tried it in my real PlayStation and it loaded the texture and displayed it just fine.

CMakeError.log

When using mkpsxiso 2.00 to pack an image without specifying a license file in the XML, the first 37632 (2352x16) bytes of the generated image are zerofilled. This is not the correct behavior as only the payload section of these 16 sectors shall be zerofilled in an image without license data; the 16-byte sector header, as well as the CRC and ECC data at the end of each sector, must still be valid.

Most emulators and tools will reject the image (DuckStation) or fail to detect its format (jPSXdec) if the first sectors are not encoded correctly, even if the cuesheet lists the first track as MODE2/2352.

Steps to reproduce: output a xml file using dumpsxiso on the original CTR NTSC-U, rebuild the iso using the outputted XML, compare the rebuilt iso with the original iso.

Help doesn't mention the fact that -lba and -lbahead both require an output file as a positional argument

After repack image FFT folder MAP size increased by 1 sector. The rest of the data shifted by 1 sector.

Maybe incorrect calculation of sums of lengths of file names in a folder
In file iso.cpp in str(36) change
length += length % 2 ---> length += (length + 1) % 2

It's confusing for users, it should give a clear message indicating failure. Right now it seems to fail quietly.

After unpacking random game and packing - XA files do not match the original XA. STR files trimmed in the end.

At the following line, I was expecting a mode2form2 mode:

Don't know about other str generation tools, but the official one (mc32), leaves edc blank in mode 2 form 2 sectors. So, rebuilding a bin with the current version of mkpsxio will be recognized as a bin with errors (tested this on Megaman Legends).

XML structure for example:

<dir name="ANI">
	<dir name="PAL">
		<file name="RMPBASE.PSX" source="ANI/PAL/RMPBASE.PSX" type="data"/>
		<file name="VRMBASE.PSX" source="ANI/PAL/VRMBASE.PSX" type="data"/>
	</dir>
</dir>
<dir name="PAL">
	<file name="BRIEFIN1.PSR" source="PAL/BRIEFIN1.PSR" type="data"/>
	<file name="BRIEFIN2.PSR" source="PAL/BRIEFIN2.PSR" type="data"/>
</dir>

In result image directories "PAL" is merged in "ANI/PAL/" path, and not exist in "PAL/" path

I'm extracting "Worms Armageddon" and I'm not seeing any XML files when I run dumpsxiso through the Windows binary. I only see the extracted files in the binary's directory. I then ran in Win10-Ubuntu console too, and it output an extra error at the end about not being able to copy track start times or something (but the error was cut off), but I couldn't figure out where it dumped any of the extracted files at all, not to mention the XML file. Can I get help with locating/generating accompanying XML files?

If you use the '-s' option with dumpsxiso to extract a disc image it doesnt output the Digital Audio Tracks at all (include the output in the xml). I also ran into another issue in regards to digital audio. If if a audio track is defined but there is no DA file in the data track that referances the audio track mksxiso simply refuses to build the disc witch makes reproducing identical builds of existing games (such as MegaMan X3) impossible.