Recent Posts

Pages: [1] 2 3 ... 10
1
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on March 27, 2024, 03:14:03 AM »
Updated:
  • DuneGraph Uncompressed bitmap (DGU/DG1)
  • GameBoy Sound System dump (GBS)
  • KiCad EESchema Netlist (NET)
  • Slight Atari Player module (SAP)
  • Cyber Paint Sequence animation (SEQ)
Added:
  • Autohotkey script (v2.x) (AHK)
  • Cyber Paint Cell animation (CEL)
  • Linux Preseed Configuration (CFG/SEED/TXT)
  • DISCO Discovery Document (DISCO)
  • DISCO Discovery Output (DISCOMAP/MAP)
  • Linux LiveCD info (DISKDEFINES)
  • Lucasfilm Games MIDI music (GMD)
  • PiyoPiyo Music (PMD)
  • Atari ST Megamax Modula-2 program/executable (v2) (PRG/ACC)
  • Atari ST Pack-Ice compressed program/executable (PRG/APP/TOS/TTP)
  • Atari Midi Sequencer song (SEQ)
  • Cyber Paint Sequence animation (variant) (SEQ)
  • Lucasfilm Games VOC Sound (SOU)
  • Sound Chip Synth patch (SYN)
Deleted:
  • Slight Atari Player music format (SAP)
2
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on March 25, 2024, 12:47:51 PM »
Updated:
  • 16bit COM executable Graham's TXT2COM (generic) (COM)
  • 16bit COM executable Graham's TXT2COM (v1.0) (COM)
  • 16bit COM executable Graham's TXT2COM (v1.1) (COM)
  • 16bit COM executable Graham's TXT2COM (v2.2) (COM)
  • 16bit COM executable Graham's TXT2COM (v2.03) (COM)
  • 16bit COM executable Graham's TXT2COM (v2.06) (COM)
  • 16bit COM executable Graham's TXT2COM (v2.10) (COM)
Added:
  • Impulse Tracker font (CFG)
  • 16bit COM executable Graham's TXT2COM (v2.0) (COM)
  • 16bit COM executable Graham's TXT2COM (v2.1) (COM)
  • 16bit COM executable Graham's TXT2PAS (v2.03) (COM)
  • 16bit COM executable Graham's TXT2PAS (v2.06) (COM)
  • 16bit COM executable Graham's TXT2PAS (v2.10) (COM)
  • 16bit COM executable Graham's TXT2RES (v1.0) (COM)
  • 16bit COM executable Graham's TXT2RES (v2.03) (COM)
  • 16bit COM executable Graham's TXT2RES (v2.06) (COM)
  • 16bit COM executable Graham's TXT2RES (v2.10) (COM)
  • Impulse Tracker sound Driver (DRV)
  • HALAC lossless compressed audio (v0.x) (HALAC)
  • HALIC bitmap (v0.x) (HALIC)
  • MMCMP compressed module (IT/MOD/S3M/XM)
  • SofTest encrypted answers data (JSON)
  • LEGO Batman 2 Saved Game (LEGOBATMAN2SAVEGAMEDATA)
  • Music Box music (SAV)
  • Silicon Graphics bitmap (SGI/BW/RGB/RGBA)
  • SofTest answers data archive (XMDX)
  • BrickLink XML inventory (XML)
  • MecaBricks XML unknow parts (XML)
Deleted:
  • Silicon Graphics bitmap (generic) (SGI)
  • Artisan Dates (XML)
3
Thanks! Will remove the old generic def and keep this one.
4
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on March 22, 2024, 08:56:06 PM »
Updated:
  • MAGIX data (generic) ()
  • RPM Package source (src.rpm) (RPM)
Added:
  • Coordinate 3D format (C3D)
  • Dynamix 3D data container (C3D)
  • Caligari TrueSpace Object (v1.x) (COB)
  • 16bit COM ComprEXE compressed executable (v1.0) (COM)
  • 16bit COM executable DOCMAKER (v1.2) (COM)
  • NeoPaint Help (HLP)
  • 16bit DOS ComprEXE compressed Executable (v1.0) (EXE)
  • Artisan Mat Style (PAAF)
  • Artisan Personal Art Kit (CCPKPSTM) (PAKIT)
  • Artisan Personal Art Kit (PAKT) (PAKIT)
  • RPM Package (v3.0 source) (RPM/SPM)
  • Caligari TrueSpace Scene (SCN)
  • NeoPaint Settings (SET)
  • CruZer's SFV Checker checksum (SFV)
  • DF CrcSfv checksum (SFV)
  • Easy SFV Creator checksum (v2.x) (SFV)
  • FireSFV checksum (SFV)
  • FlashSFV checksum (SFV)
  • GwildorSFV checksum (v1.x) (SFV)
  • QuickSFV checksum (v2.x) (SFV)
  • SFV32nix checksum (v1.x) (SFV)
  • SFVGold checksum (v1.x) (SFV)
  • SFVManager checksum (v1.x) (SFV)
  • SFVit checksum (v1.x) (SFV)
  • SOURmp3 CheckSFV checksum (SFV)
  • Sour SFV checksum (v1.x) (SFV)
  • WIN-SFV32 checksum (v1.x) (SFV)
  • cksfv checksum (v1.x) (SFV)
  • Artisan Skin (SKINX)
  • Dynamix SPT game data container (SPT)
  • Artisan Dates (XML)
Deleted:
  • Coordinate 3D (subset of ADTech File Format) file (common) (C3D)
  • Coordinate 3D (subset of ADTech File Format) file (more generic) (C3D)
  • RoboPlay Player plugin (PLY) (duplicated)
5
TrID File Identifier / replacement bitmap-sgi.trid.xml for Silicon Graphics bitmap
« Last post by jenderek on March 21, 2024, 05:55:13 PM »
Hello trid users,

some days ago i looked at the content of an exotic CD-ROM. There are also
stored samples which are misidentified as Silicon Graphics bitmap.

So i run trid utility on such graphics and related files. All samples
are at least described as "Silicon Graphics bitmap (generic)" by
bitmap-sgi-generic.trid.xml. No mime type and reference is shown. As
suffix SGI is shown. Most RGB samples are described with higher
priority as "Silicon Graphics RGB bitmap" by
bitmap-sgi-rgb.trid.xml. Here RGB is listed as suffix. Many BW samples
are described with higher priority as "Silicon Graphics B/W bitmap" by
bitmap-sgi-bw.trid.xml. Here BW is shown as suffix. The TFM are
misidentified as Silicon Graphics bitmap. These few samples are in
reality TeX font metrics (see appended trid-v-old.txt in output).

To check if samples are really SGI graphics you can use command line tools of
some graphical software (like ImageMagick, XnView) by lines like:
   identify -verbose *.sgi *.tfm
   nconvert -in sgi -info *.sgi *.tfm

Then real graphics are described as "SGI" or "SGI (Irix RGB image)" with
dimensions by ImageMagick (see appended identify-verbose.txt identify.txt in
output) and as sgi or "SGI RGB" with correct dimensions by XnView (see appended nconvert-info.txt).

For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here most samples are
described as "Silicon Graphics Image" by PUID x-fmt/140. Here mime
type image/x-sgi-bw is listed. The artificial samples with 2 and 5
channels are skipped. Also the TFM samples are not misidentified.
Furthermore here only RGB BW file name suffix are considered as valid.
The 2 suffix RGBA SGI are considered here as invalid (see appended
droid-sgi.csv in output).

For comparison reason i also run file command (version 5.45) on such samples.
Here the samples are also recognized. The graphics are here described as "SGI
image data" The TFM samples are correctly described as "TeX font metric data"
(see appended file-5.45.txt in output). But with keep going option the TFM
samples are also described wrong as SGI image data with invalid "0-D"
dimension and "high" 16 channels (see appended file-k-5.45.txt in
output). According to specification patched variant now shows correct
information (see appended file-ext.tmp file-i.tmp file.tmp in output). The
mime type application/x-tex-tfm is here shown for TFM samples and for graphics
generic application/octet-stream shown (see appended file-i-5.45.txt in
output). Here no file name suffix is shown (see appended file-ext-5.45.txt in
output).

On Linux according to shared MIME-info database the samples are called "SGI
image". Here image/x-sgi is shown as mime type. Here only sgi is listed as
suffix. That information can be seen in freedesktop.org.xml.in source found
for example on gitlab.freedesktop.org.

Luckily i found information about such graphic file format on archive team web
site and Wikipedia. That is expressed inside new definitions
bitmap-sgi.trid.xml by line like:

   <RefURL>http://fileformats.archiveteam.org/wiki/SGI_(image_file_format)</RefURL>

There also link to Wikipedia page is here are mentioned. The advantage is that here also download links to samples and software
are listed.

So i run tridscan on my inspected source samples to get new definition
bitmap-sgi.trid.xml as replacement for bitmap-sgi-generic.trid.xml.  The four
file name suffix are expressed by line like:

   <Ext>BW/RGB/RGBA/SGI</Ext>

On Wikipedia also 2 suffix INT and INTA are mentioned. Unfortunately i found no
such samples on my system. So at the moment i do not add these 2 suffix.

On Wikipedia image/sgi is listed as mime type, but this is not officially
registered at IANA. So i choose what is used on Linux systems.  This mime
type is expressed by line like:

   <Mime>application/x-source-rpm</Mime>

So i looked at generated patterns and try to understand and refine it by
looking at specifications. The first construct looks like:

   <Bytes>01DA</Bytes>
   <Pos>0</Pos>

According to documentation that is the magic pattern for such graphics. This
is used inside bitmap-sgi-generic.trid.xml. Unfortunately 2 byte pattern is not
unique enough. So by bad circumstances this is also true for other file
formats likes some Tex font metric. So more patterns are needed.

The second construct looks like:

   <Bytes>00</Bytes>
   <Pos>4</Pos>

According to documentation at offset 4 the dimensions are stored as 2 byte
big endian integer. Allowed values are three values. 1 means scanline, 2 means
dimension XSIZExYSIZE and 3 means XSIZExYSIZExZSIZE dimensions. That means the
upper byte is not used and therefore always nil. DROID tool explicitly check
for these allowed values and thereby skip the TFM samples with invalid 0
value.

Third XML construct looks like

   <Bytes>00</Bytes>
   <Pos>10</Pos>

According to documentation at offset 10 the channels are stored as 2 byte
big endian integer. value 1 means black and white. highest observed value in
my samples was 4. That means RGB+ALPHA channel. If i understand the
documentation right it is maybe possible to have samples with higher channels.
For examples i can imagine an animated RGBA. So then an additional time
component may be added and the channel number would be 5. So the channel
number is probably always lower 256. That means the upper byte is probably
always nil and third XML construct is true.


Third XML construct looks like:

   <Bytes>000000</Bytes>
   <Pos>12</Pos>

According to documentation at offset 12 the minimum pixel value in the image is stored as 4 byte
big endian integer PINMIN. Often this value is 0 or low, but i can imagine that
there exist samples where this value is reaching maximum. So i delete that pattern.


Forth XML construct looks like:

   <Bytes>0000</Bytes>
   <Pos>16</Pos>

According to documentation at offset 16 the maximum pixel value in the image
is stored as 4 byte big endian integer PINMAX. Often this value is 225 or
similar, but i can imagine that there exist samples where this value is
reaching maximum. So i delete that pattern.

Fifth XML construct looks like:

   <Bytes>00000000</Bytes>
   <Pos>20</Pos>

According to documentation at offset 20 4 used bytes are stored. In my
examples the value is zero. I assume that this is always true. So i keep that pattern.

The XML construct number six looks like:

   <Bytes>000000000000000000000000000000000000000000000000</Bytes>
   <Pos>87</Pos>

According to documentation at offset 24 an image can be stored as 80
bytes. This ASCII string is null terminated. At offset 104 COLORMAP
is stored as 4 byte big endian integer. Allowed value are in range 1-3. So the
3 upper bytes of  COLORMAP are always nil. Assuming that string reach maximal
length the only terminating nil byte and the 3 upper byes of COLORMAP will
survive. So the construct will shrink and become like:

   <Bytes>00000000 </Bytes>
   <Pos>103</Pos>

According to documentation from offset 108 til 511 are dummy bytes to scale
the header to 512 bytes. In some documents is written that these should be set
to nil. That is often true but in some samples some bytes are not nil. So i do
not rely on existence of nil bytes in that area. So i delete corresponding
patterns. These look like:


   <Pattern>
      <Bytes>00</Bytes>
      <Pos>112</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00000000</Bytes>
      <Pos>114</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>120</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00000000000000000000</Bytes>
      <Pos>122</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000000000</Bytes>
      <Pos>136</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000000000000000000000000000000000000
      <Pos>152</Pos>
   </Pattern>


With the new definition all my graphic bitmaps still recognized and
described with correct mime type. Now TFM samples are not misidentified
(see appended trid-v-new.txt in output).

TrID definitions, some samples and output are stored in archive sgi_tfm.zip. I
hope that my definition can be used in future version of triddefs.

Then of course the other TrID definitions must updated. Unfortunately i can not do
this because i have too few samples. Especially samples with INT and INTA suffix. I
am also not sure about samples with more channels.

There are no definitions for TeX Font Metric. Unfortunately for TFM samples there
exist no unique and long pattern. So i will need some time to do this work in
the future.

With best wishes
J?rg Jenderek

6
TrID File Identifier / Re: ark-rpm-src-v30.trid.xml for source variant of RPM Package
« Last post by Mark0 on March 20, 2024, 10:48:44 PM »
Thanks Joerg!
7
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on March 19, 2024, 02:02:44 PM »
Added:
  • WiredTiger journal (0000000001)
  • Amazon game data (Atari ST) (CST)
  • Intelligent Games Ltd resource data (HDR/RES)
  • TETRIS! High score (HI)
  • WiredTiger Lock (LOCK)
  • Intelligent Games Video/cutscene (MOV)
  • RoboPlay Player plugin (PLY)
  • Atari ST Atomik packed program/executable (v3.5) (PRG/TOS)
  • Atari ST HiSoft BASIC compiled program/executable (PRG/TOS)
  • Atari ST LHArc SFX archive (v3.10) (PRG/TOS)
  • Atari ST STOS BASIC compiled program/executable (PRG)
  • Atari ST TDI Modula-2/ST compiled program/executable (PRG/ACC)
  • Steel Panthers Shapes data (SHP)
  • WiredTiger data  (WT)
8
TrID File Identifier / ark-rpm-src-v30.trid.xml for source variant of RPM Package
« Last post by jenderek on March 18, 2024, 03:28:11 AM »
Hello trid users,

some days ago i looked at the content of an exotic CD-ROM. There are also
stored Red Hat Packages. Most samples have RPM file name suffix.

So i run trid utility on such packages. All samples are recognized and
described as "RPM Package (generic)" by ark-rpm.trid.xml. Here as mime type
application/x-rpm is shown and RPM is displayed as file name suffix (see
appended trid-v-old.txt in output). As reference the page about RPM Package
Manager on Wikipedia is used. That is expressed by line like:
   <RefURL>http://en.wikipedia.org/wiki/RPM_Package_Manager</RefURL>

For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here the samples are also
recognized. The samples are described here as "RPM Package Manager file". Here
no mime type is listed and only RPM suffix is considered as valid (see
EXTENSION_MISMATCH in appended droid-rpm.csv in output). It also does a sub
classification. Three different versions are listed (1 2 3). These are
described as via PUID fmt/793m fmt/794 and fmt/795. Here i find hint for my
observed unusual items. Here it is written that RPM files currently appear in
two defined types, the first is binary package files containing the compiled
version of certain software. The second is source package files containing the
source code used to produce a package. These have an appropriate tag in the
file header that distinguishes them from Binary RPMs, causing them to be
extracted to /usr/src on installation. Source package files customarily carry
the file extension ?.src.rpm". So that is only half of the truth.

For comparison reason i also run file command (version 5.45) on such samples.
Here the samples are also recognized. These are here described generic as
"RPM" (see appended file-5.45.txt in output). It also shows the version
information as done by DROID. here the three version are shown (as v1 v2
v3.0). After that information phrase bin is shown for binary packages and src
for source packages. Afterwards the canonical architecture names are shown for
most cases. For some samples that information is here not show. Obviously this
is a bug in current file command. That fact had me made nervous when looking
in package collection outputs. The mime type application/x-rpm is here also
shown (see appended file-i-5.45.txt in output). Here no file name suffix is
shown (see appended file-ext-5.45.txt in output).

On Linux according to shared MIME-info database the binary samples are called
"RPM package". Here application/x-rpm is shown as mime type. The samples are
just recognized by looking for 4 byte sequence \xed\xab\xee\xdb at the
beginning. Here also rpm is listed as suffix. But for source packages here
application/x-source-rpm is shown as mime type and 2 name endings are listed
(*.src.rpm *.spm). That information can be seen in freedesktop.org.xml.in
source found for example on gitlab.freedesktop.org. Unfortunately i found no
example with SPM suffix on my systems. To verify these information i search
for SPM suffix and i i found at least 2 different web sites with
information. These sites are:

 https://filext.com/file-extension/SPM
 https://www.file-extensions.org/spm-file-extension-source-package-manager-data

On Wikipedia it is explicitly explained that instead of longer name ending
.src.rpm also .spm can be used to overcome some limit on old file systems like
FAT16 (with 8+3 name length).

Luckily i found information about RPM packages file formats on archive team
web site. That is expressed inside new definitions by line like:
   <RefURL>http://fileformats.archiveteam.org/wiki/RPM</RefURL>

The current Wikipedia page used as reference is here are mentioned as
link. The advantage is that here also download links to samples and software
are listed. Further more a direct line to package file format is listed here
in specifications section.

So i run tridscan on my inspected source samples to new definition.  The two
file name suffix are expressed by line like:
   <Ext>RPM/SPM</Ext>
The mime type is expressed by line like:
   <Mime>application/x-source-rpm</Mime>

So i looked at generated patterns and try to understand and refine it by
looking at specifications. The first construct looks like:
   <Bytes>EDABEEDB0300000100</Bytes>
   <Pos>0</Pos>
According to documentation the files begin with signature bytes
EDABEEDB. Afterwards comes major version byte followed by minor revision
number byte. In my inspected samples these are 3 and 0, which is read as
version 3.0. Unfortunately none of inspected samples is an older
version. Maybe that with older samples patterns shrink. So at the moment i
concentrate on version three and therefore use definition name
ark-rpm-src-v30.trid.xml.  At offset 6 the type is stored as 2 byte big
endian.  The value indicates whether this is a source or binary package. This
value shall be 0 to indicate a binary package. Then apparently value 1 means
source package. At offset 8 the architecture number is stored as 2 byte big
endian. There exist only a dozen of possible values. At the moment highest
number is 23 for loongarch64 and 255 for noarch. So the upper byte of this
number will by always nil.

The second construct looks like:
 <Bytes>00000000000000000000000000000000000000000000000000000000000000000000
 00010005000000000000000000000000000000008EADE80100000000000000</Bytes>
 <Pos>42</Pos>
At offset 10 the package name is stored. This string i null terminated and has
a length of 66. Apparently in my samples the maximal package name length is
not used. So i got many nil bytes. At offset 76 osnum is stored as 2 byte big
endian. This is indicating the Operating system. This shall be 1 but in few
binary packages (MainActor-2_06linux.rpm openssl-0.9.8zh-2.aix5.1.ppc.rpm
openssl-1.0.2s-1.aix5.1.ppc.rpm PGPCommandLine-10.4.1.54-MP2-aix5.3.ppc.rpm) i
found value 255. At offset 78 the signature type is stored as 2 byte big
endian. According to specification this value shall be 5. At offset 80 16
reserved bytes are stored. In all my inspected samples this is nil except in
example MainActor-2_06linux.rpm (this starts 44d2ffbfda5c0508).  At offset 96
the structures rpmheader start with 4 byte magic "\216\255\350\001" (8eade801
hexadecimal). This followed by 4 reserved bytes. This value shall be
"\000\000\000\000". At offset nindex is stored as as 4 byte big endian. That
is the number of index records that follow this header record. In my examples
i get "low values ( like 2 3 4 5 7 8 9 10). Assuming that package name and
index records is maximal the most of first and the last 3 nil bytes vanish in
above XML construct. So this now will become like:
 <Bytes>0000010005000000000000000000000000000000008EADE80100000000</Bytes>
 <Pos>75</Pos>

At higher offset occur some short nil sequences like:
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>108</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>112</Pos>
   </Pattern>
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>116</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>120</Pos>
   </Pattern>
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>124</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>128</Pos>
   </Pattern>
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>132</Pos>
   </Pattern>
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>136</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>140</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>144</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>184</Pos>
   </Pattern>
I assume that this are triggered by lucky circum stances. Some 4 byte fields
in other structures are not reaching maximum. Assuming what such value can
reach "high" values or occur at other offset these pattern vanish.

In global strings section i get lines like:
   <String>CPIO'GZIP'9</String>
   <String>.SPEC</String>
   <String>.TAR.</String>
   <String>LINUX</String>

Apparently this are triggered by RPM nature. RPM contain gzip compressed CPIO
archives. The sources are packed as TAR archives.  And the build instruction
are stored in SPEC text files. I do not know if is possible to use other
compression, packing formats here.

With the new definition all my source packages are still recognized and
described with correct suffix (see appended trid-v-new.txt in output).

TrID definitions, some samples and output are stored in archive rpm_.zip. I
hope that my definition can be used in future version of triddefs.

With best wishes
J?rg Jenderek

9
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on March 14, 2024, 12:55:45 PM »
Updated:
  • Logisim Circuit (CIRC)
Added:
  • MIDI Arpeggiator Arpeggio (ARP)
  • Logisim Hexdump/image format (raw, v2.0) (HEX)
  • Logisim Hexdump/image format (words plain, v3.0) (HEX)
  • Logisim Hexdump/image format (words addressed, v3.0) (HEX)
  • Pure Pascal Help (v1.x) (HLP)
  • Netscape bookmark (v1.0) (HTM)
  • Trumpet Windsock settings (INI)
  • Instant Graphics and Sound (IGS/IG/GR1)
  • Atari ST Pure-C v1.x compiled program/executable (PRG/ACC/APP/TOS/TTP)
  • Atari ST Pure Pascal compiled program/executable (PRG/APP/ACC/OVL/TTP)
  • Atari ST Turbo-C compiled program/executable (PRG/GTP/OVL/TTP/ACC/APP/TOS)
  • Scribble Synth data (SCR)
  • Snippit patch (SNP)
  • TurboBase DB (TBP)
10
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on March 12, 2024, 11:47:57 PM »
Updated:
  • Corel Corel Dream3D scene (D3D)
  • ElectricImage 3D model (FACT/FAC)
  • IFC-SPF (with rem) (IFC)
  • Serif PhotoPlus Picture (OLE) (SPP)
  • Ray Dream Designer scene (RD4)
Added:
  • BeebEm preferences (CFG)
  • DESIGN 3D path (CHM)
  • Fortune Cite data (CIT)
  • DESIGN 3D outline (CNT)
  • DESIGN 3D scene (D3D)
  • GPatch Patch (v1.4) (GPATCH/GPCH)
  • GPatch Patch (v1.6) (GPATCH/GPCH)
  • GPatch Patch (v2.6) (GPATCH/GPCH)
  • GPatch Patch (v3.0) (GPATCH/GPCH)
  • IFC-SPF (IFC)
  • MoviePlus Project (MVP)
  • S.O.T.E. module (MUS)
  • System Audio Manager Aware info (SAA)
  • DESIGN 3D Script (SCR)
  • DESIGN 3D Sky (SKY)
  • MS 2.5 module (SNG)
  • SQ Tracker module (SQT)
  • TriSound module (TRI)
  • TriSound Voice Set (TVS)
  • Crossrunner saved state (XRS)
Pages: [1] 2 3 ... 10