What's the best way to distribute a PSP translation patch?

Discussion in 'PSP - Hacking & Homebrew' started by jjjewel, Dec 4, 2013.

  1. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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. :wub:
     
  2. trumpet-205

    trumpet-205 Embrace the darkness within

    Member
    4,363
    542
    Jan 14, 2009
    United States
  3. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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.:wub:
     
  4. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,824
    9,718
    Nov 21, 2005
    United Kingdom
    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.
     
  5. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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. :P) so making things simple is my priority.

    I looked around for other PSP patches and they were so small. :blink: 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.
     
  6. Foxi4

    Foxi4 On the hunt...

    pip Reporter
    23,677
    21,718
    Sep 13, 2009
    Poland
    Gaming Grotto
    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. ;)
     
  7. Arras

    Arras GBAtemp Guru

    Member
    5,880
    2,713
    Sep 14, 2010
    Netherlands
    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.
     
  8. Foxi4

    Foxi4 On the hunt...

    pip Reporter
    23,677
    21,718
    Sep 13, 2009
    Poland
    Gaming Grotto
    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. :P
     
  9. Arras

    Arras GBAtemp Guru

    Member
    5,880
    2,713
    Sep 14, 2010
    Netherlands
    Nono, I meant for running on the PC to create a patched ISO in order to prevent 1.4GB patches :P
     
  10. Foxi4

    Foxi4 On the hunt...

    pip Reporter
    23,677
    21,718
    Sep 13, 2009
    Poland
    Gaming Grotto
    Oh, fair enough then. Opening up an ISO isn't rocket science on PC - it's not all that different from any other archive or image and can be done.
     
  11. Arras

    Arras GBAtemp Guru

    Member
    5,880
    2,713
    Sep 14, 2010
    Netherlands
    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.
     
  12. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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.
     
  13. StorMyu

    StorMyu "I'm too old for this"

    Member
    900
    440
    Jan 2, 2010
    France
    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.
     
  14. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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.
     
  15. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    18,692
    8,991
    Oct 27, 2002
    France
    Engine room, learning
    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

    Warning: Spoilers inside!

    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 :D


    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)
     
  16. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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. :D
     
  17. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    18,692
    8,991
    Oct 27, 2002
    France
    Engine room, learning
    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.

    I'm using this program to create/apply the patch : http://www.romhacking.net/utilities/598/

    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).
     
  18. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    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. :yay: (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.)
     
  19. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    18,692
    8,991
    Oct 27, 2002
    France
    Engine room, learning
    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.
     
  20. jjjewel
    OP

    jjjewel GBAtemp Maniac

    Member
    1,009
    293
    Dec 17, 2009
    United States
    Cyan, it's 140 MB not 400. :D 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. :lol: )

    Thank you so much for you advice and examples.:bow: