Conduit gcs/gcm files by pietastesgood at 8:34 PM EDT on June 24, 2009
The Conduit just came out today, and from the samples i've heard the score is going to be great. However, the game is divided into many small archives with the extensions gcs and gcm. I can see riff headers but the archives somehow seem to be compressed.
I agree that it looks compressed. The stream data, however, is uncompressed (I see plain DSP at the end of the gcs). This isn't going to do much good, however, as it appears that the headers are in the compressed section (as there are no headers in evidence with the raw DSP and the RIFFs seem to be in there).
Ok, thanks anyways. Hopefully someone can still help me out with this compression issue. :)
Edit:
Or, is there a way I can reverse engineer the header, so I can manually extract the uncompressed audio data out from the archive and add it on to the header?
The standard header is documented on the vgmstream wiki. The major thing missing is the table of decode coefficients. It suppose might be possible to work this out backwards from the sample data, but I wouldn't know how to go about it if it was. Consider the format used in MadWorld, where I had to work out an encryption scheme before I could read the header. This seems to be a similar situation, and it might be possible to work it out from the game executable also.
Considering that I'm unlikely to do it myself, yeah that'd be helpful. If you could post all of the gcs files, that might work, too. It might be more obvious with more samples to work from.
Worked out the compression, but that turned out to be the easy part. Now trying to figure out how to match up the data with the headers.
---
The layout is continuing to frustrate me. If someone else wants to take a look, here's the stuff I have on hand right now:
weconduit 0.0 does the decompression. dump00.bin contains headers, dump01.bin is a map of what's in dump00.bin. weconduit identifies the end of the last compressed segment; the first uncompressed segment is soon thereafter (seems to be aligned by 0x800). I've been unsuccessful in trying to match the DSP data in the uncompressed segment with the headers in dump00.bin.
The audio headers in dump00.bin are approximately RIFF WAVE, and I wrote cnd_dmp2genh 0.0 to parse those and generate GENHs from it. Each RIFF has a strm chunk that specifies the size and offset of the stream data in the uncompressed segment, but there are several (possibly three) uncompressed segments and I've failed at locating any but the first. I didn't provide a compiled version because as it stands it produces mostly junk.
Made a wee bit more progress today weconduit 0.1, cnd_dmp2genh 0.1. Run weconduit on a .gcs (like 99_98.gcs), then run cnd_dmp2genh on the dumped stuff: cnd_dmpgenh dump01.bin dump00.bin dumpUC00.bin dumpUCmstr.bin dumpUC01.bin
The ordering of the various uncompressed dumps is still a matter of some confusion. I'm getting a lot of really weird files as well (MultiPlayer-Song1.wav.genh at 5khz or so), so there may yet be bugs to work out of the decompression. Having a whole lot of trouble finding any actual interesting music so got discouraged.
edited 11:33 AM EDT September 6, 2009
by pietastesgood at 2:12 PM EDT on September 6, 2009
Great! Will try this new build out.
Any updates? by pepper at 8:52 PM EDT on September 23, 2010
I can't seem to use the tool, everytime i try the second step, it processes two genh files, and then tells me "Unexpected EOF" this is on 99_98.gcs also, the two genh files consist of the whole of the sounds, but speeded up very heavily.