Cyberflix/DreamFactory Engine Games

[Puterboy1]

Would anyone like to create a script that extracts the file archives used in games like Dust and Titanic: Adventure Out of Time?

Here are the examples: https://drive.google.com/open?id=1a1FEG ... 08QOvKTJmA

Data for Titanic: Adventure Out of Time: https://drive.google.com/open?id=1YyvdE ... MI3LwKbtTN

[aluigi]

In what file types are you interested?
The SET files are probably some video format ("LPPALPPA"): https://forum.videohelp.com/threads/334 ... ost2072652

[Puterboy1]

In what file types are you interested?
The SET files are probably some video format ("LPPALPPA"): https://forum.videohelp.com/threads/334 ... ost2072652

The .TRK and .SFX files which contain the audio. After that, you can work on the rest if you have time.

[aluigi]

They are all this LPPALPPA format which doesn't look like an archive or doesn't have a clear format.

[Puterboy1]

They are all this LPPALPPA format which doesn't look like an archive or doesn't have a clear format.

I think it’s an Apple format. Check out all the other attempts at extracting/converting the score online and see what you and the staff can do. Or just look for the user who uploaded high-definition versions of TAOOT’s score on YouTube. He claims to have made a script that extracts the .TRK files.

This is the user: https://www.youtube.com/channel/UCopf15 ... IQ7HSw6ipg

[aluigi]

In my opinion it's more like a module tracker format, a sort of MIDI file with custom instruments.
The reason is simple, there are names of instruments and PCM audio used for them.

[Puterboy1]

So is there any high chance of them being extracted and converted into a playable format? If you are this interested, we may have to resort to contacting the Cyberflix developers.

[Puterboy1]

Update: Silkhedgehog has no plans of releasing his tools and extractors for the game “at this time” because....:

“I don't have the time to walk people through using my toolset, it's a personal project rather than something I've built for release that can be supported, bug free etc.”

We need to further convince him.

[aluigi]

It doesn't seem he has really some tool.
It looks more like a step-by-step for, maybe, forcing the game to play a specific music that can be recorded directly from the computer, maybe with the game running in a virtual machine since they are very old. That would explain the low quality of the recording.

Anyway the following script dumps all the referenced data in these LPPALPPA files:

Code: Select all

goto 0x20
idstring "LPPA"
goto 0x14
get FILES long
goto 0x30
findloc OFFSET binary "PALP"
math OFFSET + 0x2c
goto OFFSET
for i = 0 < FILES
    get OFFSET long
    savepos TMP
    goto OFFSET
    get ID long
    get SIZE long
    savepos OFFSET
    goto TMP
    log "" OFFSET SIZE
next i

Don't ask me what to do with the extracted files since they are just game resources and nothing easy to use.
At least now you can extract all the data.

*edit* updated script

[Puterboy1]

Thanks, and by the way, maybe these efforts from the sister site can help you: http://forum.xentax.com/viewtopic.php?f=10&t=17905

[Puterboy1]

I thought I could start the ball rolling again by updating the script with Samurai’s code and findings, taken verbatim from the Xentax forum:

All numbers are in little-endian byte order.

Container Format
As far as I've seen, the major DreamFactory data files (TRK, STG, MOV, PUP, SET) are all based around a similar container format.

Each container file is divided into blocks, and each block can contain a wide variety of data.

Let's look at the Titanic file BOMBBLOW.MOV (In the GOG version, it's in the LOCAL directory; In the CD version, it's on Disc 1 in the BOMB directory.)

Header
The first 1024 bytes of the container comprise some metadata about the file:

Code: Select all

[0-3]        int32   FourCC code, should be 65536 (0x00 0x00 0x00 0x01)
[4-7]        int32   Length of the container file in bytes
[8-19]       ????
[20-23]      int32   Number of blocks in the container.  In the example below, there are 164 blocks in the container.
[24-1023]    ????

Here's an excerpt of the file header from BOMBBLOW.MOV:

Code: Select all

0000000: 0000 0001 1d80 0017 0000 0000 0000 0000
0000010: 0100 0000 00a4 0000 0000 0000 0000 0000
0000020: 504c 4150 504c 4150 0000 0000 0000 0000
0000030: 0000 0000 0000 0000 0000 0000 0000 0000

Additional notes about the header:
Bytes 32-39 often spell out "LPPALPPA", but I'm not sure what that means.

There is additional data from 512-1023, and it may be compressed with some simple variant of LZ compression??? I'm really not sure, but I can sometimes see strange fragments of text.

Block Offset Table
There's a "block offset table" that starts at byte 1024. It's basically an array of int32 offsets, one for each block in the container.
The number of entries in the table corresponds to the number of blocks specified in the header. In this example, there are 164 entries.

Here's an excerpt of the block offset table, starting at byte 1024:

Code: Select all

0000400: 0800 0000 1d80 0000 1ec0 0000 1f40 0000
0000410: 1f80 0000 1800 0001 9f40 0001 a3c0 0001
0000420: a300 0002 a780 0002 dd40 0002 e1c0 0002
0000430: 1dc0 0003 2240 0003 5fc0 0003 6440 0003
0000440: a080 0003 a500 0003 e200 0003 e680 0003
0000450: 2380 0004 2800 0004 6540 0004 69c0 0004

In the example, the first block offset is 2048, the second is 7552, the third is 7872, and so on.

Blocks
To read each block, seek to the offset given in the block offset table, and read until you reach the start of the next block offset (or the end of the file).

Most blocks should be at least 8 bytes long, but I've occasionally seen some that are only 4 bytes long (and don't have a byte length number).

Block format:

Code: Select all

[0-3]        int32   Block ID
[4-7]        int32   Length of the block in bytes
[8-end]      block data

Formats of each type of block
I haven't yet figured out where the type of each block is stored, but I have been able to figure out some parts of some of the blocks just by observation and patterns.

For video files, there tend to be one or two metadata blocks near the beginning.

Then a little later (if the movie has audio), there's 1 or more blocks of audio data, probably to fill the audio buffer when the movie starts playing.

Then you'll see a list of alternating blocks.
The larger ones are video frames, and the smaller ones most likely contain pallete information (since these games use 8-bit color).

Here's a listing of the first 20 blocks in the BOMBBLOW.MOV file:

Code: Select all

ID=0     Offset=2048     Size=5490    Metadata block
ID=1     Offset=7552     Size=270     ???
ID=2     Offset=7872     Size=92      ???
ID=3     Offset=8000     Size=4       ???
ID=4     Offset=8064     Size=63574   Audio block
ID=5     Offset=71680    Size=34603   Audio block
ID=6     Offset=106304   Size=1094    Pallete?
ID=7     Offset=107456   Size=65312   Frame
ID=8     Offset=172800   Size=1094    Pallete?
ID=9     Offset=173952   Size=13728   Frame
ID=10    Offset=187712   Size=1094    Pallete?
ID=11    Offset=188864   Size=15332   Frame
ID=12    Offset=204224   Size=1094    Pallete?
ID=13    Offset=205376   Size=15725   Frame
ID=14    Offset=221120   Size=1094    Pallete?
ID=15    Offset=222272   Size=15381   Frame
ID=16    Offset=237696   Size=1094    Pallete?
ID=17    Offset=238848   Size=15595   Frame
ID=18    Offset=254464   Size=1094    Pallete?
ID=19    Offset=255616   Size=15576   Frame

Metadata blocks
I really don't know much about the structure of these yet; however, they do contain an index of filenames or asset names.
So I'm guessing they also contain information about each block type. I just haven't figured out how to decode them yet.

In the BOMBBLOW.MOV example, at file offset 4254, you'll see an 8-bit number indicating the length of the text string (0x6) followed by 6 characters of text "Frame1".

If you can figure out the structure of this metadata block, that would be wonderful!

Audio blocks
I've figured out the following about audio blocks:

Code: Select all

[0-3]        int32   Block ID
[4-7]        int32   Length of the block in bytes
[8-11]       int32   Special FourCC, typically always 65536, indicating that this is an audio block.
[12-33]      ????
[34-35]      int16   Some flag, maybe to indicate stereo, or bit depth mode, or something??
[36-37]      int16   Audio sample rate, typically 22050 in the files I've looked at so far, which is a very normal audio sample rate.
[38-47]      ????
[48-51]      int32   Number of audio offset table entries

Byte 52 marks the start of an array of int32 values that appear to be offsets in the audio block. The number of items in the table is the number stored in the block header at byte offset 48.
I'm not sure what they are for. Maybe they are markers for when to display a frame as the audio plays???

After the offset table is the actual audio data. The offset to the audio data appears to be: (number of audio offsets) * 4 + 56

The audio data itself, I am about 99% sure, is some form of ADPCM, in a 4:1 compression ratio (4-bit numbers that map to a delta lookup table, producing 16-bit audio).
I've tried decoding some of the data using common Microsoft ADPCM and IMA ADPCM algorithms, but it didn't produce anything normal sounding. I might have messed up, though, so don't count those out without investigating further.
Finding out what delta encoding table Cyberflix uses might mean firing up the assembly debugger...

Pallete blocks
These most likely contain more than just pallete data, but I haven't figured out what yet.
They are always the same size within a given video file (>1024 bytes), but the size varies slightly between video files.
I would normally expect a full pallete table to be 768 bytes, so maybe these have alpha information as well, and maybe they have additional metadata used for decoding the frame.

Frame blocks
I don't know much about these except that the video codec itself is based on some form of vector quantization of 4x4 pixel blocks.

There's some block header info, though:

Code: Select all

[0-3]        int32   Block ID
[4-7]        int32   Length of the block in bytes
[8-9]        int16   Video height, in pixels (ex: 384)
[10-11]      int16   Video width, in pixels (ex: 512)

Conclusion

[Puterboy1]

This user M3tox, has managed to create a tool to extract these items: https://github.com/M3tox/DFET/releases/tag/0.71