I came across another CD-ROM the other day with some fun embroidery formats. It includes the HUS format I recently posted on, plus a few more.
Like I mentioned before, this is a format genre which is not normally seen in the archival world, but is fun to take a peek into the world of embroidery formats. The HUS format from Husqvarna was a unique proprietary format, but looking at another in this set, we see a common container format.
filename : 'CH1604.ofm'
filesize : 25600
modified : 2002-04-29T05:58:26-06:00
errors :
matches :
- ns : 'pronom'
id : 'fmt/111'
format : 'OLE2 Compound Document Format'
version :
mime :
class : 'Text (Structured)'
basis : 'byte match at 0, 30'
First, what is an OFM file? It is the native format for Melco branded embroidery machines. They have been around for a few years. Melco has been around since 1972, but i’m sure the format is much newer. The fact that it is in an OLE container would indicate it was created in the mid 1990’s.
Looking inside the OLE container:
Path = CH1604.ofm
Type = Compound
Physical Size = 25600
Extension = compound
Cluster Size = 512
Sector Size = 64
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
..... 19171 19456 EdsIV Object
..... 2502 2560 Design Icon
..... 130 192 Design Status
------------------- ----- ------------ ------------ ------------------------
21803 22208 3 files
The EdsIV Object seems specific. Looking back at the web archive it looks like EDS IV was software available for the Melco products. In a user manual there are three formats associated with the software:
- .CND – Condensed Format
- .EXP – Expanded Format
- .OFM – Project (Layout format)
The EdsIV Object file is unique and will work well for identification. There also seems to be some common patterns within the file that can further the correct identification.
hexdump -C EdsIV Object | head 00000000 03 00 00 00 03 00 00 00 00 00 00 00 00 00 ff ff |................| 00000010 0b 00 0c 00 43 50 72 6a 44 65 66 61 75 6c 74 73 |....CPrjDefaults| 00000020 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 f0 3f 28 00 00 00 01 00 00 00 |.......?(.......| 00000040 7f 00 00 00 00 00 00 00 00 00 39 40 00 00 00 00 |..........9@....| 00000050 00 00 10 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@............| 00000060 00 00 00 00 00 00 00 00 00 00 59 40 04 00 00 00 |..........Y@....| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 80 51 40 |..............Q@| 00000080 00 00 00 00 00 00 3e 40 00 00 00 00 00 00 2e 40 |......>@.......@| 00000090 00 00 00 00 00 80 56 40 00 00 00 00 00 80 51 40 |......V@......Q@|
The CND and EXP formats are a different matter. I ran Tridscan across all the CND samples and it could not detect one common pattern among them all.
python tridscan.py *.csd TrIDScan/Py v2.02 - (C) 2015-2016 By M.Pontello File(s) to scan found: 60 Scanning for patterns... Checking file 1/60 './Cf0103.csd' Checking file 2/60 './Cr0005.csd' Pattern(s) found: 11 Checking file 3/60 './Fd0106.csd' tridscan.py: Error: no patterns found!
Being a condensed format, I gather it might have some compression which makes for a difficult binary file to identify.
The EXP format on the other hand has a short pattern at the beginning:
hexdump -C CF0103.EXP | head 00000000 80 02 00 00 80 02 18 e7 80 02 19 e6 80 02 19 e6 |................| 00000010 80 02 19 e7 80 02 19 e6 80 02 19 e6 80 02 19 e6 |................| 00000020 80 02 19 e7 80 02 19 e6 80 02 19 e6 80 02 18 e7 |................| 00000030 00 00 fc 00 04 00 fc 00 04 ff fc 01 ed 00 ec 00 |................| 00000040 21 21 df de da 01 15 14 15 15 15 15 eb eb eb eb |!!..............| 00000050 eb eb da 00 17 17 17 17 17 18 17 17 ea e9 e9 e9 |................| 00000060 e9 e8 e9 e9 ed 00 ec 00 18 18 19 19 18 19 19 19 |................| 00000070 18 18 e8 e8 e8 e7 e7 e7 e8 e7 e8 e8 fa 01 20 00 |.............. .| 00000080 21 00 20 01 21 00 20 00 f8 1e f7 1e f7 1f f7 1e |!. .!. .........| 00000090 da 00 e6 e5 e5 e5 e5 e4 e5 e5 1a 1b 1b 1b 1b 1c |................|
Currently Melco distributes a different software for use with their embroidery machines. Their DesignShop software also works with the OFM format. Downloading a copy of version 11 and using the trial version I get access to a few OFM sample files. Let’s see if they are the same.
hexdump -C BUBBLEBOY1.ofm | head 00000000 52 49 46 46 86 e5 01 00 4f 46 4d 38 76 72 73 6e |RIFF....OFM8vrsn| 00000010 08 00 00 00 39 00 2e 00 30 00 30 00 6e 6f 74 65 |....9...0.0.note| 00000020 a8 00 00 00 ff fe ff 52 44 00 69 00 67 00 69 00 |.......RD.i.g.i.| 00000030 74 00 69 00 7a 00 65 00 72 00 20 00 3a 00 20 00 |t.i.z.e.r. .:. .| 00000040 41 00 45 00 30 00 38 00 33 00 0d 00 0a 00 46 00 |A.E.0.8.3.....F.| 00000050 61 00 62 00 72 00 69 00 63 00 20 00 3a 00 20 00 |a.b.r.i.c. .:. .| 00000060 54 00 77 00 69 00 6c 00 6c 00 20 00 0d 00 0a 00 |T.w.i.l.l. .....| 00000070 4d 00 45 00 4c 00 43 00 4f 00 20 00 2d 00 20 00 |M.E.L.C.O. .-. .| 00000080 41 00 43 00 54 00 49 00 4f 00 4e 00 20 00 49 00 |A.C.T.I.O.N. .I.| 00000090 4c 00 4c 00 55 00 53 00 54 00 52 00 41 00 54 00 |L.L.U.S.T.R.A.T.|
Well that is very different than the earlier example. We can see right away this is a different type of file, in fact the first few bytes tells us this another container format. The Resource Interchange File Format, is used in many various file formats, the most popular are WAVE, AVI, and CorelDRAW. It is a chunk based format and there are a few tools we can use to look closer.
Riffpad can open the file, but claims there is some extra data at the end. It does see four chunks and it gives us the code “OFM8”, which is what identifies this particular RIFF type.
I was also able to get some samples of version 10 of DesignShop and found they are the same OLE container. Also has the same “EdsIV Object” within the container. There is a small paragraph in the EdsIV user manual that indicates there are some versioning within the OFM format.
If you open an EDS III .OFM file and save it, it will be converted into an EDS IV .OFM file, which is no longer readable in EDS III.
Files saved in this version of EDS IV cannot be read by previous versions of EDS IV.This version of EDS IV is capable of producing two types of OFM files. Files saved as “Melco Project File (.ofm)” can only be read with this version or higher versions of EDS IV. Files saved as “Melco Version 2.00 (.ofm)” can be read by any EDS IV user that has version 2.00.006 or higher software.
It never ceases to amaze me how many formats use the Compound Object Container format. Seems like more and more are documented often. For now, I made a signature to identify the OLE and RIFF version of OFM. I’ll keep my eye out for the older EDS III and other related formats. As always, you can find my signatures and a sample file on my GitHub.