Hello trid users,
Some days ago i run Pirisoft ccleaner and it complains about unused 4 byte
file name extension SH3T. These samples are part of Sweet Home 3D. That is a
free interior design application. On the page about Textures import on
product web site is written that SH3T files are just some kind of ZIP file
with individual texture images. That information is now shown in new
definition by line like:
<RefURL>
http://www.sweethome3d.com/importTextures.jsp</RefURL>
I have not found a registered mime type for such SH3T samples. So these
should get at least the mime type of ZIP archives. That is expressed by line
like:
<Mime>application/zip</Mime>
The SH3T file type is described by software version 7.0.2 for Windows as
"eTeks Sweet Home 3D Textures Library". So i show similar description inside
TrID by line like:
<FileType>Sweet Home 3D Textures library</FileType>
I removed company name eTeks and use library phrase in low letters, because
that matches more the 4 byte file name suffix that is expressed by line
like:
<Ext>SH3T</Ext>
When running TrID on such SH3T examples i get an expected unprecisely
output. All examples are with highest rate described generic as "ZIP
compressed archive" by ark-zip.trid.xml. So no sub classification is done
here and so file name extension is wrong (See appended
output/trid-v-old.txt)
For comparison reason i check these examples by file command utility. When
running file command (version 5.42) here all examples are also described
generic as "Zip archive data" (See appended output/file-5.42.txt).
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This identifies all
examples also only generic "ZIP Format" by PUID x-fmt/263 and complains
about name extension SH3T (See appended droid-sh3t.csv).
For comparison reason i generate ZIP archive listing by running 7-zip
unpacking utility (See appended 7z-l-slt.txt 7z-l.txt).
After running tridscan to generate new definition sh3t.trid.xml i began to
refine the definition because it is based only on few samples. First XML
construct looks like:
<Bytes>504B0304</Bytes>
<ASCII> P K</ASCII>
<Pos>0</Pos>
According to page ZIP (file_format) on Wikipedia that is the the 4 byte
signature "PK\3\4" of the first ZIP local header.
At offset 4 the version needed to extract is stored as 2 byte little endian
integer. In my examples in found version 1.0 or 2.0. That was expressed by
second XML construct like:
<Bytes>00</Bytes>
<Pos>5</Pos>
Assuming that also other versions are possible i delete that pattern.
At offset 8 the compression method is stored as 2 byte little endian
integer. In my examples in found only store (=0) or deflate (=8). That was
expressed by second XML construct like:
<Bytes>00</Bytes>
<Pos>9</Pos>
Highest possible method is AES (=99). So the upper byte is always nil. So i
keep that pattern.
At offset 14 the CRC-32 of uncompressed data is stored as 4 byte little
endian, followed by compressed size and uncompressed size of data. In my
examples these are all zero. That was expressed by XML construct like:
<Bytes>000000000000000000000000</Bytes>
<Pos>14</Pos>
This is always true if first member is an directory entry. These values can
also be zero for other data, but then these values are stored later in a
descriptor fragment. I assume that there exist samples where these values
are stored in local zip header. So i delete that construct.
At offset 26 the file name length (n) is stored as 2 byte little endian
integer. At offset 29 the extra field length (m) is stored as 2 byte little
endian integer. In my examples n value is low (like 11 for LICENSE.TXT or 32
for PluginTexturesCatalog.properties). So the upper byte is nil. In all my
examples there are no extra field after first file name. That means m value
is zero. That was expressed by XML construct like:
<Bytes>000000</Bytes>
<Pos>27</Pos>
I assume that longer file names are possible and i still keep the assumption
that first archive member has no extra field and mention this in remark
line. So this XML construct now becomes like:
<Bytes>0000</Bytes>
<Pos>28</Pos>
If m value is 0 then this has some side effects. Then after filename next
ZIP fragment starts with PK magic. So in my first efforts the library
contains mainly JPEG textures with name containing color or material
name. That was then expressed inside global strings section by lines like:
<String>PATTERN.JPGPK</String>
<String>_BRICKS.JPGPK</String>
<String>CARPET.JPGPK</String>
<String>STONES.JPGPK</String>
<String>_TILES.JPGPK</String>
<String>BROWN.JPGPK</String>
<String>GREEN.JPGPK</String>
<String>WHITE.JPGPK</String>
<String>BLUE.JPGPK</String>
<String>PINE.JPGPK</String>
<String>WALL.JPGPK</String>
<String>WOOD.JPGPK</String>
<String>_2.JPGPK</String>
<String>3.JPGPK</String>
If needed, you may also create your own SH3T files with the downloadable
Textures Library Editor. When considering also library containing only PNG
image textures such lines vanish like in MySH3T.sh3t. Then after inspecting
5 samples one line of that kind survived. That looks like:
<String>WOOD</String>
Apparently all my examples contains at least one wood like image. I assume
that there exist libraries without wood textures. So i delete that line. So
only one line in global string section remain. That looks like:
<String>PLUGINTEXTURESCATALOG.PROPERTIESPK</String>
So that apparently is the main characteristic that is the difference between
SH3T samples from ordinary ZIP archives.
With the new trid definition now all SH3T examples are described (see
appended output/trid-v-new.txt). TrID definitions and output are stored in
archive sh3t.zip. I hope that my XML file can be used in future version of
triddefs.
With best wishes
Jörg Jenderek
