Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on February 16, 2024, 01:19:07 AM »
Updated:
  • Javelin Driver (DRV)
  • Autodesk Inventor Assembly (IAM)
  • Autodesk Inventor Part (IPT)
  • Microsoft Image Composer graphics (MIC)
  • Standard ACIS Text (SAT)
  • MakerBot 3D print format (X3G)
Added:
  • Microsoft MS-DOS setup binary patch format ()
  • BlackHole compressed archive (BH)
  • Pac-in-Time game data (BIN)
  • MRNZ installer/obfuscated format (CO_/EX_/SY_)
  • DCM 3D model (generic) (DCM)
  • DCM 3D model (with annotations) (DCM)
  • Oracle Data base Diagram (ODD)
  • Melco DesignShop Project (OFM)
  • Packages Project (PKGPROJ)
  • Standard ACIS Binary (SAB)
  • Oracle TPX Template (TPX)
  • Parasolid model (Binary) (X_B)
  • Parasolid model (Text) (X_T)
22
There's a 2KB limit for the fixed pattern area, both practical and "historic" reasons.
It may change in the future, but it would probably part of some major changes.
Sorry but I can't make any promises.
23
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on February 11, 2024, 11:30:11 PM »
Updated:
  • Finale ETF Enigma Tansportable File (MUS/ETF)
Added:
  • ArmSI Speed Index timings data ()
  • Finale music score (v1.0 ) ()
  • Finale music score (v1.8 ) ()
  • Finale music score (v2.6 ) ()
  • Central Point PC Backup Directory data (DIR)
  • Generic PC disk image (NTFS) (DSK/IMG)
  • 16bit DOS EXE Ady's GLUE combined (v1.10) (EXE)
  • 16bit DOS EXE PACKWIN compressed (EXE)
  • 16bit Win EXE PACKWIN compressed (EXE)
  • 16bit Win EXE PACKWIN compressed (with stub) (EXE)
  • Finale Performance Assessment (FPA)
  • HOOPS 3D Metafile Format (generic) (HMF)
  • HOOPS 3D Metafile Format (v1.x) (HMF)
  • HOOPS 3D Stream Format (v18.x) (HSF)
  • HOOPS 3D Stream Format (v19.x) (HSF)
  • JuggleKrazy Ladder diagram (LAD)
  • EdWord Macro (MACRO)
  • Novell NetWare Namespace module (NAM)
  • Norton pcAnywhere Remote session Log (RL6)
  • JuggleKrazy Tutorial (TUT)
24
TrID File Identifier / overcome size limits (USHRT_MAX) in tridscan.py triddefspack.py
« Last post by jenderek on February 08, 2024, 10:19:42 PM »
Hello trid users,

some days ago i read an article about emulation of old commodore computer.  In
that context disc image with D64 file name extension are mentioned.

So i run trid utility on such examples with D64 suffix. The samples are
"recognized" and described wrong as "null bytes" because many samples contain
nil byte at the beginning. Or samples are described wrong as "MacBinary 1",
"Adobe PhotoShop Brush" "Sybase iAnywhere database files" because the
corresponding definitions contains only few and nil bytes at the beginning.
(see appended trid-v-old.txt in output).

For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here the samples are also not
recognized.

For comparison reason i also run file command (version 5.45) on such samples.
Here most of the samples are recognized and most are described as "D64 Image"
(see appended file-k-5.45.txt in output).

Luckily i found about D64 on file formats archive team web server. So this
expressed inside new TrID definition d64.trid.xml by line like:
   <RefURL>http://fileformats.archiveteam.org/wiki/D64</RefURL>

But when i refine definition by running tridscan on more samples than most
patterns vanish and i get few nil byte patterns at the beginning like:
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>0</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>256</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>512</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>768</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>1024</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>1280</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>1536</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>1792</Pos>
   </Pattern>

But when running here tridscan with samples brucelee.d64 i get error message
like:
TrIDScan/Py v2.02 - (C) 2015-2016 By M.Pontello

File(s) to scan found: 1
Scanning for patterns...
Checking file 1/1 '.\brucelee.d64'
tridscan.py: Error: no patterns found!

But i know that there must exist some shared patterns, because file command
recognize most examples. So i looked inside Magdir/c64 fragment of file
sources and looked how there the recognition happens. There at offset 16500h
(=91392 decimal) check for 4 byte sequence 12014100 is done. So i create
manually a definition like d64-bad.trid.xml with translated pattern. when now
running triddefspack i get error message like:
Building files list...
No update!
Found 12 definitions.
Reading...
Packing...
Traceback (most recent call last):
  File "C:\PROGS\trid\triddefspack.py", line 362, in <module>
    main()
  File "C:\PROGS\trid\triddefspack.py", line 329, in main
    defdatanew = trdbuild(deflist, CMD["strip"])
  File "C:\PROGS\trid\triddefspack.py", line 235, in trdbuild
    defsdata.append(trddef2bin(triddef, stripflag))
  File "C:\PROGS\trid\triddefspack.py", line 207, in trddef2bin
    PatBlock.append(pack("<HH", pos, len(patbytes)) + patbytes)
struct.error: ushort format requires 0 <= number <= USHRT_MAX

So is it possible to change some size limits inside TrID tools that D64 disc
images can be recognized?

I would be pleased to get at least some hints. Thanks
Jörg Jenderek
25
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on February 08, 2024, 01:19:20 PM »
Updated:
  • CA Visual Objects Application Export File (v1.x) (AEF)
  • eDrawings part (v 2008) (EASM/EPRT/EDRW)
  • Python Egg (EGG)
  • HOOPS 3D Stream Format (generic) (HSF)
  • MusicXML (MUSICXML)
  • IFF binary Patch (PCH/PATCH)
Added:
  • MLT framework AV preset ()
  • MLT framework AV preset (var.2) ()
  • MLT/melt script ()
  • ATIS DVR/dashcam firmware (BIN)
  • Abuse demo Data (v1) (DAT)
  • HAV video (HAV)
  • HOOPS 3D Stream Format (v12.x) (HSF)
  • HOOPS 3D Stream Format (v13.x) (HSF)
  • HOOPS 3D Stream Format (v14.x) (HSF)
  • HOOPS 3D Stream Format (v8.x) (HSF)
  • MLT XML document (MLT)
  • MNX Music Notation (MNX)
  • MusicXML (compressed) (MXL)
  • VDA-FS CAD data exchange format (VDA)
  • VideoMach Project (VMP)
  • Actimagine Video (VX)
Deleted:
  • CA Visual Object Application Export File (AEF)
26
TrID File Identifier / Re: updated egg-python.trid.xml for Python Egg
« Last post by Mark0 on February 08, 2024, 11:54:31 AM »
Thanks!
27
TrID File Identifier / Re: updated iff-pch.trid.xml for IFF binary Patch
« Last post by Mark0 on February 08, 2024, 11:49:52 AM »
Thanks for the update!
28
TrID File Identifier / updated egg-python.trid.xml for Python Egg
« Last post by jenderek on February 08, 2024, 03:14:56 AM »
Hello trid users,

some days ago i must update my python package. From previus version an
program/library directory remains with files inside. So i look at file types
remaining there. On type has file name suffix EGG. So i look for such files on
my systems.

So i run trid utility on such examples with EGG suffix. Many of the samples
are "recognized" and described with highest priority as "Python Egg" without
mime type by egg-python.trid.xml. But many are only described as "ZIP
compressed archive" with mime type application/zip by ark-zip.trid.xml (see
appended trid-v-old.txt in output).

For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here the samples are recognized
generic and described as "ZIP Format" by PUID x-fmt/263. Here Egg suffix is
considered as "bad".

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
"Zip archive data" (see appended file-5.45.txt in output). Here also generic
application/zip mime type is shown (see appended file-i-5.45.txt in output )
and no suffix is here shown (see appended file-ext-5.45.txt in output ).

On Linux according to shared MIME-info database such samples are called " "Zip
archive" Here "application/zip" is used as mime type. The samples are just
recognized by looking for 4 byte sequence PK\003\004 at the beginning. Here 2
suffix are listed (*.zip *.zipx). That information can be seen in source
freedesktop.org.xml.in found for example on gitlab.freedesktop.org.

The samples are described correctly as ZIP. That is expressed by first XML
construct. That looks like:

   <Bytes>504B0304</Bytes>
   <ASCII> P K</ASCII>
   <Pos>0</Pos>

The zip content can be seen by running unpacking tools (like 7z unzip see
appended 7z-l-slt.txt 7z-l.txt unzip-lv.txt unzip-Z.txt in output).

The sub classification is done by lines inside global strings section. These
looks like:

   <String>TOP_LEVEL.TXTPK</String>
   <String>__INIT__.PYCPK</String>
   <String>PKG-INFOPK</String>
   <String>ZIP-SAFEPK</String>
   <String>EGG-INFO</String>
   <String>S.PYCPK</String>
   <String>S.TXTPK</String>
   <String>SOURCE</String>

After running tridscan on undetecxted samples now i look what has changed.

One line vanished. That was.

   <String>__INIT__.PYCPK</String>

Most samples contain a python module with name __init__.pyc. But in some samples
(like example-21.12-py3.6.egg vboxapi-1.0-py3.11.egg) the moduel name is like
__init__.cpython-36.pyc inside __pycache__ directory and some packages (like
esptool-2.5.1-py2.7.egg) do not have simialar module.

In one line the s letter befor point vainhed. The old line looks like:

   <String>S.PYCPK</String>

So this now becomes like:

   <String>.PYCPK</String>

In recognizeds samples i founf modues with names like:

adatags.pyc
batchtags.pyc
conftags.pyc
CppSemantics.pyc
cpptags.pyc
difftags.pyc
dtags.py

That triggereed the old line. The undetected samples also contain python
module with PYC file name suffix, but there the main names have no s character
as last character of main name.

For such files i found no mime type. But the egg are a sub class of
ZIP container. So in my opinion the pytheon eggs should at least get then the mime type of
container. So this is now expressed by line like:

   <Mime>application/zip</Mime>

With the updated definition now all my inspected Pythion EGG files recognized
(see appended trid-v-new.txt in output).

TrID definition and output are stored in archive egg_.zip. I hope that
my definition can be used in future version of triddefs.

With best wishes
Jörg Jenderek
29
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on February 06, 2024, 12:33:11 AM »
Updated:
  • Rosegarden score (ungzipped) (XML/RG)
Added:
  • FastSpr sprite (v1) ()
  • FastSpr sprite (v2) ()
  • VTech Genius cartridge image ()
  • CA Visual Objects Application Export File (v1.x) (AEF)
  • Animation Magic video/Animation (v1) (ANI)
  • Animation Magic video/Animation (v2) (ANI)
  • CA Visual Objects Application (v1.x) (APP)
  • Bome MIDI Translator Project (BMTP)
  • Bome MIDI Translator Project (signed) (BMTP)
  • Videoton TV-Computer tape image (CAS)
  • Win16 EDI Install Pro executable (EXE)
  • Space Quest V Font (FON)
  • Cryptic Studios game data (generic) (HOGG)
  • Star Trek Online game data (HOGG)
  • CA Visual Objects ADAM Index (IND)
  • CA Visual Objects Module Export File (v1.x) (MEF)
  • CA Visual Objects Prefix (PFX)
  • Rosegarden composition (var.1) (RG)
  • Rosegarden composition (var.2) (RG)
  • CA Visual Objects sys atom table (VO)
  • Lomax World game data (WLD)
  • Rosegarden note style (XML)
30
TrID File Identifier / updated iff-pch.trid.xml for IFF binary Patch
« Last post by jenderek on February 04, 2024, 03:22:53 PM »
Hello trid users,

some days ago i must handle some patch files. Sometimes the file name suffix
PCH is used. For control reason i look for samples with that suffix on my
systems. In context of "Amiga" operating system i found such samples.

So i run trid utility on such examples with PCH suffix. The samples are
"recognized" and described as "IFF binary Patch" with mime type
application/octet-stream and 2 suffix (.PCH/PATCH) by iff-pch.trid.xml. No
reference URL is listed here (see appended trid-v-old.txt in output).

For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here the samples are recognized
generic and described as "Interchange File" by PUID x-fmt/157. Here PCH suffix
is considered as "bad".

For comparison reason i also run file command (version 5.45) on such samples.
Here the samples are also "recognized". These are here described as "IFF data"
and "PTCH binary patch" (see appended file-5.45.txt in output). Here also
generic application/octet-stream mime type is shown (see appended
file-i-5.45.txt) and no suffix is here shown (see appended file-ext-5.45.txt).

On Linux according to shared MIME-info database such samples are called "IFF
file" or as alias expanded "Interchange File Format".  Here "application/x-iff
is used as mime type. The samples are just recognized by looking for 4 byte
sequence FORM at the beginning. Here no suffix are listed. That information
can be seen in source freedesktop.org.xml.in found for example on
gitlab.freedesktop.org.

The samples are also described with low priority as "Generic IFF container"
with mime type application/x-iff by iff-gen.trid.xml. Here page about
"Interchange File Format" on Wikipedia is used as reference. So "Generic IFF
container" is "container" format for such Amiga patches because file start
with characteristic 4 byte magic. That is expressed by first XML
construct. That looks like:
   <Bytes>464F524D</Bytes>
   <ASCII> F O R M</ASCII>
   <Pos>0</Pos>

The sub classification is done by 4 byte pattern at offset 4. That is
expressed by second XML construct. That looks like:
   <Bytes>5054434856455253</Bytes>
   <ASCII> P T C H V E R S</ASCII>
   <Pos>8</Pos>

This sub classification information can be found on page about IFF FORM and
Chunk Registry on Amiga OS web server. So i choose this instead of generic
Wikipedia page. So here this is now expressed by line like:
 <RefURL>https://wiki.amigaos.net/wiki/IFF_FORM_and_Chunk_Registry</RefURL>

For such files i found no mime type. But the patches are a sub class of
IFF. So in my opinion the patches should at least get then the mime type of
container. So this is now expressed by line like:
   <Mime>application/x-iff</Mime>

With the updated definition my inspected Amiga patches are still described but
now more details like mime type and reference is also shown (see appended
trid-v-new.txt in output).

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

With best wishes
Jörg Jenderek
Pages: 1 2 [3] 4 5 ... 10