Editing CXML Containers

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
=Description=
=Description=
[[Qt Resource Container (QRC)|.QRC]], [[PlayStation 3 Theme (P3T)|.P3T]], and [[Rich Appearance Format (RAF)|.RAF]] (in order of complexity from easier to harder) and '''.CXML''' file extensions uses the same container, and are able to use zlib compression, but the zlib compression method and the structure of the container has several variations:
[[Qt Resource Container (QRC)|.QRC]], [[PlayStation 3 Theme (P3T)|.P3T]], and [[Rich Appearance Format (RAF)|.RAF]] (in order of complexity from easyer to harder) and '''.CXML''' file extensions uses the same container, and are able to use zlib compression, but the zlib compression method and the structure of the container has several variations:


The only way to identify accurate the exact container type is by reading the texts in the "strings table" (are tags and some of his values from the .xml file that was used to build the container) that are related with the building process and defines his internal structure, but their names are too long to use when talking about them
The only way to identity accuratelly the exact container type is by reading the texts in the "strings table" (are tags and some of his values from the .xml file that was used to build the container) that are related with the building process and defines his internal structure, but his names are too long to use when talking about them


*'''For QRC there are 2 basic variations:''' (both of them uses zlib compression, and only contains a "file-table" with "files")
*'''For QRC there are 2 basic variations:''' (both of them uses zlib compression, and only contains a "file-table" with "files")
**'''QRCC''' - (used by all .qrc files except icontex.qrc) - zlib compression is applied over the whole .qrc file (except his first 8 bytes that are info for the decompression), after decompression the file generated is a QRCF and the internal container structure can be readed (QRCC always contains a QRCF that is the real container)
**'''QRCC''' - (used by all .qrc files except icontex.qrc) - zlib compression is applyed over the whole .qrc file (except his first 8 bytes that are info for the decompression), after decompression the file generated is a QRCF and the internal container structure can be readed (QRCC always contains a QRCF that is the real container)
**'''QRCF''' - (used only by icontex.qrc) - zlib compression is applied per-file over each contained file (the container structure can be read directly and every one of the files inside the container structure is compressed individually)
**'''QRCF''' - (used only by icontex.qrc) - zlib compression is applyed per-file over each contained file (the container structure can be readed directlly and every one of the files inside the container structure is compressed individually)


*For this reason is not possible to identify the 2 variations of QRC by reading his magic (both are QRCF) but his structure is different, so is needed to use unofficial names to identify them and to be able to explain his variations here in wiki, the proposed names used in this page are:
*For this reason is not posible to identify the 2 variations of QRC by reading his magic (both are QRCF) but his structure is different, so is needed to use unnofficial names to identify them and to be able to explain his variations here in wiki, the proposed names used in this page are:
**'''QRCF_1''' (the most common and older... used by all .qrc's except icontext.qrc)
**'''QRCF_1''' (the most common and older... used by all .qrc's except icontext.qrc)
**'''QRCF_2''' (the less common and newer... used only by icontex.qrc)
**'''QRCF_2''' (the less common and newer... used only by icontex.qrc)
Line 14: Line 14:
*'''For P3T there are lot of posible variations:'''
*'''For P3T there are lot of posible variations:'''
**The internal structure is dependant of the items included in the theme... some of them can be icons (to be stored inside an icontable) and others can be a wallpaper, the mouse pointers (stored in a pointertable), navigation sounds (stored in a se table), etc...
**The internal structure is dependant of the items included in the theme... some of them can be icons (to be stored inside an icontable) and others can be a wallpaper, the mouse pointers (stored in a pointertable), navigation sounds (stored in a se table), etc...
**Is possible to create themes with the official theme compiler tool with all this items, or only a few of them (e.g: a theme containing only 1 icon... or a theme containing only the name of the theme), this frankenstein themes are really useful for understanding the structure as you can see in this examples ---> https://www.sendspace.com/file/5suokd
**Is posible to create themes with the official theme compiler tool with all this items, or only a few of them (e.g: a theme containing only 1 icon... or a theme containing only the name of the theme), this frankenstein themes are really usefull for understanding the structure as you can see in this examples ---> https://www.sendspace.com/file/5suokd


*'''For RAF seems is posible a lot of variations too'''
*'''For RAF seems is posible a lot of variations too'''
**RAF's are used for the animation scene inside dynamic themes, when using them this way it seems the contents is restricted to a list of contained files, but raf is also used in the animation when PS3 boots (coldboot.raf) and although his format is pretty similar than the background of a theme is possible to include multiple files of different types inside the container
**RAF's are used for the animation scene inside dynamic themes, when using them this way it seems the contents is restricted to a list of contained files, but raf is also used in the animation when PS3 boots (coldboot.raf) and althought his format is pretty similar than the background of a theme is posible to include multiple files of different types inside the container


All this variations are confusing and hard to explain in the page, but is needed to find a way to represent them as the basic layouts that the firmware expects to find inside the container
All this variations are confusing and hard to explain in the page, but is needed to find a way to represent them as the basic layouts that the firmware expects to find inside the container
Line 251: Line 251:
QRCC ('''Q'''t '''R'''esources '''C'''ontainer '''C'''ompressed)
QRCC ('''Q'''t '''R'''esources '''C'''ontainer '''C'''ompressed)


In the practise and from the point of view of the system, the QRCC has no interest and is needed to decompress the whole QRCC to be able to read the internal structure of the container and to acess individual files, when a QRCC is decompressed it generates an QRCF file (the real container) but this QRCF has a different internal structure than the QRCF used by icontex.qrc (are 2 variations of the same container with some small differences... although both uses the same identifier QRCF)
In the practise and from the point of view of the system, the QRCC has no interest and is needed to decompress the whole QRCC to be able to read the internal structure of the container and to acess individual files, when a QRCC is decompressed it generates an QRCF file (the real container) but this QRCF has a different internal structure than the QRCF used by icontex.qrc (are 2 variations of the same container with some small differences... althougth both uses the same identifyer QRCF)


*Example from 3.55 rhm.qrc:
*Example from 3.55 rhm.qrc:
Line 280: Line 280:


===Main Header===
===Main Header===
The header contains an identifier of the container (magic), his version, and allows to store the "absolute start offset" and "size" of 7 tables (or areas)
The header contains an identifyer of the container (magic), his version, and allows to store the "absolute start offset" and "size" of 7 tables (or areas)


When a "not used table" is placed before a "used table"... the start offset of the "not used table" and his size (as zero) are stored in the main header to preserve his position in the structure. The "used table" that comes later starts in the same offset than the previously "not used table" (an intuitive way to think in this is imagining are overlapped because starts in the same position but only the one at the top is used)
When a "not used table" is placed before a "used table"... the start offset of the "not used table" and his size (as zero) are stored in the main header to preserve his position in the structure. The "used table" that comes later starts in the same offset than the previouslly "not used table" (an intuitive way to think in this is imagining are overlapped because starts in the same position but only the one at the top is used)


*The container format is generic (used also by .RAF and .P3T with some variations) so the usage of this tables can vary, in this example there are 3 "not used tables":
*The container format is generic (used also by .RAF and .P3T with some variations) so the usage of this tables can vary, in this example there are 3 "not used tables":
Line 334: Line 334:


*Notes
*Notes
**The sizes doesn't includes the (possible) padding at the end of all tables
**The sizes doesnt includes the (posible) padding at the end of all tables


===Tree Table===
===Tree Table===
Line 422: Line 422:


Every <file> inside <file-table> has assigned 2 attributes in the xml used to create the container: "src" (includes full path + file name + file extension), and "id" (only file name), plus the attribute "size" in QRCF_2 that is added by the program that creates the container ("size" is not present in the original .xml but added automatically when the container is created, this only happens in QRCF_2 and themes and is related with the per-file compression)
Every <file> inside <file-table> has assigned 2 attributes in the xml used to create the container: "src" (includes full path + file name + file extension), and "id" (only file name), plus the attribute "size" in QRCF_2 that is added by the program that creates the container ("size" is not present in the original .xml but added automatically when the container is created, this only happens in QRCF_2 and themes and is related with the per-file compression)
*For QRCF_1 containers only is stored the "src" (the file "id" is missing although can be deduced from the "src")
*For QRCF_1 containers only is stored the "src" (the file "id" is missing althougth can be deduced from the "src")
*For QRCF_2 and P3T themes only is stored the "id" (the file "src" is missing so there is no way to read the original path or file extension from the container)
*For QRCF_2 and P3T themes only is stored the "id" (the file "src" is missing so there is no way to read the original path or file extension from the container)


Line 454: Line 454:


===String Table===
===String Table===
This area is composed by a consecutive list of all the tags (elements or attributes) from the xml that was used to create the container. Are stored "from-top-to-bottom" in the exact same order that they was ordered in the xml (although it looks in some cases the theme compiler reorders them to his convenience). This list doesn't makes differences of the "directory hierarchy" of the tags neither is specified if the tag is an element or an attribute (this parent-child hierarchy is defined in other place of the container by making references to this area by using "byte counters" to locate a tag)
This area is composed by a consecutive list of all the tags (elements or attributes) from the xml that was used to create the container. Are stored "from-top-to-bottom" in the exact same order that they was ordered in the xml (althougth it looks in some cases the theme compiler reorders them to his convenience). This list doesnt makes differences of the "directory hierarchy" of the tags neither is specifyed if the tag is an element or an attribute (this parent-child hierarchy is defined in other place of the container by making references to this area by using "byte counters" to locate a tag)


  In all the .qrc files (QRCF_1) except icontex.qrc (QRCF_2). The only difference is QRCF_2 adds the "size" to all the <file> elements (added by the container creator, related with the "per-file" compression)
  In all the .qrc files (QRCF_1) except icontex.qrc (QRCF_2). The only difference is QRCF_2 adds the "size" to all the <file> elements (added by the container creator, related with the "per-file" compression)
Line 695: Line 695:


====String Table====
====String Table====
This area is composed by a consecutive list of all the tags (elements or attributes) from the xml that was used to create the container. Are stored "from-top-to-bottom" in the exact same order that they was ordered in the xml (althougth it looks in some cases the theme compiler reorders them to his convenience). This list doesn't makes differences of the "directory hierarchy" of the tags neither is specified if the tag is an element or an attribute (this parent-child hierarchy is defined in other place of the container by making references to this area by using "byte counters" to locate a tag)
This area is composed by a consecutive list of all the tags (elements or attributes) from the xml that was used to create the container. Are stored "from-top-to-bottom" in the exact same order that they was ordered in the xml (althougth it looks in some cases the theme compiler reorders them to his convenience). This list doesnt makes differences of the "directory hierarchy" of the tags neither is specifyed if the tag is an element or an attribute (this parent-child hierarchy is defined in other place of the container by making references to this area by using "byte counters" to locate a tag)
   
   
  '''Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F'''
  '''Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F'''
Line 873: Line 873:
_RAF ('''_'''? '''R'''ich '''A'''ppearance '''F'''ormat)
_RAF ('''_'''? '''R'''ich '''A'''ppearance '''F'''ormat)


In practise and from the point of view of the system, the _RAF has no interest and is needed to decompress the whole _RAF to be able to read the internal structure of the container and to acess individual files, when a _RAF is decompressed it generates an RAFO file (the real container).
In the practise and from the point of view of the system, the _RAF has no interest and is needed to decompress the whole _RAF to be able to read the internal structure of the container and to acess individual files, when a _RAF is decompressed it generates an RAFO file (the real container).


*Example from anim.raf of HeavyRain.p3t:
*Example from anim.raf of HeavyRain.p3t:
Line 954: Line 954:


*Notes
*Notes
**The sizes doesn't includes the (posible) padding at the end of all tables
**The sizes doesnt includes the (posible) padding at the end of all tables


===Tree Table===
===Tree Table===
Line 1,045: Line 1,045:


===String Table===
===String Table===
This area is composed by a consecutive list of all the tags (elements or attributes) from the xml that was used to create the container. Are stored "from-top-to-bottom" in the exact same order that they was ordered in the xml. This list doesnt makes differences of the "directory hierarchy" of the tags neither is specified if the tag is an element or an attribute (this parent-child hierarchy is defined in other place of the container by making references to this area by using "byte counters" to locate a tag)
This area is composed by a consecutive list of all the tags (elements or attributes) from the xml that was used to create the container. Are stored "from-top-to-bottom" in the exact same order that they was ordered in the xml. This list doesnt makes differences of the "directory hierarchy" of the tags neither is specifyed if the tag is an element or an attribute (this parent-child hierarchy is defined in other place of the container by making references to this area by using "byte counters" to locate a tag)
   
   
  '''Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F'''
  '''Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F'''
Line 1,106: Line 1,106:
The Typ '''File''' is used to descripe two integer values, the Offset and Size for a File which will be readed from '''File Table'''. The Typ '''ID with ref''' is used to descripe the Offset of a Filename within the '''ID Table''' with the use of a 4 byte long reference, starting from the Offset given. The Second value from '''ID''' seems not to be used in Containers. So '''ID without ref''' is the same but it doesn't use an reference byte (aka. the Offset of Element). Similar to  '''ID''', the '''Integer''' Typ only use one value the second one seems not to be used. '''Float''' is identical to '''Integer'''. '''Float Array''' is used to describe the offset and count of float values. But offset will be readed as a float count just like the second var float count it self, only with the diff it is meant as offset and you start to read the given Float count from there. Example: offset 7, float_count 2 == offset 7 (7 float values to jump, á 4 bytes * 7 = 28 so Offset = 0x28) float_count 2 (2 float values to take from offset 0x28 á 4 byts long so 8 bytes to read). Result in bytes: offset == 0x28, float_count == 0x08.
The Typ '''File''' is used to descripe two integer values, the Offset and Size for a File which will be readed from '''File Table'''. The Typ '''ID with ref''' is used to descripe the Offset of a Filename within the '''ID Table''' with the use of a 4 byte long reference, starting from the Offset given. The Second value from '''ID''' seems not to be used in Containers. So '''ID without ref''' is the same but it doesn't use an reference byte (aka. the Offset of Element). Similar to  '''ID''', the '''Integer''' Typ only use one value the second one seems not to be used. '''Float''' is identical to '''Integer'''. '''Float Array''' is used to describe the offset and count of float values. But offset will be readed as a float count just like the second var float count it self, only with the diff it is meant as offset and you start to read the given Float count from there. Example: offset 7, float_count 2 == offset 7 (7 float values to jump, á 4 bytes * 7 = 28 so Offset = 0x28) float_count 2 (2 float values to take from offset 0x28 á 4 byts long so 8 bytes to read). Result in bytes: offset == 0x28, float_count == 0x08.
* '''ID with ref''' (0x00000007) is using the entry Offset from the Element (to which the Attribute belongs) as reference byte to compare if it is using the correct Filename for the processing File.
* '''ID with ref''' (0x00000007) is using the entry Offset from the Element (to which the Attribute belongs) as reference byte to compare if it is using the correct Filename for the processing File.
* '''ID without ref''' (0x00000008) doesn't. Or at least if it does it, it knows that the returned value will be a false one.
* '''ID without ref''' (0x00000008) does this not. Or at least if it does it, it knows that the returned value will be a false one.


==CXML==
==CXML==
Line 1,113: Line 1,113:
Magic of the container is '''HKNW''' (acronym of hakoniwa)
Magic of the container is '''HKNW''' (acronym of hakoniwa)


Hakoniwa is the "Photo Gallery" official app (NPIA00006) that comes partially preinstalled in the firmwares (there is a mandatory icon in XMB photo column and is dependant of hknw_plugin.sprx, but the program itself is not installed with the firmware). To use the program it is needed to install the .PKG that installs the rest of the files in dev_hdd0/game/NPIA00006/USRDIR/EBOOT.PBP
Hakoniwa is the "Photo Gallery" official app (NPIA00006) that comes partially preinstalled in the firmwares (there is a mandatory icon in XMB photo column and is dependant of hknw_plugin.sprx, but the program itself is not installed with the firmware). To use the program is needed to install the .PKG that installs the rest of the files in dev_hdd0/game/NPIA00006/USRDIR/EBOOT.PBP


In path: '''dev_flash/vsh/resource/hknw_plugin/jacket/''' index.cxml, frame_01.cxml, and frame_05.cxml
In path: '''dev_flash/vsh/resource/hknw_plugin/jacket/''' index.cxml, frame_01.cxml, and frame_05.cxml
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)