search

Brian151 / OpenShockwave

attempt at reverse-engineering and possibly re-implementing Macromedia Shockwave
Apache License 2.0
51 stars 8 forks source link

DCR DEFLATE Compression #3

Closed hqkirkland closed 7 years ago

hqkirkland commented 7 years ago

Did you guys ever figure out the exact compression format of the DCR files?

On branch IN001 of my project (/hqkirkland/DcrDecompressor/) I began using the DeflateStream in .NET. But it keeps telling me "Block length does not match it's complement." on an unusually-long chunk of data.

Suggestions regarding the error indicate that you should skip the first two bytes (0x78, 0xDA, in most of the blocks of my file). And while this works for most of the blocks, except for the 4th one on a particular file.

For the record, I also tried using the .NET wrapper library Zlibnet, but vshost.exe crashes after the third block. I'm guessing that the dll wasn't set up with a good enough structure for tracebacks.

I know that the chunk offsets I'm using are correct, because the programs do get some of the data uncompressed.

In the end I just want to get a handle on how to inflate those DCR chunks. The programs work fine for smaller files.

Brian151 commented 7 years ago

umm...dcr use zlib, not deflate/inflate i'm pretty sure. offzip decompresses them

also, one of the 'chunks' isn't a valid chunk, it's a daisy-chained collection of zlib blocks with a four byte header. i forget its exact name...

hqkirkland commented 7 years ago

ZLIB is actually DEFLATE. So I'm unsure what you mean when you say that DCRs use ZLIB. They're either a collection of GZIP files embedded into a single one, or a stream of DEFLATE-processed data.

tomysshadow commented 7 years ago

It is correct that DCR uses zlib, not DEFLATE. The only difference between zlib and DEFLATE is that zlib compression has a small header, easily recognizable by the 0x78DA at the beginning. Further complicating things, not every file is zlib compressed, though some still have a zlib header (and I'm not sure where the compression used is specified.)

For example, PNG images can be JPEG compressed without any zlib compression, in which case they can be found by searching for "JFIF," and sound often isn't "compressed" in the traditional sense at all, it's just a snd file with a low frequency and in mono. In these cases you need to skip over the first 17 bytes because there is a zlib header for seemingly no reason (??) This is presumably somehow specified in the first few sections.

The length of the sections are specified by varints. There is documentation on varints in the repository.

hqkirkland commented 7 years ago

Ok, thanks you two, I understand now. Weird way to make an algorithm/library.

Brian151 commented 7 years ago

yeah, kinda slightly unrelated, but you ever had to deal with XML DOM? god is that painful! There are parts of the API in all implementations that just contradict what you'd expect or want it to do.... >.<

hqkirkland commented 7 years ago

All you had to say was XML.

tomysshadow commented 7 years ago

I should mention that dirOpener can convert some DCRs to DIR if you want a side by side comparison.

Brian151 commented 7 years ago

I should've mentioned this, seeing as I am the one whom added it to the repo... facepalm yep, DCR and DXR can both be converted to DIR if diropener is used. The big catch is versions. It gets even worse with xtras involved. (I'm still fairly confident missing/wrong xtras caused me issues dir-opening dcrs, though.)

hqkirkland commented 7 years ago

I, too, have had some missing Xtras errors. One I can't seem to get past is the SWA Decompressor Xtra.

Brian151 commented 7 years ago

that one should be fairly common because it's widespread in use. iirc, it's one of the defaults...

hqkirkland commented 7 years ago

What's it take to fix it? Does it take more than just finding it in/applying/extacting it to %AppData% ?

Brian151 commented 7 years ago

i'm not sure... the only xtra i ever had issues with is bamovecursor

tomysshadow commented 7 years ago

Xtras are similar to DLLs. They extend the functionality of Shockwave. Some movies require certain xtras to work correctly. Xtras have a different extension depending on the platform you're on. They may be seen with a x32, w32, carb or ppc extension. Xtras can be included with a Projector EXE file, in which case they are extracted to a temporary directory.

By default, on Windows the web browser version of Shockwave puts Xtras at C:/Windows/system32/Macromedia/Shockwave 10/Xtras or C:/Windows/system32/Adobe/Shockwave 12/Xtras . If you are on 64-bit Windows, substitute system32 for SysWOW64 .

Projectors don't load Xtras from there however, because they come with their own Xtras. You can make a Projector EXE file load your own Xtras by placing the appropriate file in the Xtras directory in the same folder as the EXE (you may need to create said directory if it does not exist.)

The Xtras will need to be for the correct version of Shockwave. If the Projector EXE was made for Shockwave 8, you'll need Shockwave 8 Xtras. If it was made for Shockwave 10, you'll need Shockwave 10 Xtras.

hqkirkland commented 7 years ago

Crud. I've been mixing and matching them.

I'm mainly trying to get dirOpener to successfully open a DCR with no errors, but I keep getting complaints about a missing SWADcmp.x32 (SWA Decompressor) extra.

Brian151 commented 7 years ago

Like I just said in the "error opening DCR" issue, let's try to keep these on-topic/organized from now on. DCR indeed uses Zlib, although the various implementations of it do tend to use different names/terms for some reason.

As for Xtras, yep, they're a pain, let's discuss them somewhere else, though. Having a bunch of generally unrelated issues under the same thread could become difficult to deal with rather fast!