PS3 XForge PS QRC Tool - Modifying aspects of the XMB is now easier then ever.

We have seen many XMB visual mods published so far in the lifetime of the PS3 but the QRC format (a type of container) has been always problematic, tricky, and very restricted. XForge is intended to solve all this problems once for all, it allows full freedom to rebuild the QRC files and modify all his contents

There are many files inside the QRC containers that are candidates to be modified, XForge is the first tool that allows to modify them in a "noob friendly" way, everything made from a intuitive interface with preview panels

Say goodbye to the previous manual methods that required dealing with zlib compressed files or injecting them with a hex-editor to create a custom wave, to replace XMB main icons, to change background wallpapers, etc... XForge supersedes all that tutorials, manuals methods, and tools, there is a long list of features supported by XForge, for more detailed descriptions see the feature list below​

-@sandungas​

Download: XForge​

Feature List_________________________________________________________________________________________

• All QRC file types supported (QRCC and QRCF)
• ZLIB compression and decompression transparent management (no user interaction needed)
• Individual extraction/injection of files of any size
• Full extraction of all files, using an additional xml control file for rebuilding purposes
• Full rebuilding from the xml control file, generates QRC files identicals to the originals
• QRCC to QRCF, and QRCF to QRCC conversions, generates files identicals to the originals
• Build custom QRC files 100% from scratch, or adding/removing files from the officials
• Several display panels: FileList (all types), TextViewer (MNU, TXT, INI, PATH), ImageViewer (BMP, JPG, TGA, DDS), HexViewer
• Compatibility with sce-cgcdisasm.exe (tool not included in XForge releases) to dissassemble FPO and VPO files on the fly
• Syntax highlighting in the TextViewer for MNU, TXT, INI, PATH (and optionally FPO and VPO)
• MD5 hash info of QRC files and all his file contents, with identification of official files (initial support)
• Advanced QRC internal structure file info (for debugging, development or research purposes)
• Optional custom file extension system icons for QRC.ico and QRCF.ico
• Optional custom file extension renaming at extraction time
• Extensive drag and drop features - Drag files into XForge from Windows explorer, and out of XForge to Windows explorer.
• Ability to open 2 or more XForge instances with different QRC's and drag-and-drop files between them.
• Double click files on filelist to open them in your preferred editor application that's associated with that file type
• Compatible with Microsoft Windows XP onwards (requires .Net framework 4.0)

[TABLE STYLE=class:prefix prefixBlue, border-width:0px, width:100%][TR][TD]Screenshots_________________________________________________________________________________________[/TD][/TR][/TABLE]
System icons

MNU, TXT, INI, PATH viewer with syntax highlighting

FPO/VPO viewer and dissassembler with syntax highlighting

BMP, JPG, TGA, and DDS imageviewers

Hexviewer

Videos________________________________________________________________________________________________

[TABLE STYLE=class:prefix prefixBlue, border-width:0px, width:100%][TR][TD]Tutorials______________________________________________________________________________________________[/TD][/TR][/TABLE]

Full build Individual file replacements QRC/QRCF direct conversions

• 
  This building method is inspired by rcomage, at extraction time XForge generates a XML control file for rebuilding purposes (located at root of the extraction path). The QRC file is built by loading the XML control file
  
  1) Open the QRC file with [File]>[Open]
  2) Extract all contents from the QRC file with the option [File]>[Extract All]. This will create a control XML file
  3) At this point you can modify or replace all extracted files
  4) Build the new QRC file by using the control XML file with the option [File]>[Open]
  
• 
  This method allows to replace individual files by using the buttons in XForge interface
  
  1) Open the QRC file with [File]>[Open]
  2) Extract files individually with the button [Extract File]
  3) Replace files individually with the button [Replace File]
  4) Save QRC file with the button [Save QRC File]
  
• 
  This is a direct conversion in between QRC and QRCF
  
  1) Open the QRC/QRCF file with [File]>[Open]
  2) Convert the file with [Tools]>[Convert]>[QRC to QRCF] or [QRCF to QRC]
  

Credits, History, and Changelog________________________________________________________________

Credits History Changelog

• 
  First our team
  @pink1 Programming & development, research of the qrc format
  @sandungas For texting, icons/images, research of the qrc format & development consulting
  @DeViL303 For getting the team together with the idea of making the app, researching modding the qrc, texting & development consulting
  @Berion For texting & development consulting
  I can't thank these guys enough for all of the time and energy they put into this.
  
  We'd like to give credit to all of the other developers and members from over the years who have helped in any way.
  
• 
  Working with @sandungas @DeViL303 & @Berion over the past few weeks we have been able to make a few good jumps with the ps3 QRC file(mainly the earth.qrc).
  
  1. First we were able to replace files the same size or smaller(cool but not really new).
  2. After looking at the wiki for awhile we thought why not try editing the TOC (we know all of the values from the work of the amazing guys that reversed the format). This worked! We were able to expand the size of the files inside of the qrc.
  3. After playing with that we decided to try extracting the qrc to a folder then building a new one from it. To do this we also create a xml file with the a list of the qrc files in the order they are inside the qrc.
  4. This xml is used to build the new qrc. We have two spaces for each file first we have the source file then we have the id(the name in the qrc). By editing this file we can build a custom qrc only needing to extract & then build in the program after editing.
  5. Specific imageviewer preview modes for the special DDS file formats (mimicking the look of PS3 XMB)
     
  6. Specific textviewer syntax corrections for problematic files (EOL windows to unix conversions, standarization of control characters)
• 
  Initial release
  

 

Btw @LuanTeles there is something you should try now that you are playing with this

The problem we have by applying the math calculations we mentioned before... is the original images have an aspect ratio of 2:1
But the screen of most people is 16:9

As you can see there is an small distortion applyed to the originals... is just the originals are degrades of colors, and the XMB is "softening" them.. so the result is ok
But if you try to replace them by a photo (lets say from a landscape) then is going to be distorted and will look bad

So... the challengue is to find the values of width and height to preserve the 16:9 aspect ratio

 

128x64 works fine.
192x96 works but will not load the XMB.
256x128 works but will not load the XMB.
640x320 black screen

Try with this sizes (all them preserves 16:9 aspect ratio)

64x36
80x45
96x54
112x63
128x72
144x81
160x90

 

Try with this sizes (all them preserves 16:9 aspect ratio)

64x36
80x45
96x54
112x63
128x72
144x81
160x90

I will try

i'm using 128x72

I need to dome the particules to stay where they stays in ps5.

 

@sandungas i don't know if it is nice or not, the particles will get off screen. after 30 seconds and them i need to shake de DS3 to get them back.

 

i'm using 128x72

So 128x72 works fine ?, this is what you are using in the video ?

@sandungas i don't know if it is nice or not, the particles will get off screen. after 30 seconds and them i need to shake de DS3 to get them back.

I dont understand how the size of the DDS files could affect the particles
Maybe is because the shaders that generates the particles have some value related with the wallpaper sizes, dunno

 

So 128x72 works fine ?, this is what you are using in the video ?

I dont understand how the size of the DDS files could affect the particles
Maybe is because the shaders that generates the particles have some value related with the wallpaper sizes, dunno

Oh Sorry, i was using 128x64px

but it gave me black screen after replacing all dds with the 128x64 ones, maybe file size limit?
it was 380Kb.

Replacing just one of them works just fine.

So i reverted all of them back to 64x32 and i got it working again.

 

Oh Sorry, i was using 128x64px

but it gave me black screen after replacing all dds with the 128x64 ones, maybe file size limit?
it was 380Kb.

A size restriction i guess :/
But it should be mostly like a size restriction in memory

Oh Sorry, i was using 128x64px

Ok, then mistery is unsolved yet

The reason why i mentioned that is because the original images are aspect ratio 2:1 (and all the others you was using) If you draw a circle in them and you display them in XMB the circle is going to be streched vertically and it will look like an oval

That distortion effect is an annoyance, and it happens in all OFW, CFW, HEN, etc... is just the original images are degrades of colors and when you distort a degrade the result is... ok
Nobody is going to realize that there is a distortion in the degrade, so it doesnt matters, but is a restriction in the amount of design styles we can use in them
In other words... we can only use degrades of colors because is the only design style that is going to resist well the distortion

With the other sizes i mentioned that respects the 16:9 aspect ratio that distortion dissapears so we are removing that restriction, if you draw a circle in them it will look like a real circle in XMB

 

Here is a simple little tool I made to make modding PS3 QRC overrides/presets easier. It allows you take any of the sets of QRC override files called MNUs, and copy them to all available presets in any given QRC.

So lets say you are sick of your wave changing colour from when you boot up to when the XMB loads, or when you go into the music player, or you really like a specific camera angle in the Gaia visualization, or you always want the canyon.qrc to show a specific style of visualization always and not be changing randomly. Then this is the tool for you.

What you do is extract your qrc file to a folder with Xforge, then drop the MNUs for the preset you want to force into a "preset" folder next to the extracted QRC. Here is an example showing canyon.qrc.

1. Prepare your folder like this

2. Place the MNU override files you want to use into the preset folder:

3. Click the bat and then choose canyon.qrc from the list. You can use your mouse OR use your arrow keys and enter:

4. Then choose "Force Always" after verifying you have your files arranged correctly:

5. It will then take the MNU files inside the "preset" folder and copy them to all the available override sub folders in the QRC, in the case of canyon.qrc that is 57 copies of each MNU:

6. Now repack the QRC file with Xforge and it will always stay on the preset you chose.


I call it PS3 QRC Preset Forcer lol. It's just a simple bat with copy commands but can save a lot of time for QRC modders. .

I used it along with Xforge to build these 57 different canyon.qrcs, Each one is forced to stay on a specific preset by making all the presets the same.

 

Little thing I noticed while doing these mods, not every qrc works with the same rules.

For earth qrc you can actually delete any presets that you would not like to show and it just figures it out and will only show the ones that exist in the qrc. However with canyon.qrc it works differently, if you remove presets from canyon.qrc it still tries to use them all and just shows a black screen whenever it finds a missing preset. It does not freeze or anything, just shows a black screen for the duration of that preset.

Another thing that kind of pissed me off is that earth.qrc and lines.qrc seem to show the exact same thing every time. So it's not like there is some random number generation is going on that makes it never show the same thing twice. They are actually more like a video file being played in the background. It just generates the same thing every time based on static code.

However canyon.qrc is truly random due to the way the music affects it, so it will show a different visualization for every track you play even if on the same preset. This makes canyon.qrc superior for me as a visualization.

 

Sorry to randomly butt in here, but is that a modified version of the Debug info in the bottom right corner?

 

Sorry to randomly butt in here, but is that a modified version of the Debug info in the bottom right corner?

Yes, its easy to mod that by hex editing the DEX xmb_plugin.sprx.

 

Yes, its easy to mod that by hex editing the DEX xmb_plugin.sprx.

That's good to know, thanks for the heads up.

 

Im thinking in a couple of feature requests and im going to write it before i forgot about it

The first idea is inspired by psarc.exe is used for size optimization, it works this way (im going to simplify it for the matter we care):
1) reads the names of all files
2) compresses all files
3) finds the compressed sizes of all files
4) calculates the hash of all files
5) compares the hashes of all files to identify the "dupes"
6) creates a TOC for all compressed files, where the entries of the "dupes" are redirected to the same offset

This is the same kind of "file relinking" i was doing with the help of a python script made by flatz and applying the patches in the .qrc with a hexeditor (before xforge existed)
Is just we was doing it for experiments (relinking different files), and because we didnt had better ways to do some of the experiments

The difference in what im suggesting now is to do this identifycation of the "dupes" always (in psarc.exe is optional, but for .qrc we should do it always), for all file formats (not only .mnu settings but image formats too, etc...), and relink the identical files
It could help eventually when someone just "copypastes" .mnu settings in between several "overrides" directories, also, as far i remember there are some official .mnu files copypasted by sony
This feature is going to identify all the dupes, no matter if are official or custom, and at the extraction time is going to extract them as dupes too, so no problemo

Lets say... if you try to create a .qrc with 2 identical files xforge is going to reallize that are dupes and is going to store only 1 copy of the file inside the qrc. If you extract the contents of that qrc, the single file that was stored as a dupe is extracted as 2 identical files... and if you create another qrc with the extracted contents the 2 files becomes 1 file... and so on... Is like magic made automatically in a way that is "invisible" for the user, everything looks normal, but the tool is doing some smart shit in the background

-----------------------
The other feature request is to store the MD5 of the extracted (and zlib decompressed) files individually in the XML control file, as an additional attribute (in first position, for a better alignment, because an MD5 always have the same lenght)

<file md5="D9EF49925392C199ED582C2BBA2D0CA3" src="BACKGROUND.mnu" id="BACKGROUND.mnu" compression="False"/>

The purpose of the "md5" attribute is a requirement for more advanced features that could be implemented later, remember we was talking about some ?, are features dependant of info databases containing the md5 for all files inside all qrc files from inside all PS3 firmware versions

Actually, i would like to add also into the XML control file the MD5 of the .qrc this way:

Spoiler

Incase the md5 of the qrc doesnt matches with any entry in the databases the value of "id" should be "unknown"

<?xml version="1.0" encoding="UTF-8"?>
 <db md5="261CD31A2516EF85A6D3B584C9BD02C5" id="lines_460_487.qrc" 
 <qrc compression="True" attributes="2" >
	<file-table>
		<file md5="D9EF49925392C199ED582C2BBA2D0CA3" src="BACKGROUND.mnu" id="BACKGROUND.mnu" compression="False"/>

The actual Xforge version already contains a database with the MD5's of all qrc files from all known firmware versions, so is easy to add this md5 to the XML control file when we extract his contents
What we dont have are the databases with the MD5's of all the files extracted/deompressed from inside all the qrc files from all firmware versions
Btw, is needed to make this databases as "external files", easy to edit to keep them updated, and is needed to think in a "format" for the database files (i guess using xml would look tidy)

The other MD5's that needs to be calculated "by file" is something not made by XForge yet... but the first feature request i mentioned, about identifying the "dupes" requires to calculate a hash of all the files... and well... you already have MD5 support implemented, so long story short...
It looks it could be handy to calculate MD5 of the files decompressed/extracted from a .qrc (to create info files for the databases), and also when creating a .qrc (to identify dupes)

 

I'm having trouble with icontex.qrc

When i open a fresh icontex.qrc and extract the icon and replace it with the same icon, it gives me an error

 

Btw @pink1 the download link is down

 

Btw @pink1 the download link is down

Thanks for letting me know. I'll get it fixed as soon as I get a chance to get on my computer.

 

Does anyone have a copy of the zip so I can get this back uploaded. I got a new computer awhile back and I seem to have missed some stuff.
I still have it all it's just in storage

 

@pink1 can support for coldboot.raf be added? we still need to make it manually, would be nice if it can show the animation script too.

The tools for colored coldboot does not allow us to add animation due to the lack of the animation script.

 

@pink1 Do You have in mind this application or src? I'm not sure if I have source but for sure the binary in my backup.

 

Does anyone have a copy of the zip so I can get this back uploaded. I got a new computer awhile back and I seem to have missed some stuff.
I still have it all it's just in storage

I dont have the original release, i was decompressing them in the same folder (i was using it as a "work directory" for the tests), and that folder is named "XForge_Dark_RC1_public"... so im not sure if are good for a re-release, i was messing them a bit :/ (and now im regreting)

@pink1 can support for coldboot.raf be added? we still need to make it manually, would be nice if it can show the animation script too.

The tools for colored coldboot does not allow us to add animation due to the lack of the animation script.

RAF is the most tricky because the internal structure contains some tables specific to store numbers by data type (float, integer, etc..), also are intended to avoid duplication (lets say, if you want to store the value 123.887 several times, the table is goign to store it only 1 time). This features are not implemented but are really required for RAF, check the "scene" sample from this link https://www.psdevwiki.com/ps3/Coldboot.raf#Scene
As example... everytime are used attributes like position="1.85,0.0,0.0" rotation="1.570796,0.0,0.0" etc... that "float" values are "embedded" in the RAF structure (are not a file, but just data spreaded around in the internal RAF structure)

Lets say, in few words... XForge is not able to read/write that special data types from the internal RAF structure
We was thinking in it... but we realized is more important to add support for P3T format (themes)... because is the same concept but with different data types (easyer)
Also, as probably you already know... the background of the animated P3T themes is a RAF... so if we think in the order we need to follow to extract contents from themes it would be P3T ---then --->RAF

Take a look at the contents of the XML files used to represent the contents of a P3T theme, and try to figure his data types, all them are text strings, or integer values (rounded numbers), but there are no floats (decimal numbers)... this is one of the most important reasons why is easyer to implement support for P3T than RAF

Spoiler

In other words... the "float table" (and the "float array table") required for RAF support is tricky

https://www.psdevwiki.com/ps3/PlayStation_3_Theme_(P3T)#Theme_Name_.28.XML.29

Edit:
Btw, im showing you samples of XML files used in P3T and RAF because thats exactly what we need to read/write from the internal fileformats structures
The XML files doesnt exists inside P3T or RAF... all this info is "embedded" in the structure spreaded all around and organized in groups based in his "data types"
Lets say, in few words... the suport of P3T and RAF in XForge depends of how many "data types" are supported, the current version doesnt supports this data types:
-integer
-float
-float array
-maybe some other weird type i dont remember right now
The fact that QRC, P3T, and RAF are different formats with small differences doesnt matters, this is not a challenge because are 99% the same