Resource Container (RCO): Difference between revisions
m (→TOC: "RCO TOC entry common area" table converted to template) |
m (→TOC: moved to Talk:RCOXML Fonts) |
||
Line 280: | Line 280: | ||
*(0x7) Font | *(0x7) Font | ||
*(0x8) Object | *(0x8) Object | ||
*(0x9) Animation | *(0x9) Animation |
Revision as of 06:29, 27 September 2016
Description
The file extension in PSP and PS3 is RCO that seems to be the acronym of Resource Container Objet
The file signature (aka magic number) from PSP (in little endian) is PRF that seems to be the acronym of Playstation Resource File
RCO contents are loaded by other firmware functions as XMBML setting files, and XMB modules (also known as .sprx plugins), see Plugin Interfaces and VSH
Contents
- RCO contents (See Multimedia Formats and Tools):
Text for all languages, textures, sounds (for cursor navigation, trophy unlocking, etc...) and models
RCO format | Embedded code | Text | Textures | Sounds | Models | Script |
---|---|---|---|---|---|---|
Generic | RCOXML | utf8, utf16, utf32 | gim, png, jpg, tif, gif, bmp | vag, unknown0x0 | gmo | PlayStation JavaScript |
PS3 specific | RCOXML | utf16 | gim, png, jpg | vag | n/a | n/a |
Versions
RCO Structure
Based on RCO File Format (outdated) and rcomage source
Header
Offset | Length | Example | Name | Notes |
---|---|---|---|---|
0x00 | 0x04 | 46 52 50 00 | prf_signature | In PS3 is "FRP" (big endian). In PSP is "PRF" (little endian) |
0x04 | 0x04 | 00 00 00 97 | prf_version | named minFirmwareVer in Rcomage, see Discussion page |
0x08 | 0x04 | 00 00 00 00 | prf_unknown | |
0x0C | 0x04 | 00 00 00 00 | prf_compression | 0x00=uncompressed, 0x10=ZLIB, 0x20=RLZ It can be combined with UMDflag, see Discussion page |
0x10 | 0x04 | 00 00 00 A4 | toc_maintree_absolute_offset | |
0x14 | 0x04 | FF FF FF FF | toc_scripttree_absolute_offset | |
0x18 | 0x04 | FF FF FF FF | toc_languagetree_absolute_offset | |
0x1C | 0x04 | FF FF FF FF | toc_soundtree_absolute_offset | |
0x20 | 0x04 | FF FF FF FF | toc_modeltree_absolute_offset | |
0x24 | 0x04 | FF FF FF FF | toc_imagetree_absolute_offset | |
0x28 | 0x04 | FF FF FF FF | toc_unknown | |
0x2C | 0x04 | FF FF FF FF | toc_fonttree_absolute_offset | |
0x30 | 0x04 | 00 00 00 CC | toc_objecttree_absolute_offset | |
0x34 | 0x04 | FF FF FF FF | toc_animationtree_absolute_offset | |
0x38 | 0x04 | 00 00 01 D4 | str_language_table_absolute_offset | |
0x3C | 0x04 | 00 00 00 00 | str_language_table_length | |
0x40 | 0x04 | 00 00 01 D4 | str_label_table_absolute_offset | |
0x44 | 0x04 | 00 00 00 1C | str_label_table_length | |
0x48 | 0x04 | 00 00 01 F0 | str_event_table_absolute_offset | |
0x4C | 0x04 | 00 00 00 04 | str_event_table_length | |
0x50 | 0x04 | FF FF FF FF | ptr_language_table_absolute_offset | |
0x54 | 0x04 | 00 00 00 00 | ptr_language_table_length | |
0x58 | 0x04 | FF FF FF FF | ptr_image_table_absolute_offset | |
0x5C | 0x04 | 00 00 00 00 | ptr_image_table_length | |
0x60 | 0x04 | FF FF FF FF | ptr_model_table_absolute_offset | |
0x64 | 0x04 | 00 00 00 00 | ptr_model_table_length | |
0x68 | 0x04 | FF FF FF FF | ptr_sound_table_absolute_offset | |
0x6C | 0x04 | 00 00 00 00 | ptr_sound_table_length | |
0x70 | 0x04 | 00 00 01 CC | ptr_object_table_absolute_offset | |
0x74 | 0x04 | 00 00 00 08 | ptr_object_table_length | |
0x78 | 0x04 | FF FF FF FF | ptr_animation_table_absolute_offset | |
0x7C | 0x04 | 00 00 00 00 | ptr_animation_table_length | |
0x80 | 0x04 | FF FF FF FF | dat_image_table_absolute_offset | |
0x84 | 0x04 | 00 00 00 00 | dat_image_table_length | |
0x88 | 0x04 | FF FF FF FF | dat_sound_table_absolute_offset | |
0x8C | 0x04 | 00 00 00 00 | dat_sound_table_length | |
0x90 | 0x04 | FF FF FF FF | dat_model_table_absolute_offset | |
0x94 | 0x04 | 00 00 00 00 | dat_model_table_length | |
0x98 | 0x04 | FF FF FF FF | dat_unknown_1 | |
0x9C | 0x04 | FF FF FF FF | dat_unknown_2 | |
0xA0 | 0x04 | FF FF FF FF | dat_unknown_3 |
TOC
This area works as an index of all the .rco contents, when the area is compressed there are 12 bytes at the beginning with info about this compression, after it starts the info composed by entries that follows a hierarchy of parent/children/brother, every entry defines an element with its attributes. All this info can be represented as an xml file (this is what rcomage names an RCOXML)
The container structure can be represented as an XML (see RCOXML), with rcomage is posible to generate this XML when extracting, and for rebuilding the rco using the XML as a layout
Every entry has an area at beginning that is common for all entry_types, the values that comes after this common area are specific and different for each the entry_type
Offset | Length | Data type | Name | Example (TOC) | Example (XML) | Notes | ||
---|---|---|---|---|---|---|---|---|
0x00 | 0x04 | int | entry_type | Yes | Yes | 01 01 / 00 00 | <Element name="label"/> |
entry_type[2], padding[2] |
0x04 | 0x04 | int | entry_label_offset | Yes | Yes | 00 00 00 00 | label_string_table_offset[4] (optional) | |
0x08 | 0x04 | int | attributes_offset | Yes | Yes | 00 00 00 00 | represents XML hierarchy | Attributes offset relative to the start of this entry (optional) |
0x0C | 0x04 | int | children_offset | Yes | Yes | 00 00 00 28 | First children offset relative to the start of this entry (optional) | |
0x10 | 0x04 | int | children_number | Yes | Yes | 00 00 00 00 | Number of subentries | |
0x14 | 0x04 | int | next_sibling_offset | Yes | Yes | 00 00 00 00 | Next sibling offset relative to the start of this entry (optional) | |
0x18 | 0x04 | int | prev_sibling_offset | Yes | Yes | 00 00 00 00 | Previous sibling offset relative to the start of this entry (optional) | |
0x1C | 0x04 | int | parent_offset | Yes | Yes | 00 00 00 00 | This entry offset relative to the start of the parent entry | |
0x20 | 0x08 | unk | toc_entry_unk | Yes | Yes | 00 00 00 00 .. . | no XML representation | Unknown |
Second byte | |||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 | 0x08 | 0x09 | 0x0A | 0x0B | 0x0C | 0x0D | 0x0E | 0x0F | 0x10 | 0x11 | 0x12 | 0x13 | 0x14 | 0x15 | 0x16 | 0x17 | 0x18 | 0x19 | 0x1A | 0x1B | 0x1C | 0x1D | 0x1E | 0x1F | ||
First byte | 0x01 | unk | MainTree | ||||||||||||||||||||||||||||||
0x02 | ScriptTree | ||||||||||||||||||||||||||||||||
0x03 | TextTree | Text | |||||||||||||||||||||||||||||||
0x04 | ImageTree | Image | |||||||||||||||||||||||||||||||
0x05 | ModelTree | Model | |||||||||||||||||||||||||||||||
0x06 | SoundTree | Sound | |||||||||||||||||||||||||||||||
0x07 | FontTree | Font | |||||||||||||||||||||||||||||||
0x08 | ObjectTree | Page | Plane | Button | XMenu | XMList | XList | Progress | Scroll | MList | MItem | unk | XItem | Text | ModelObject | Spin | Action | ItemSpin | Group | LList | LItem | Edit | Clock | IList | IItem | Icon | UButton | unk | CheckboxGroup | CheckboxItem | Meter | EditBox | |
0x09 | AnimTree | Anim | MoveTo | Recolour | Rotate | Resize | Fade | Delay | FireEvent | Lock | Unlock | SlideOut | |||||||||||||||||||||
Supported by and | Supported by only |
- The entry_types with the suffix Tree (as example MainTree) are special and doesnt uses attributes, MainTree is always located as the first entry, doesn't have a parent, and doesn't have any previous or next "sibling", the maximun number posible of childrens for MainTree is 8 (containing all the other "trees"). The other "trees" (as example imageTree or soundTree) are siblings and are the childrens of "MainTree", Every one of those "trees" contains a variable number of entry_types that are its childrens
- The attributes of the RCOXML Objects (entry_types starting with 0x08) and RCOXML Animations (entry_types starting with 0x09) can be grouped in standard attributes (used by most entryes of this type) and specific attributes (different for every entry_type). The standard attributes are always located before the specific attributes
- First two bytes are swapped based on architecture (PSP in little endian, PS3 in big endian). The table shows the values in big endian
After the area common for all entries it starts the info specific for each entry_type explained below
- (0x1) MainTree
Main tree doesnt uses specific attributes, only uses the default ones explained above that indicates his position at top of the RCOXML Structure hierarchy and gives it a "label" name
- (0x2) Script
This is named "ScriptTree" for simplification purposes, but is not actually a tree, only one VSMX file can be stored inside an RCO
Offset | Length | Name | Example | Notes |
---|---|---|---|---|
0x00 | 0x04 | file_offset | VSMX file offset, relative to the start offset of the vsmx data table (always 0) | |
0x04 | 0x04 | file_size | VSMX file length |
- (0x3) Text
"TextTree" could be renamed to LanguageTree, is more intuitive, the point is every entry here is the "parent" of several string texts, but the entry itself is not a text (is the parent of a group of texts), so is better to use a name more abstract like "LanguageTree"
For a Language first are specified the language_id and the number of "children" text strings
Offset | Length | Name | Example | Notes |
---|---|---|---|---|
0x00 | 0x02 | language_id | 0x00=Japanese 0x01=English (United States) 0x02=French 0x03=Spanish (Spain) 0x04=German 0x05=Italian 0x06=Dutch 0x07=Portuguese (Portugal) 0x08=Russian 0x09=Korean 0x0A=Chinese (Traditional) 0x0B=Chinese (Simplified) 0x0C=Finnish 0x0D=Swedish 0x0E=Danish 0x0F=Norwegian 0x10=Polish 0x11=Portuguese (Brazil) 0x12=English (United Kingdom) 0x13=Turkish | |
0x02 | 0x02 | strings_format | 0x00=UTF8 0x01=UTF16 0x02=UTF32 | |
0x04 | 0x04 | strings_number | number of text strings for this language_id |
Now for every strings_number are repeated 12 bytes to define every string that are references to other tables
Offset | Length | Name | Example | Notes |
---|---|---|---|---|
0x00 | 0x04 | label_offset | Offset to label, relative of the label table | |
0x04 | 0x04 | string_length | Length of the text | |
0x08 | 0x04 | string_offset | Offset of the text, relative to the text data start address |
- (0x4) Image
The values marked in red are optional, the presence of the unknown specific for PS3 can be deduced based on the "rco version" in the rco header, only exists in PS3 RCO's (PSP doesnt uses it). See rcomage talk page. The presence of the other optional value file_uncompressed_size can be deduced by reading the entry itself
The file_compression feature adds a compression layer over the file format (pointless for image formats that are nativelly compressed like GIM or JPG)
Offset | Length | Name | Example | Notes |
---|---|---|---|---|
0x00 | 0x02 | file_format | 0x0=PNG 0x1=JPEG 0x2=TIFF 0x3=GIF 0x4=BMP 0x5=GIM | |
0x02 | 0x02 | file_compression | 0x0=NONE 0x1=ZLIB 0x2=RLZ | |
0x04 | 0x04 | file_size | either compressed or uncompressed, this is the final size of the file stored inside the rco | |
0x08 | 0x04 | file_offset | ||
0x0C | 0x04 | unknown | PS3 RCOs seem to have this extra value - probably something to do with planes/frames?? usually 0x1 | |
0x10 | 0x04 | file_uncompressed_size | Optional. Doesn't exist if file_compression = NONE, for PSP is located 4 bytes before because the previous value doesn't exists |
- (0x5) Model
ModelTree uses the same values than ImageTree with a couple of differences, the table is repeated here for comparison purposes
The presence of the unknown (specific for PS3) is completlly speculative because never has been found a GMO file used on PS3 official firmware, is not even known if PS3 firmware has some function able to manage GMO files
Offset | Length | Name | Example | Notes |
---|---|---|---|---|
0x00 | 0x02 | file_format | 0x0=GMO | |
0x02 | 0x02 | file_compression | 0x0=NONE 0x1=ZLIB 0x2=RLZ | |
0x04 | 0x04 | file_size | either compressed or uncompressed, this is the final size of the file stored inside the rco | |
0x08 | 0x04 | file_offset | Offset of data relative to the beginning of the image data section | |
0x0C | 0x04 | unknown | PS3 RCOs seem to have this extra value - probably something to do with planes/frames?? usually 0x1 | |
0x10 | 0x04 | file_uncompressed_size | Optional. Doesn't exist if file_compression = NONE, for PSP is located 4 bytes before because the previous value doesn't exists |
- (0x6) Sound
Offset | Length | Name | Example | Notes |
---|---|---|---|---|
0x00 | 0x02 | file_format | 0x0=unknown 0x1=VAG | |
0x02 | 0x02 | audio_channels | 0x1=MONO 0x2=STEREO | |
0x04 | 0x04 | file_size | either one or two channels, this is the final size of the file stored inside the rco | |
0x08 | 0x04 | file_offset | Offset of the sound data to the beginning of the sound data section | |
0x0C | 0x04 | left_channel_size | This is the size of left channel file | |
0x10 | 0x04 | left_channel_offset | Offset of left channel VAG to the beginning of the sound data section | |
0x0C | 0x04 | right_channel_size | Optional. Only exists if audio_channels = STEREO | |
0x10 | 0x04 | right_channel_offset | Optional. Only exists if audio_channels = STEREO |
- (0x7) Font
- (0x8) Object
- (0x9) Animation
Pointer tables
String tables
Data tables
RCO compression methods
When the TOC table is compressed at beginning there are 3 values related with the compression (otherway if the table is not compressed this 3 values doesnt exists)
Offset | Length | Name | Example | Notes | Speculation |
---|---|---|---|---|---|
0x00 | 0x04 | lenPacked | Packed size of all the table sections | ||
0x04 | 0x04 | lenUnpacked | Unpacked size of all the table sections | ||
0x08 | 0x04 | lenLongestText | length of the longest language's text data (unpacked) if the compressed area doesn't contains any language text the value is 0 |
|