I'm helping my friends with a PSP translation project but everyone in our team is a noob when it comes to PSP patching. T_T So I'm looking for a convenient and easy way to create/apply a translation patch, something that's easy for me to make a patch, and easy for my friends to apply the patch to their ISO file.
For the current game I'm working, there are only 2 files that need to be changed. One decrypted Eboot.bin (about 4 MB) and one decrypted PGDfile (about 300 MB).
The original ISO is about 1.7 GB and the modified ISO is pretty much about the same size. I tried creating a patch with XdeltaUI but the xdelta patch itself is 1.4 GB. So I think xdelta is not the best choice here. (Plus it took so long to make a patch and it'll be a pain to upload the patch. And it is still a beta patch, so we'll have to upload/download many revisions of it.)
Should I ask my friends to download UMDGen and then I upload the new Eboot and PGD files for them instead? Or are there any other ways I should try?
P.S. Is uploading Eboot and PGD files okay on most game forum like GBATemp?
P.S. 2 How likely is it that a modified ISO that works on PSP emulators won't work on the real PSP? (I don't have a PSP and I'm using JPCSP and PPSSPP to test the translation patch.)
Thank you very much.
EDITED: Found the method Cyan suggested in this reply to work best for me. So, problem solved. Thanks so much.
Thank you, trumpet-205. But my project is non-English (and it's a language that PSP doesn't support and it doesn't use English font.) so that might not work. But I'll try to read some more about it. Thank you very much.
You seem to have run into the first major problem and that is
1.4 gigs is a bit strong for an eboot/binary the is but a couple of megs and what I guess is an archive file that is nowhere the near the balance (nor has it had enough data changed to represent 300 megs worth). To this end xdelta appears to have failed to pick up a thread where it left off and just assumed it was a big change. You might be able to fiddle with an option but in reality it will probably fail again as will its normal competitors in BSdiff (not to mention it has issues with files as the get bigger in its windows port). You could try the Beat patching system http://www.romhacking.net/utilities/893/ but you will likely face similar issues there.
The other side of this is you never know what the end user will have done as far as CSO and relinking (if it is a relatively unplayable title without knowledge of the original language you might be luckier) and even though it is just a few gigs you could face fun telling people to get an original copy.
To that end yeah it is probably best to find a command line means to extract and build a PSP iso and attack the files on an individual basis before rebuilding the iso or injecting the files back in. I have not really had cause to find a command line iso extraction tool for the PSP but if memory serves it is a fairly standard iso format underneath it all. If you reckon your friends can handle a few clicks with umdgen or something (and it is usually fairly obvious things you will want them to do) then by all means go for that.
Uploading the files. Afraid not. It still contains the property of the company that owns the game. Along with distribution size they are the main reasons for using patches in the first place. Excerpts and samples are tolerated for discussion in a lot of places but whole files are a bit much and are more like smacking the bear upside the head than poking it.
Emulator vs console accuracy. By all accounts the PSP emulators are not the most accurate, however they are typically not inaccurate in the way certain SNES emulators might be inaccurate. Suffice it to say though I can see memory issues arising in some instances it is far more likely to be that whatever rebuild tool you are using did not make a proper header or something. You will probably know when you are starting to play fast and loose with instructions, timings and memory management though.
Thank you, FAST6191. The PGD file contains all the background music and stuff, so it's big. Plus, it's decrypted, so the content is totally different from the original file. (For other games that I checked, they packed the whole audio files along with the dialog text. The files are much bigger than this. 400 MB+ are pretty common. Some are as big as 1 GB.)
Anyway, I probably won't try anything complicated. This is a game for girls and I think 100% of people who will use this patch will be girls (or maybe a few curious boys. ) so making things simple is my priority.
I looked around for other PSP patches and they were so small. Maybe it's because of the way the games stored files?
If anyone has any different ideas of how to distribute patch, I'd like to check them out.
There are practically two ways of patching games on the PSP - either injecting the translated text or audio files in real-time using a plugin which has the added benefit of being easily updatable, but arguably more difficult to pull off since it requires developing a plugin or providing the user with a patch that can be applied with an external patching application which is much easier, however cannot be easily updated. Both methods were forementioned, I just thought I should underline the benefits and drawbacks of those two.
There are practically two ways of patching games on the PSP - either injecting the translated text or audio files in real-time using a plugin which has the added benefit of being easily updatable, but arguably more difficult to pull off since it requires developing a plugin or providing the user with a patch that can be applied with an external patching application which is much easier, however cannot be easily updated. Both methods were forementioned, I just thought I should underline the benefits and drawbacks of those two.
I think injecting the translated text (at least, with the Project Diva Extend plugin) only works if all the text you have to replace is in the EBOOT.BIN file though.
Maybe it would be possible to write a script that extracts the files from the ISO, patches them individually and then rebuilds it? I'm not sure whether there's a command line version of UMDgen or something similar available.
I think injecting the translated text (at least, with the Project Diva Extend plugin) only works if all the text you have to replace is in the EBOOT.BIN file though.
Maybe it would be possible to write a script that extracts the files from the ISO, patches them individually and then rebuilds it? I'm not sure whether there's a command line version of UMDgen or something similar available.
Pretty sure you don't have to rebuild the ISO in real-time - whatever assets are used by the game have to be loaded into RAM where they can be modified with a plugin if that's your intention - that's how AR codes work after all.
Pretty sure you don't have to rebuild the ISO in real-time - whatever assets are used by the game have to be loaded into RAM where they can be modified with a plugin if that's your intention - that's how AR codes work after all.
I know that, but I'm not sure whether UMDgen does any special header patching magic or something that would not be there in a regular ISO. If it doesn't though, doing this would probably work as a small noob-friendly patching method.
Thank you Foxi4 and Arras.
I'm not going to write a program myself, though. That will be too difficult for me.
I'm looking for existing programs that might work better than UMDGen or Xdelta patchers. Or other programs that can make patch distribution a little easier.
Unless you do it yourself you won't find better. As FAST suggested, your own program to open/patch different file will be a lot more efficient than the whole iso. You can even call xdelta from your program it's not that big of a deal.
I don't know if I'm capable of writing such a program myself, but in the end we'll deal with decrypted v.s. encrypted files which I think I can't simply patch just small parts of them anyway. (Like where the files are located and the file sizes and stuff won't be the same in the original and the modified file. So I'll need to replace the whole big files anyway.)
Well, I'm not quite sure I got the concept right. I'll study some more. Thanks so much, Stormyu.
ChepChep had the same problem with his La Pucelle translation patch.
but when I did the patch myself on the uncompressed ISO (not cso), I got 1.58MB xdelta patch.
He asked me how I did it, so here is the explanation I gave him in PM
To make a small patch, the difference between both ISO have to be very small, so you need to keep the file's position and order as much as possible.
When you add a file, the file's positions are modified and use random order, so when you compare the two ISO you have a very big .xdelta file (330MB).
To keep the unchanged files in their original place and order, you need to export the LBA before modifying the ISO :
UMDGen > File > File list...> Export...
save as .txt
now you change the ISO, replace files, etc.
Before saving the new ISO, you choose File> File list > Import... > import the Original ISO's file list.
It will ask you if you want to Force the original file's position stored in the .txt, reply yes.
Save the new patched ISO as uncompressed .iso (don't remove/compress the dummy file, you have to keep the new iso as much identical as possible as the original).
It will fail because there are LBA conflicts. You will have to edit the Filelist.txt manually to resolve conflicts. (I don't know any program to do it manually, maybe it exists as I'm sure other translation team had to do it too).
When you save the ISO, it tells you :
"SCRIPTPACK.dat LBA starts at 0185088, but next free LBA is 0185139"
It means START_JP.LZS is now bigger than the original, so it takes more sectors in the ISO. You need to edit the .txt file to tell ALL the files located after this file to start a little further.
new SCRIPTPACK.DAT - old SCRIPTPACK.DAT = 51 LBA difference (your new STARTJP is 51 LBA bigger than the original)
but the difference with old NSAVEICON - new NSAVEICON is only 48 LBA
So I thought it might be a bad idea to increase 51 to ALL following LBA.
Doing that would move each files to 51 sectors, adding empty LBA and make a bigger patch.
The best method is to find the real next available LBA in the ISO.
I guess there are different methods:
Method1:
You can find the real next free LBA by letting the program tell you what value to use. Edit the .txt, reimport, etc.
Method2:
You can calculate how much LBA each original files are using (how big the file is, in LBA instead of MB), and add that size to all the new LBA, one by one.
Method3:
give a fake LBA value to all the files (bigger than the known current file's LBA), and let the program tell you which is the next free LBA.
I think Method3 will be easier/faster/produce smaller patch size. But, I'll have to test. I thought about it only today.
What I did:
I started with Method1:
Edit the filelist to replace the starting LBA from 0185088 to 0185139 (the next available LBA).
Re-import the filelist, Force alignment, Save the iso again, and you will find the next conflict, with the next available LBA address.
NSAVEICON.PNG starts at 0186336, but next available LBA is 0185384
replace 336 to 384, import again, save the iso to find next conflict/next free lba.
This time, it's a little different: there are two files with "384", making a real conflict.
Method1 doesn't work anymore.
So, I went with Method2:
I calculate the LBA difference (file size) manually for all files one by one, and add LBA size to the new LBA.
import the file, save uncompressed iso.
Now you can use Xdelta to create the path for the full iso.
I didn't detailed Method3, but Method 2 should be enough.
Your friends will have to use the original ISO to apply the xdelta patch.
They can then convert it to cso if they want, but they will have to keep the original iso for future patch releases.
It could be not well explained, or wrong. It's only the way I understood it myself. It's the first time I create a patch for PSP.
I hope you don't have a lot of files. La Pucelle have less than 20 files so it's easy to do manually.
Making a program to translate the LBA offset in a txt file is probably easier than making your own patching program.
If you make one, please share it
An idea to make the program to auto-re-LBA:
let the program open both the .txt with the LBA references and a folder with All patched files.
The program will check all the file sizes and determine how many sectors are needed for them, compare the original LBA position, and edit them based on the new file's LBA sizes (how many sectors they need).
not all files need to be moved (for example, in La Pucelle, the new bigger eboot.bin doesn't affect the next LBA position because it fit in the same sector).
I don't know the technical side, but I suppose 1 LBA = 1 sector = 2048 (mode1) or 2352(mode2) bytes/sectors ?
1 sector can hold only 1 files? or can a sector contains the end of file1 and start of file2? (I'll have to read ISO 9660 specs)
Thank you, Cyan. I gotta go out today so I won't have time to test it now, but it looks promising. I'll test your method once I get back and will report here how it goes.
There are few different GUI and xdelta version. Always use the same one, as I've (and other users too) experienced incompatibility if not using the correct version used to create the patch.
For the technical detail about creating the patch:
xdelta is checking 8MB ahead of the current position to check if data were added/inserted/changed etc.
if your patched files are bigger than the original by 8MB or more, you'll have to use the command line to give a user defined buffer size.
http://www.romhacking.net/utilities/928/
This page gives a command line with a buffer VERY big (the game's ISO size), so it checks all files moved around the entire iso and is supposed to produce a small xdelta, even without reimporting the LBA.
I didn't try, I think reordering the files like the original release is better (but it's my own preference, and I don't have a 64bit OS to set buffer this big).
Cyan, I just tested importing the original UMD filelist when I saved my new ISO and could bring the xdelta patch size down from 1.4 GB to 140 MB. (I also used XdeltaUI for the patch.)
Luckily, there are only 2 files I need to repack. One decrypted Eboot.bin around the beginning of the ISO which is smaller than the original file and one decrypted PGD (.DNS) that is bigger than the original file, but it is the last file in the list. So when UMDGen repacked it, I didn't encounter any pop-up error message.
Anyway, I got curious so I ran another test with a random game with decrypted file in the middle of the list. And I understood what you mentioned about editing the LBA sizes. For this issue, I think using spreadsheet should be fast enough. I calculated LBA size with filesize/2048 and rounded up the number. Then added the difference (New LBA-Original LBA) to the files down the list. (Most otome games that I have packed files in .cpk or .img so in general, there are only a few files that need to be edited.)
Edited: Hm... I re-read your early post and yeah, adding the difference to the other files might not be a good idea. But I can't think of a way to optimize that for now. (Most games I have stored text in USRDIR and it's usually around the bottom of the list, so it doesn't seem to be a problem.)
You are lucky, the file you changed is the last one !
400MB is still a big patch, but you can't do anything about it.
As it's the last file, I think you didn't had to change the xdelta buffer size.
But if the file was in the middle of the ISO, the patch could have been bigger, from start of the difference to the end of the iso.
Making a buffer newfilesize+8MB should have suffice to make the 400MB patch, I think the 1.8GB buffer is a little exaggerated.
If you create a tool to calculate the new LBA, let me know
Checking real file size instead of adding previous file's LBA difference will prevent empty blocks. but I think the game will work even if you add empty block, it will only produce a bigger patch.
Cyan, it's 140 MB not 400. So it's not so bad. Plus the current big size is probably because I used uncompressed cpk file for the new ISO instead of compressed file like the original. (Just read from other threads that some games had problem running on the real PSP if you use uncompressed cpk file. I'll have to ask my friends to test that.)
I'll think about a program to recalculate LBA when I'm a bit more familiar with it. (I'm still not quite sure I understand it. I'm just happy I can make a smaller patch now. )
After a couple days of Nintendo releasing their 18.0.0 firmware update, @SciresM releases a brand new update to his Atmosphere NX custom firmware for the Nintendo...
Today, April 8th, 2024, at 4PM PT, marks the day in which Nintendo permanently ends support for both the 3DS and the Wii U online services, which include co-op play...
Hello, GBAtemp members! After a prolonged absence, I am delighted to announce my return and upgraded form to you today...
Introducing tempBOT AI 🤖
As the embodiment...
With Apple having recently updated their guidelines for the App Store, iOS users have been left to speculate on specific wording and whether retro emulators as we...
Yet another casualty goes down in the never-ending battle of copyright enforcement, and this time, it hit a big website which was the host for many fangames based and...
The highly popular and accurate FPGA hardware, MisterFGPA, has received today a brand new update with a long-awaited feature, or rather, a new core for hardcore...
The time has finally come, and after many, many years (if not decades) of Apple users having to side load emulator apps into their iOS devices through unofficial...
The romhacking community is always a source for new ways to play retro games, from completely new levels or stages, characters, quality of life improvements, to flat...
A new Nintendo Switch firmware update is here. System software version 18.0.1 has been released. This update offers the typical stability features as all other...
Retro handheld manufacturer Anbernic is releasing a refreshed model of its RG35XX handheld line. This new model, named RG35XX 2024 Edition, features the same...
Today, April 8th, 2024, at 4PM PT, marks the day in which Nintendo permanently ends support for both the 3DS and the Wii U online services, which include co-op play...
Hello, GBAtemp members! After a prolonged absence, I am delighted to announce my return and upgraded form to you today...
Introducing tempBOT AI 🤖
As the embodiment...
After a couple days of Nintendo releasing their 18.0.0 firmware update, @SciresM releases a brand new update to his Atmosphere NX custom firmware for the Nintendo...
With Apple having recently updated their guidelines for the App Store, iOS users have been left to speculate on specific wording and whether retro emulators as we...
The time has finally come, and after many, many years (if not decades) of Apple users having to side load emulator apps into their iOS devices through unofficial...
Nintendo might just as well be a law firm more than a videogame company at this point in time, since they have yet again issued their now almost trademarked usual...
A new Nintendo Switch firmware update is here. System software version 18.0.1 has been released. This update offers the typical stability features as all other...
Yet another casualty goes down in the never-ending battle of copyright enforcement, and this time, it hit a big website which was the host for many fangames based and...
The highly popular and accurate FPGA hardware, MisterFGPA, has received today a brand new update with a long-awaited feature, or rather, a new core for hardcore...
Nintendo has recently announced through their social media accounts that a new Indie World stream will be airing tomorrow, scheduled for April 17th, 2024 at 7 a.m. PT...
) so making things simple is my priority.
