JoshuaMKW / pyisotools

python library for working with Gamecube ISOs (GCM)
GNU General Public License v3.0
18 stars 9 forks source link

Sizing alignment issues cause dvd read failures in some games #9

Open dj0wns opened 1 year ago

dj0wns commented 1 year ago

Games like Metal Arms read the iso in 80 byte chunks and pysiotools creates an iso that is not divisible by 80 bytes. This causes the game to read past the end of the iso when accessing the last block of data and causes a DVD fatal error in dolphin.

Workaround: Append X nullbytes such that the dvd size is divisible by 80.

JoshuaMKW commented 1 year ago

Thanks for telling me about this! Before we continue however, what is your current version of pyisotools (should be v2.X.Y)? I remember a bug very similar to this which I have fixed recently.

dj0wns commented 1 year ago

I pulled directly from the git to test. So 2.4.4, potentially + some commits

JoshuaMKW commented 1 year ago

Awesome. Next thing I need to know is what the non modified size of the vanilla Metal Arms ISO is, and what the size of the pyisotools modified ISO is.

dj0wns commented 1 year ago

Looking into it deeper - it looks like it is a case of adding additional files to the iso that breaks the alignment - which may be out of scope for your project.

Size of vanilla: 1459978240 Size of repacked: 1459978240 Size of repacked + 2 files: 1459978300 (+60 bytes)

The files added are large (23MB) so its likely due to additional entries in the file table? or something similar.

JoshuaMKW commented 1 year ago

Adding files itself isn't an issue, which I can verify because I use pyisotools for my own projects which add many files to the ISO. However, is it possible that with adding such large files you've managed to surpass the ISO capacity? Although I find that pretty unlikely since if that were the case, you'd probably have an ISO that is at least many kilobytes larger than usual.

Another idea, did you extract the ISO with or without positional information dumped? If you did it with positional info, it could cause problems with adding new files since the old ones are effectively "frozen" into place.

dj0wns commented 1 year ago

Although I find that pretty unlikely since if that were the case, you'd probably have an ISO that is at least many kilobytes larger than usual.

I agree this is unlikely. I replaced the files being added with smaller files (3 MB rather than 25MB) and the resulting iso was actually 32 bytes larger than before. (Also i am expanding files in the iso by more than this amount but that doesn't seem to affect anything.

Another idea, did you extract the ISO with or without positional information dumped? If you did it with positional info, it could cause problems with adding new files since the old ones are effectively "frozen" into place.

Unsure, I'm just calling "GamecubeISO.from_iso(src)" and "GamecubeISO.from_root(src)". If thats the default behavior then that may be why

dj0wns commented 1 year ago

Oh wait wrong functions, I am because extract defaults to that. Let me replace that and try.

dj0wns commented 1 year ago

Disabling dump positions resulted in no change - Still having the issue

JoshuaMKW commented 1 year ago

Alright, I'll see if I can replicate the bug and from there patch it out.

dj0wns commented 1 year ago

I can send you an example root folder if it would help - accept my discord FR