This is discussion. Not a plan.

With all those PRs pouring in (which remove legacy features or bad code), I'm wondering if it's such a good idea to even maintain extract-xiso.
Aside for creating functional ISOs for XQEMU, nothing really seems to work.

It can obviously not create redump XISO (no tool can) and it can't even extract them.

mborgerson has mentioned that extract-xiso could be replaced with a short python script - and I agree.
There's also other projects which seem to do a similiar, or even better job.

Yesterday I found myself with my redump XISO dumps and wanted to run a game on real Xbox. As I'm on Linux I had a hard time finding any software to deal with that.
I'd expect extract-xiso to support this, but it doesn't. While looking around, someone on redump IRC recommended xbiso. I've used the xbiso C++ rewrite by @thrimbor which worked just fine for extracting redump XISOs. It might work fine, but I used a custom branch which has a hack (not sure if relevant).

I'm not sure how good the code quality of xbiso is (despite having hacked together a version to export metadata about XISO in late 2017).
In my opinion we should review tools like it (what is supported? is there feature creep?) and find one which could possibly replace extract-xiso if necessary.

Thoughts?

• Should we keep extract-xiso?
• Move xbiso to XboxDev?
• New tool from scratch?
  ...

Using MSYS2, there are multiple build issues:

• Use of pthread in the FTP library refuses to build. The pthread_mutex line appears unneeded.
• Removing the above line causes the FTP library to build, but then the rest of the application to fail to build due to the following errors

C:\Users\Matt\Downloads\EmuBuild\tmp\cc65ZnMG.o:extract-xiso.c:(.text.startup+0x48f): undefined reference to `__imp_WSACleanup'
C:\Users\Matt\Downloads\EmuBuild\tmp\cc65ZnMG.o:extract-xiso.c:(.text.startup+0x5ec): undefined reference to `__imp_WSAStartup'
libftp-5.0.1.modified.by.in/libftp.a(FtpBye.o):FtpBye.c:(.text+0xe5): undefined reference to `__imp_shutdown'
libftp-5.0.1.modified.by.in/libftp.a(FtpBye.o):FtpBye.c:(.text+0x109): undefined reference to `__imp_shutdown'
libftp-5.0.1.modified.by.in/libftp.a(FtpClose.o):FtpClose.c:(.text+0x2a): undefined reference to `__imp_shutdown'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x6d): undefined reference to `__imp_gethostname'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0xf5): undefined reference to `__imp_gethostbyname'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x12f): undefined reference to `__imp_socket'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x15e): undefined reference to `__imp_setsockopt'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x17f): undefined reference to `__imp_bind'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x198): undefined reference to `__imp_getsockname'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x1ae): undefined reference to `__imp_listen'
libftp-5.0.1.modified.by.in/libftp.a(FtpData.o):FtpData.c:(.text+0x3d9): undefined reference to `__imp_accept'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x43): undefined reference to `__imp_select'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0xdb): undefined reference to `__imp_recv'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x1da): undefined reference to `__imp_select'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x26e): undefined reference to `__imp_send'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x349): undefined reference to `__imp_select'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x3d7): undefined reference to `__imp_recv'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x56a): undefined reference to `__imp_select'
libftp-5.0.1.modified.by.in/libftp.a(FtpIO.o):FtpIO.c:(.text+0x58b): undefined reference to `__imp_send'
libftp-5.0.1.modified.by.in/libftp.a(FtpMessage.o):FtpMessage.c:(.text+0x278): undefined reference to `__imp_select'
libftp-5.0.1.modified.by.in/libftp.a(FtpMessage.o):FtpMessage.c:(.text+0x30f): undefined reference to `__imp_send'
libftp-5.0.1.modified.by.in/libftp.a(FtpConnect.o):FtpConnect.c:(.text+0x37): undefined reference to `__imp_getsockopt'
libftp-5.0.1.modified.by.in/libftp.a(FtpConnect.o):FtpConnect.c:(.text+0x82): undefined reference to `__imp_WSAGetLastError'
libftp-5.0.1.modified.by.in/libftp.a(FtpConnect.o):FtpConnect.c:(.text+0x12d): undefined reference to `__imp_socket'
libftp-5.0.1.modified.by.in/libftp.a(FtpConnect.o):FtpConnect.c:(.text+0x1b6): undefined reference to `__imp_htons'
libftp-5.0.1.modified.by.in/libftp.a(FtpConnect.o):FtpConnect.c:(.text+0x1bd): undefined reference to `__imp_connect'
libftp-5.0.1.modified.by.in/libftp.a(FtpGetHost.o):FtpGetHost.c:(.text+0x36): undefined reference to `__imp_inet_addr'
libftp-5.0.1.modified.by.in/libftp.a(FtpGetHost.o):FtpGetHost.c:(.text+0xae): undefined reference to `__imp_gethostbyname'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:24: extract-xiso] Error 1

• Attempting to strip out all FTP options, including using the NO_FTP flag (which seems to be lying), the application will build, but produce different output than a Linux build of the same source.

Is there a Windows build for 2.7.1? The Appveyor links here in the repo readme are pointing to v2.5, as well as the downloads on Source Forge.

Hello, first of all, thank you for your work, the tool works wonderfully. However, I found a minor UX niggle. When extracting multiple images like so: extract-xiso.exe 1.iso 2.iso 3.iso, 2.iso and 3.iso fail with a "file not found" error, ie. only the first image specified is processed.

With some files I'm seeing an error and others are successful.
Example below.
Command:
PS > .\extract-xiso.exe -x '.\Blinx2MastersofTimeSpace.iso'
Error:
failed to extract xbox iso image Blinx2MastersofTimeSpace.iso

Worked
Tested in Xemu. Boots up to menu screen.
ConkerLiveReloaded.iso (stutter)
FarCryInstincts.iso
MechAssault.iso
ShadowtheHedgehog.iso
Failed
PowerShell returns error.
Blinx2MastersofTimeSpace.iso
MechAssault2LoneWolf.iso
Mercenaries.iso
ChroniclesofRiddickTheEscape fromButcherBay.iso

Testing by re-downloading the failed .iso files and attempting again. Will update soon.

This is a test issue for webhooks. Please ignore.

With some games there are invalid entries even in the redump ISO.
When I use xbox backup creator to get the main partition of the PAL game Burnout for example and try to extract it with extract-xiso, it hangs at the directory trafcars/models/minibus and then crashes after some time with an out of memory error.
This directory is probably the last entry as the size of the extracted files exactly matches the size when extracting the disc with xbox back creator directly from the disc.
With xdvdmulleter with the redump as well as the xbox backup creator images I get an invalid toc entry error and can't even try to extract the file.
Is there some way to ignore this error or fix it?

extract-iso's readme suggests it can create specialized XISOs for burning to optical media.

Theoretically these XISOs should be faster than straight dvd2xbox dumps, but slower than redump dumps. We do not know for sure if this is the case, or if the code that does this optimization is actually effective.

• Research existing code to understand this optimization more deeply, may be able to remove it to slim down codebase if functionality is not effective/required any more

• If feature is effective, add to readme description and detail what it does exactly.

Maybe there is a way to do this I just don't know, but if I have like 20 .iso files in the directory, is there a way to just tell extract-xiso to just rewrite all .iso's in the directory without manually specifying the names?

When you click the link in your readme, it takes you to a page that just says
{"message":"Artifact not found or access denied."}
It's probably minor; but it saves trying to compile for ourselves

There's very few cases where 2x or 4x spaces are used for indentation, when almost the entire file uses tabs.

It should be made consistent.

(Personal preference: 2x spaces / 4x spaces instead of tab)

i know only 1 dvd drive supports this but duo to "situations" in some countries, all dvd drives work here
what i do right now is making an iso and then extracting it using this tool

The code has some stubs for burning ISOs to CDs, but the code to do so isn't actually there, just some macros to stub it out. This should be removed.

This includes debian instructions, debian building, and flatpak.

like the title implies
When i try to read .iso files that are bigger then a normal DVD the program gives an error:
"... does not appear to be a valid xbox iso image"

The FTP support in this project adds significant complexity to the code, complicates project building, and provides little usefulness over just using a regular FTP client to transfer files over. For these reasons I think it should be removed.

I have two roms that failed to be extracted/converted by extract-xiso. Both contain a "!" character.

Whacked! (USA, Europe).iso
Yu-Gi-Oh! The Dawn of Destiny (USA).iso

As explained in #32 (comment), we might want to provide an option for skipping sectors / bytes.

This would lead to support for redump images.

Generally, I'm not sure if this is too helpful, and it feels like a hack.
In the linked comment, I've proposed alternatives that I have personally used in the past.

I might be doing something wrong here, but I haven't been able to fix this so not sure if it's a bug or me being stupid. Using Windows 11.

I'm trying to run a bat with a for/as adding -d ./new/ at the end, so basically extract-xiso game.iso -d ./new/. I've also tried replacing ./new/ with the full path D:\Xbox\Games\new\, and tried replacing the back slashes for forward slashes. Last but not least I saw the documentation example and tried adding the iso filename to it as a subfolder, so extract-xiso game.iso -d ./new/game.iso/. When the batch reached the end it shows open error: -d No such file or directory.

The issue is that it always extracts to the same folder extract-xiso.exe is in, instead of in the subfolder /new/.

I've created a bat with this code (I renamed the exe to !extract-xiso.exe to keep it at the top) and drop iso files onto it:

@echo on
for %%a in (%*) do !extract-xiso %%a -d .\new\%%a\
pause

And I have my folder structure set up like this:

Currently we have build instructions for macOS / Linux users but point Windows users to the AppVeyor builds.

This is great for the more common user, but if one is interested in developing/improving extract-iso it can be helpful to have build instructions.

The System Symbol was opened as 'Administrator'

and both filepaths are non-read-only:

So my question is, what else am I missing?

Is there something else, I need to do here?

Thanks

Hi.

Thank you for extract-xiso.

I get an error on a specific file when I run this command:
`extract-xiso.exe -x -d "X:\Games\MyGame" "E:\Xbox 360 Games\MyGame\MyGame.iso"

open error: filename.ext Invalid argument
failed to extract xbox iso image MyGame.iso

I think this is because filename.ext is actually longer than 42 characters, but it's not very clear.

I expected a more friendly error message indicating that the error is caused because the file is longer than 42 characters, which is not allowed on the xbox 360 file system.

Thank you.

I'm running this on the Steam Deck and I get the following error:

$ cmake ..
$ make
/home/deck/Documents/extract-xiso/extract-xiso.c:245:10: fatal error: time.h: No such file or directory
  245 | #include <time.h>
      |          ^~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/extract-xiso.dir/build.make:76: CMakeFiles/extract-xiso.dir/extract-xiso.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/extract-xiso.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Are there any other libraries that need to be installed?

Please specify in the compilation instructions in the readme that build-essential is needed for cmake to work. It's the one piece I was missing and kept getting errors without it. I'm on Ubuntu 22.04.

Been thinking about how to test an image to see if it's damaged, can't figure out any way to actually do it.

Would that be possible? Or is there another way that I just keep missing? If so, I apologize.

I get this warning when building nxdk from scratch:

CMake Warning (dev) in CMakeLists.txt:
No project() command is present. The top-level CMakeLists.txt file must
contain a literal, direct call to the project() command. Add a line of
code such as

project(ProjectName)

near the top of the file, but after cmake_minimum_required().

CMake is pretending there is a "project(Project)" command on the first
line.
This warning is for project developers. Use -Wno-dev to suppress it.

I'm not sure why yet but building in 64b mode creates a reproducible bad ISO with the "Halo 2 Multiplayer Map Pack" and "Call of Duty: Big Red One" game files (which I've ripped from my discs, verified to work on my real Xbox).

When running H2:MMP with such a faulty ISO, the game will start but it will fail to install update the game executable and report "out of space" errors when trying to install the maps. In CoD:BRO, the game will report dirty disc errors before getting to the main menu. (Fixed in #52)

In both cases, building in 32-bit mode yields a fully-functional ISO. Suggest updating CI to build in 32-bit mode until this can be fixed.

Thanks to @Ernegien for helping me debug this issue!

I want to store my game collection in the most authentic way possible (matching Redump) but that takes a lot of storage. So, I did a little bit of research and now I have few questions (and few requests) that I hope someone could help me with.

It seems to me that there are three main formats for storing a retail OG Xbox disc:

• (1) Redump ISO
• (2) XISO
• (3) Extracted files/Game Folder

I did some testing with:
Halo - Combat Evolved (USA) (Rev 2) {crc="013986d0"}
JSRF - Jet Set Radio Future (USA) {crc="b2a882df"}
Mortal Kombat - Deception (USA) {crc="007bcbcc"}

A

In the Xemu documentation it is mentioned that you can create an emulator-compatible .iso file by using either of the commands:

-with dd:
dd.exe if={redump_game_name}.iso of={output_game_name}.iso skip=387 bs=1M

-with extract-xiso:
extract-xiso.exe -r {redump_game_name}.iso

But these two methods produce different .iso files. The one created with dd.exe is much bigger.
A1- Are these two different forms of XISO or is the .iso file created with dd.exe just a trimming hack and not a proper XISO?
A2- Is what is trimmed with dd.exe the same for every retail disc (meaning we can just keep one copy to rebuild every disc with it)?
A3- What is the effect of using the two commands together?
A4- In this post JayFoxRox says that we can separate the video and game partitions and recombine them later. Also he says that the video partition is the same for most retail games. Is that true? What games have special video partition? How to separate the two partitions and recombine them to give the original Redump CRC?

If the video partition is the same for all/most games, that would mean that we can keep one copy of that partition to recreate the Redump ISO from any XISO file (saving a lot of space). The exception being the random padding that we need to find a way to recreate.

B

Extracting the files from a Redump ISO with with extract-xiso
extract-xiso.exe -x {redump_game_name}.iso
then generating a .iso with them
extract-xiso.exe -c {Folder_with_all_the_files}

gives a .iso file with a different CRC32 to the .iso file that is created from
extract-xiso.exe -r {redump_game_name}.iso

I tried to use IsoBuster 4.8 (free) on a Redump ISO. It worked for listing the LBA for the files and for extracting the game files.

IsoBuster always showed 4 partitions for the Redump ISOs:
SEP13011042
SEP13011042072
VIDEO
XBOX

and two partitions for the XISO created with extract-xiso:
"-" {it's just a dash}
XBOX

The files didn't change (I extracted again and compared) but I noticed that the some LBA for the files is different. Maybe there is something else that is different as well?
B1- Is there a program that can create/edit ISO files based on LBA information (maybe like PS3 ISO Rebuilder with IRD files)?
B2- Does this mean that we need to create files like IRD files for the PS3 (Layout files?) to be able to recreate an XISO file from extracted files?
B3- Anyone knows a program that can do that for XISO files? For Redump ISO files? (similar to Redump2IRD)

Note: I tried IsoBuster 4.7 and didn't work for me. In their release notes for 4.8 they mention {better XISO support}.

General Questions

1- Do you think we should start a database for the random blocks seeds using the tools in HERE? (even though we can't do it for all discs right now)
2- Can anyone provide the attachments from this thread?
3- Can anyone provide a compiled version of this program?

Thanks

Extracting "Amped - Freestyle Snowboarding" ISO produces an error on MacOS.

Running with LC_ALL=C produced the same result.

$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

even if I open the folder in the terminal and copy paste the program name it still says command not found

here is a text file copy of my terminal if it helps
extract xiso.txt

I have been vetting extract-xiso (32, and 64bit builds) on linux against xbfuse. I extract the redump ISO using each tool to separate directories, and then sha1 all files in the extractions.

But it appears that extract-xiso fails to see and extract a certain file from the following redump ISO:

Loaded 2581 REDUMP ISO hashes
--------------------------------------------------
 -    FILE PATH: /volume1/software/xbox/games/redump/100 Best Xbox Games Game Disc, The (UK).iso
 -    FILE SHA1: 5d1d8ddfb2c4a48eab5253bbb0888637f60efe30
 -  REDUMP NAME: 100 Best Xbox Games Game Disc, The (UK)
 - - - - - - - - - - - - - - - - - - - -
 - RUNNING extract_xbfuse(...)
 - MOUNTING...
 - COPYING FILES...
 - UNMOUNTING...
 - HASHING FILES...
 - EXTRACTION DONE!
 - - - - - - - - - - - - - - - - - - - -
 - RUNNING extract_xiso_32(...)
 - HASHING FILES...
 - EXTRACTION DONE!
 - - - - - - - - - - - - - - - - - - - -
 - RUNNING extract_xiso_64(...)
 - HASHING FILES...
 - EXTRACTION DONE!
 - COMPARING ALL HASHES...
 ---- extract_xbfuse vs extract_xiso_32
!!! HASH FILE COMPARISON FAILED BETWEEN extract_xbfuse AND extract_xiso_32 !!!

Specifically, xbfuse produced one extra file from the ISO that extract-xiso did not:

5d7cdd950e87b5feaad5072037560f860b302da0  Quantum/data/frontend/savebar/model.cmm

Based on visual inspection of the file in a hex editor, I do believe this is a real file that extract-xiso has missed. I also tried the 32 bit windows release build of extract-xiso on github and it does not list the file either:

listing.txt

Here are the sha1 hash listings which again show the file missing file between the two tools:

sha1_extract_xiso.txt
sha1_xbfuse.txt

I am not sure when I will find the time to dig into this specific case, but I hope that this issue might pique someone's curiosity, seems like a fun little bug to track down.

There's some Xbox 360 functionality.

We have to decide wether we want to keep these parts:

• The XGD3 support: might be useful for the Burger King games?
• The "$SystemUpdate" folder skip: a dirty hack and should be avoided / removed (broken anyway).

Unless it affects original Xbox, I feel that we should remove features.

Removing these features will probably prevent some users from switching to our fork, but we never test these features anyway (so they might be broken). I'd also assume that there's better tools for Xbox 360.

One negative aspect is that we might have to rebrand our fork: There's already extract-xiso in some distributions, and I doubt they'd allow 2 versions of the same tool. We couldn't replace the original tool anymore as people might depend on the 360 functionality.
If we keep these features, we could take-over those packages - the upstream hasn't been updated in more than 5 years and tickets remain unanswered.

I am trying to create a batch file to run through a bunch of ISO's in a specific directory and run extraction and then XISO generation. I have it automatically generating an extraction directory for each ISO, however when passed to extract-xiso it tells me "Permission denied" to the input path. I thought maybe it was because the path already exists, but if I don't have the path already created then it complains it doesn't exist. This even happens with a manually created path.

extract-xiso v2.7.1 (01.11.14) for win32 - written by in [email protected]

open error: F:\Xbox\Roms Conversion\Extracted\America's Army - Rise of a Soldier (USA) Permission denied

I believe this issue is a separate bug from #76. In this case, extract-xiso can 'see' the file but extract-xiso ends up creating a 0 byte default.xbe where as xbfuse produces a 1718272 byte xbe.

This could be a case of even the redump ISO being a bad rip (despite the hash matching redump's dat listing). I say that because the xbe extracted by xbfuse throws a warning in IDA about possibly being truncated, and it does appear maybe a small chunck at the end of the file is missing.

Clearly both xbfuse/extract-xiso are bit confused, but extract-xiso probably shouldn't silently fail.

Loaded 2581 REDUMP ISO hashes
--------------------------------------------------
 -    FILE PATH: /volume1/software/xbox/games/redump/Dancing Stage Unleashed (Europe) (Beta).iso
 -    FILE SHA1: d9470f190ee109ad394ed2187a5cf009725c70c3
 -  REDUMP NAME: Dancing Stage Unleashed (Europe) (Beta)
 - - - - - - - - - - - - - - - - - - - -
 - RUNNING extract_xbfuse(...)
 - MOUNTING...
 - COPYING FILES...
 - UNMOUNTING...
 - HASHING FILES...
 - EXTRACTION DONE!
 - - - - - - - - - - - - - - - - - - - -
 - RUNNING extract_xiso_32(...)
 - HASHING FILES...
 - EXTRACTION DONE!
 - - - - - - - - - - - - - - - - - - - -
 - RUNNING extract_xiso_64(...)
 - HASHING FILES...
 - EXTRACTION DONE!
 - COMPARING ALL HASHES...
 ---- extract_xbfuse vs extract_xiso_32
!!! HASH FILE COMPARISON FAILED BETWEEN extract_xbfuse AND extract_xiso_32 !!!

Listing files on windows, note that default.xbe is visible, but with a size of 1720320 bytes?

extract-xiso.exe -l ./"Dancing Stage Unleashed (Europe) (Beta).iso"
extract-xiso v2.7.1 (01.11.14) for win32 - written by in <[email protected]>

listing ./Dancing Stage Unleashed (Europe) (Beta).iso:

\dashupdate.xbe (55013376 bytes)
\default.xbe (1720320 bytes)
\downloader.xbe (1134592 bytes)
\media\ (0 bytes)
\media\ArialUni.Ttf (23274572 bytes)
\media\default.uix (1901060 bytes)
\media\dlcustom.xpr (1574912 bytes)
\media\Sound.xsb (684 bytes)
\media\stats.xsb (656 bytes)
\media\stats.xwb (190012 bytes)
\media\Wave.xwb (190012 bytes)
\music.sng (323567616 bytes)
\mv_test01.xmv (417792 bytes)
\mv_test02.xmv (487424 bytes)
\mv_test03.xmv (167936 bytes)
\mv_test04.xmv (610304 bytes)
\mv_test05.xmv (667648 bytes)
\mv_test06.xmv (258048 bytes)
\mv_test44.xmv (294912 bytes)
\sfx_g_00.thp (796672 bytes)
\update.xbe (2035712 bytes)
\VCLIP.BKT (28590080 bytes)
\xdata_bin\ (0 bytes)
\xdata_bin\x_data.bin (37050368 bytes)

22 files in ./Dancing Stage Unleashed (Europe) (Beta).iso total 479944708 bytes

Extracting files on windows, note no default.xbe is listed/printed:

extract-xiso.exe -x ./"Dancing Stage Unleashed (Europe) (Beta).iso"
extract-xiso v2.7.1 (01.11.14) for win32 - written by in <[email protected]>

extracting ./Dancing Stage Unleashed (Europe) (Beta).iso:

extracting ./Dancing Stage Unleashed (Europe) (Beta)\dashupdate.xbe (55013376 bytes) [100%]

extracting ./Dancing Stage Unleashed (Europe) (Beta)\downloader.xbe (1134592 bytes) [100%]
creating ./Dancing Stage Unleashed (Europe) (Beta)\media\ (0 bytes) [OK]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\ArialUni.Ttf (23274572 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\default.uix (1901060 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\dlcustom.xpr (1574912 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\Sound.xsb (684 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\stats.xsb (656 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\stats.xwb (190012 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\media\Wave.xwb (190012 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\music.sng (323567616 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test01.xmv (417792 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test02.xmv (487424 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test03.xmv (167936 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test04.xmv (610304 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test05.xmv (667648 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test06.xmv (258048 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\mv_test44.xmv (294912 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\sfx_g_00.thp (796672 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\update.xbe (2035712 bytes) [100%]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\VCLIP.BKT (28590080 bytes) [100%]
creating ./Dancing Stage Unleashed (Europe) (Beta)\xdata_bin\ (0 bytes) [OK]
extracting ./Dancing Stage Unleashed (Europe) (Beta)\xdata_bin\x_data.bin (37050368 bytes) [100%]

22 files in ./Dancing Stage Unleashed (Europe) (Beta).iso total 479944708 bytes

A 0 byte default.xbe is on disk after this extraction.

Based off a good catch from @mborgerson here: #20 (comment)

The version command of extract-xiso (-v) is out of date as it is just hard-coded into the source.

Ideally this should be set by the current repo's tag/branch, or the current commit hash (and maybe dirty status?).

Having versions/commit hashes can aid with debugging user issues, especially as we now ship compiled binaries.

The VS Solution files are a hassle on the Makefile is overly complicated. Let's dump both and just use CMake.

Maybe someone can help me here. I would like to keep the folder structure of my collection and ideally use a script that allows me to adjust all my files under Windows bulk.

My folder structure looks like this:

roms / xbox / GameA / GameA.iso
roms / xbox / GameB / GameB.iso

Is that possible somehow or do I really have to enter the source and destination manually via cmd?

We should upgrade this repository with README.md and probably remove the old README.txt.
Hardly anyone will ever care about the full changelog (it will still be in git history anyway).

After some testing, we aren't sure extract-xiso is applying any Allowed Media patching. We tested with or without the -m flag and get the same results for both. And those results seem to suggest that no patching is being done, either way.

After comparing to other known Media Patcher's default.xbe against extraxt-xiso own version and according to Rocky5's eagle eye using vbindiff and dx-dexbe-0.5.fixed etc. it would seem something is awry.

It should be noted that we tested in rewrite mode only i.e. no testing was done in create mode. The docs state that it should be available in both, however.

    -m    
          In create or rewrite mode, disable automatic .xbe
          media enable patching (not recommended).

This project should have continuous integration setup (e.g. travis/appveyor) to verify build success and to provide pre-built versions.

I'm using "Rewrite xiso(s)" (-r) for my script as it's convert redump xiso to regular xiso on the fly.
The script also create a new sanitized filename that follow FATX limitations.
But the -r option doesn't have [name] option as -c, also it's renaming the original xiso by adding "*.old" extension.
So now, here's what the script does:

1. Rewrite redump xiso to regular xiso.
2. Rename the output xiso to sanitized filename.
3. Rename the input xiso to its original filename.

It would be nice if the script just need to rewrite to output with custom filename.

When attempting to create an image using 64-bit builds on Windows, the program silently exists after printing "generating avl tree from filesystem" 32-bit builds work as expected.

This behaviour was seen with PR #13 using Visual Studio 2017.

Edit:
This behaviour is caused because extract-iso implements the dir->handle field as a long, which on Windows is always 32-bit wide, however, _findfirst returns intptr_t, which can be 64-bit long, this causes the high bits of the returned handle to be discarded.

Hello,
I am trying to figure out, how to properly rewrite into a specific directory:
extract-xiso.exe -r "D:\Temp\game.iso" -d "D:\Games\Xbox"
This will write into the source directory "D:\Temp" and gives following error at the end:
open error: -d No such file or directory
In the help it is said, but something is missing here:

-d <directory>      In extract mode, expand xiso in <directory>.
                    In rewrite mode, rewrite xiso in <directory>.

Any hint is appreciated.

Anyone know a batch script/command to extract a bunch of folders?

Hello alll,

I don know if I missed something, but these are the steps I followed:

Clone Repo

git clone https://github.com/XboxDev/extract-xiso.git

cd into directory

cd extract-xiso

Create working directory

mkdir build
cd build

Build project

cmake ..

make

I attach the generated content (zipped) by the cmake command:
build.zip

Honestly, I'm confused, and don't know what else I need to do, in order to proceed,

Please, let me know, if you need anything else to proceed.

Thanks