Shockwave .DCR file format: Difference between revisions

From Computers Wiki
Jump to navigationJump to search
(→‎Map item: Add compression type)
(Add to category)
 
(6 intermediate revisions by the same user not shown)
Line 25: Line 25:
<code> 8a 0101 8e3a 0938 2e35 2e31 2331 3034 ....:.8.5.1#104</code>
<code> 8a 0101 8e3a 0938 2e35 2e31 2331 3034 ....:.8.5.1#104</code>


The WIP branch of Shockky shows this encodes multiple version numbers.<ref>https://github.com/Earthquake-Project/Shockky/blob/18699dd2fc80ab07e86ed5e425b80ffe65270c9c/Shockky/Resources/AfterBurner/FileVersion.cs</ref>
* 0000-0005: Unknown

* 0000-0001: Variable-length integer, representing <code>0x501</code> (appears to be for compatibility with 5.x)
* 0002-0002: Unknown (<code>01</code>)
* 0003-0004: Variable-length integer, representing <code>0x73a</code> (decimal <code>1850</code>, which would imply 8.5, matching the version string, but Shockky says 9.0)<ref>https://github.com/Earthquake-Project/Shockky/blob/wip/Shockky/Resources/Enum/DirectorVersion.cs#L44</ref>
* 0005-0005: Appears to be the length of the version string
* 0006-000d: Human-readable version string (8.5.1#104)
* 0006-000d: Human-readable version string (8.5.1#104)


Line 91: Line 96:
* ????-????: Variable-length integer, representing the compression type of the data
* ????-????: Variable-length integer, representing the compression type of the data
* ????-end: Four bytes, representing the type of the item
* ????-end: Four bytes, representing the type of the item

== FGEI / IEGF ==

This appears to mark the end of the chunk-based part of the file.

* 0000-0003: Four bytes (FGEI or IEGF)
* 0004-0004: Unknown, but always seems to be <code>00</code>

After this follows many Zlib-compressed pieces.


== References ==
== References ==


<references />
<references />

[[Category:File Formats]]

Latest revision as of 05:07, 6 March 2023

These are some WIP notes on the Shockwave .DCR file format.

The file is composed of a series of chunks. Each chunk has a header consisting of a four-byte identifier and either a four-byte integer or variable-length integer for the length of the data, followed by the data itself. The identifier may be either forwards or backwards depending on the endianness of the system that created the file. The format of the chunk size (four-byte or variable) depends on the chunk type. Headers in the following document will be identified primarily by their little-endian names and secondarily by their big-endian names.

Variable-length integers are multi-byte sequences. Each byte encodes seven bits of the integer, with the high bit being 0 if this is the end of the integer, and 1 if not. The lower seven bits of the first byte correspond to the highest seven bits of the decoded integer.[1] For example, the variable-length integer 81 3a (binary 10000001 00111010) represents the integer ba (decimal 186, binary 00000000 10111010).

RIFX / XFIR

This is the first chunk in the file.

  • 0000-0003: Four bytes (RIFX / XFIR)
  • 0004-0007: Four bytes, little-endian, representing the size of the file in bytes minus eight
  • 0008-000b: Four bytes (FGDM / MDGF)

Fver / revF

This chunk follows RIFX / XFIR and appears to encode version data.

  • 0000-0003: Four bytes (Fver / revF)
  • 0004-????: Variable-length integer, representing the size of the chunk data
  • ????-end: Binary data, followed by a human-readable version string

Data sample from HatIC

8a 0101 8e3a 0938 2e35 2e31 2331 3034 ....:.8.5.1#104

The WIP branch of Shockky shows this encodes multiple version numbers.[2]

  • 0000-0001: Variable-length integer, representing 0x501 (appears to be for compatibility with 5.x)
  • 0002-0002: Unknown (01)
  • 0003-0004: Variable-length integer, representing 0x73a (decimal 1850, which would imply 8.5, matching the version string, but Shockky says 9.0)[3]
  • 0005-0005: Appears to be the length of the version string
  • 0006-000d: Human-readable version string (8.5.1#104)

The author of Shockky believes the unknown portion may be composed of multiple variable-length integers.[4]

Fcdr / rdcF

This chunk follows Fver / revF and appears to encode help text about the compression used, and something else?

  • 0000-0003: Four bytes (Fver or revF)
  • 0004-????: Variable-length integer, representing the size of the compressed chunk data
  • ????-end: Zlib-compressed data

Data sample from HatIC

The tool offzip decompresses this to 257 bytes of data.[5] 

00000000: 0300 04e9 99ac 7000 360b 0000 0800 0737  ......p.6......7
00000010: 7a34 2e98 99ac 5d00 500d 0000 0800 0737  z4....].P......7
00000020: 7a34 89a8 0472 d0af cf11 a222 00a0 2453  z4...r....."..$S
00000030: 444c 4d61 6372 6f6d 6564 6961 207a 6970  DLMacromedia zip
00000040: 6c69 6220 636f 6d70 7265 7373 696f 6e2c  lib compression,
00000050: 2063 6f6e 7461 6374 204d 6163 726f 6d65   contact Macrome
00000060: 6469 612c 2049 6e63 2e2c 2053 616e 2046  dia, Inc., San F
00000070: 7261 6e63 6973 636f 2c20 4341 004d 6163  rancisco, CA.Mac
00000080: 726f 6d65 6469 6120 6e75 6c6c 2043 6f6d  romedia null Com
00000090: 7072 6573 736f 7200 5357 4120 4465 636f  pressor.SWA Deco
000000a0: 6d70 7265 7373 6f72 2058 7472 6120 6672  mpressor Xtra fr
000000b0: 6f6d 204d 6163 726f 6d65 6469 612c 2049  om Macromedia, I
000000c0: 6e63 2e20 2028 6874 7470 3a2f 2f77 7777  nc.  (http://www
000000d0: 2e6d 6163 726f 6d65 6469 612e 636f 6d2c  .macromedia.com,
000000e0: 2063 6f6e 7461 6374 2073 7570 706f 7274   contact support
000000f0: 406d 6163 726f 6d65 6469 612e 636f 6d29  @macromedia.com)
00000100: 00

ABMP / PMBA

This appears to stand for AfterBurner Map.[6]

  • 0000-0003: Four bytes (ABMP or PMBA)
  • 0004-????: Variable-length integer, representing the size of the chunk data (including the few bytes after this and before the compressed map)
  • ????-????: Variable-length integer, representing some sort of identifier, appears to always be 00
  • ????-????: Variable-length integer, representing the size of the decompressed map
  • ????-end: Zlib-compressed map

Zlib-compressed map

Decompress the map with Zlib before continuing.

  • 0000-????: Variable-length integer, unknown
  • ????-????: Variable-length integer, unknown
  • ????-????: Variable-length integer, representing the number of items in the map
  • ????-end: A series of map items

A series of items follows.

Map item

Do note the actual data for the item is not in the ABMP chunk.

  • 0000-????: Variable-length integer, representing some kind of ID of this item
  • ????-????: Variable-length integer, representing an offset
  • ????-????: Variable-length integer, representing the compressed size of the item's data
  • ????-????: Variable-length integer, representing the decompressed size of the item's data
  • ????-????: Variable-length integer, representing the compression type of the data
  • ????-end: Four bytes, representing the type of the item

FGEI / IEGF

This appears to mark the end of the chunk-based part of the file.

  • 0000-0003: Four bytes (FGEI or IEGF)
  • 0004-0004: Unknown, but always seems to be 00

After this follows many Zlib-compressed pieces.

References

  1. ↑ https://github.com/Earthquake-Project/Shockky/blob/1308dc7ff0ac2347dcd5f3879bce1eac54e1992e/Shockky/IO/ShockwaveReader.cs#L173
  2. ↑ https://github.com/Earthquake-Project/Shockky/blob/18699dd2fc80ab07e86ed5e425b80ffe65270c9c/Shockky/Resources/AfterBurner/FileVersion.cs
  3. ↑ https://github.com/Earthquake-Project/Shockky/blob/wip/Shockky/Resources/Enum/DirectorVersion.cs#L44
  4. ↑ https://github.com/Earthquake-Project/Shockky/blob/master/Shockky/Chunks/FileVersionChunk.cs#L18
  5. ↑ https://aluigi.altervista.org/mytoolz.htm#offzip
  6. ↑ https://docs.google.com/document/d/1jDBXE4Wv1AEga-o1Wi8xtlNZY4K2fHxW2Xs8RgARrqk/edit#heading=h.x638haejy3bd
Retrieved from "https://computers.huntertur.net/index.php?title=Shockwave_.DCR_file_format&oldid=524"