Reservoir Dogs [.PC files]

[prysm]

The contents of this post was deleted because of possible forum rules violation.

[Savage]

The audio are raw pcm, no headers found or Id's
In the botton of the 1rst file (s_0_training.pc) you can see some information

Code: Select all

 SBNKSAMP        0_training.sbk alarm_loop.wav impact_concrete_1.wav bone_crack.wav 

[prysm]

Savage, if I understood your words correctly - the audio can't be extracted, right? Do all 5 files can't be extracted or some of them?

[Kataah]

Only downloaded the first part (s_0_training.pc) - it simple pcm 16bit little endian - you dont need headers - try a simple audio editor like goldwave

[aluigi]

the following BMS script extracts all the files from the PC archive:

*edit* use the script of mr.mouse some posts below

from what I have seen some files are in raw pcm mode and have a minimal header at their beginning (samples, frequency, channels and so on) while the others are all in the PS2 VAG ADPCM and almost all have an interleave value of 8000 (in blue_tutorial_radiobackupgeneral_2.wav.str I don't know what's the right value).

[Mr.Mouse]

bugtest, nice work! I'd appreciate it greatly if you'd also post the structure of a file, besides a BMS script. This will help everyone understand the format.

[aluigi]

eh eh eh I'm so lazy that I created a new tool for making my work quicker and you ask me to do additional work? :)

usually the BMS scripts are very basic and easy to understand so I guess it's useless to document the file format in other additional forms spending more time for doing it than doing the reversing+bms job.

in this case the only particular thing was in the offsets which are all divided by 16.
in the playstation stuff is enough normal to use sectors as reference for offsets and sometimes sizes but it's ever set to 2048 bytes (size of mode1 CD-ROM sectors) while in this case it's set to 16 for some unknown reason (probably it was 2048 on PS2 and then was changed to 16 in the PC port)... it's only a hypothesis.

[Mr.Mouse]

Unfortunately, bugtest, the format of these .pc files is a little different.

Here's my MexScript that will extract the resources and match them with the correct filename.

Code: Select all

GoTo 12 0;
Get FILES Long 0;
Get INFO_OFF Long 0;
Get SBNK_OFF Long 0;
GoTo 40 0;
Get NAMES_OFF Long 0;
Math INFO_OFF *= 16;
Math SBNK_OFF *= 16;
Math NAMES_OFF *= 16;
For i = 1 To FILES;
GoTo INFO_OFF 0;
Get OFFSET Long 0;
Get DUMMY Long 0;
Get SIZE Long 0;
Get NAMEOffset Long 0;
Get DUMMY Long 0;
Get DUMMY Long 0;
Get DUMMY Long 0;
Get DUMMY Long 0;
SavePos INFO_OFF 0;
Math NAMEOffset += NAMES_OFF ;
GoTo NAMEOffset 0;
Get NAME String 0;
Math OFFSET *= 16;
Log NAME OFFSET SIZE 0 0;
Next i;

Here's the .BMS to add to your MultiEx Commander using the BMS-->Add BMS to MRF... option so you can open any .PC file with MultiEx Commander the normal way.

pc.zip

The QuickBMS script assumed that the files were saved in chronological order in the archive, which they are not exactly. The FileName table lists the names, but in a different order than the INFO_OFF table. In fact, the variable that comes after the SIZE variable in the INFO_OFF table is not a trivial one: it is the pointer to the correct filename in the NAMES_OFF table.

All of these .pc files have the 'FileNameTable.pak.sys' resource entry. It was natural to assume that the INFO_OFF table would match the actual offset and size of this entry.

[aluigi]

ops the names offsets, I should pay more attention when I do this stuff... but I'm lazy :)

[Mr.Mouse]

I would not call you lazy at all, looking at your energy to create a lot of tools.

Perhaps a little 'careless', then... (Just like : you have been thanked a lot by people, but were to careless to thank others )

Anyway, I've had my own share of mistakes in format demystification, it's only human. eh eh

[prysm]

Thanks for Your help, guys! Appreciate it!

I'll try the script you've made, Mr.Mouse