Hello trid users,
Some days ago i handle some CD-ROM images. The standard format has a suffix
like iso. But especially on Windows also some other formats are used. One
format use IBB as suffix.
So i looked for such files on my system. Such samples like
AKOYA-RECOVERY.IBB md6471.ibb were created by myself via CD-burning tool
ImgBurn.
So i run trid utility on such IBB examples. All are described in principal
correct as "Text - UTF-16 (LE) encoded" by txt-utf-16-le.trid.xml but with
wrong suffix TXT (See appended output/trid-v-old.txt).
For comparison reason i also run file command (newest version 5.44) on such
samples. Here these are described as "Unicode text, UTF-16, little-endian
text" with sub classification "[with CRLF line terminators"] (See appended
output/file-5.44.txt) and with mime type text/plain (See appended
output/file-i-5.44.txt) and no extension (see appended
output/file-ext-5.44.txt).
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This does not describe
such IBB samples.
Unfortunately i found no page about the used text file format and especially
from ImgBurn. So i i don use ImgBurn home page
www.imgburn.com as
reference. Instead i choose ImgBurn page on Wikipedia. This is expressed by
line like:
<RefURL>
https://en.wikipedia.org/wiki/ImgBurn</RefURL>
Apparently the IBB examples are just used simple text files in INI like
format but encoded as UTF-16 in little endian format. So i can use the
generic mime type text/plain. But instead i use a more specific user defined
one. So this is now expressed by line like:
<Mime>text/x-ibb</Mime>
So i run tridscan on such IBB samples to generate ibb.trid.xml. Apparently
IBB samples always contains the same start. Apparently all IBB samples start
with same 4 same lines like:
IBB
[START_BACKUP_OPTIONS]
BuildInputMode=2
Because these text lines are encoded as UTF-16 little endian with carriage
return line feed terminators and byte order mark (BOM at the beginning) this
is expressed by first XML construct that looks like:
<Bytes>FFFE4900420042000D000A000D000A005B00530054004100520054005F004200410043004B005500500
<ASCII> . . I . B . B . . . . . . . . . [ . S . T . A . R . T . _ . B . A . C . K . U . P
<Pos>0</Pos>
Line number 5 looks like:
BuildOutputMode=2
Again this encoded as UTF-16 little endian with carriage return line feed
terminators this is expressed by second XML construct like:
<Bytes>000D000A004200750069006C0064004F00750074007000750074004D006F00640065003D00</Bytes>
<ASCII> . . . . . B . u . i . l . d . O . u . t . p . u . t . M . o . d . e . =</ASCII>
<Pos>95</Pos>
Line number 6 looks like:
Destination=
Again this encoded as UTF-16 little endian with carriage return line feed
terminators this is expressed by third XML construct like:
<Bytes>000D000A00440065007300740069006E006100740069006F006E003D00</Bytes>
<ASCII> . . . . . D . e . s . t . i . n . a . t . i . o . n . =</ASCII>
<Pos>133</Pos>
These informations are also found inside the global strings section. Because
of UTF-16 encoding these are expressed by lines like:
<String>B'U'I'L'D'I'N'P'U'T'M'O'D'E</String>
<String>B'U'I'L'D'O'U'T'P'U'T'M'O'D'E</String>
<String>D'E'S'T'I'N'A'T'I'O'N</String>
<String>I'B'B</String>
<String>S'T'A'R'T'_'B'A'C'K'U'P'_'O'P'T'I'O'N'S</String>
Line number 7 often looks like:
DataType=1
These line start at different offsets. So this information is only expressed
inside global strings section. Because of UTF-16 encoding this is expressed
by line like:
<String>D'A'T'A'T'Y'P'E</String>
Because at higher offsets variable value assignments occur and these names
are ASCII like encodes as UTF-16 I get many one byte nil sequences like:
<Pattern>
<Bytes>00</Bytes>
<Pos>163</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>2043</Pos>
</Pattern>
Because these are not use full for recognition and takes space so i delete
such patterns.
With the new trid definition now my IBB examples are described (see appended
output/trid-v-new.txt). TrID definitions, some samples and output are stored
in archive Project_Files.zip. I hope that my definition can be used in
future version of triddefs .
With best wishes
Jörg Jenderek
