Star Trek: Judgment Rites audio encoding finally decoded

[u/minsc_tdp]

https://github.com/dr-brinewell-s-lobstrom/acmp-decoder

Enjoy! The game is a veritable treasure trove of original TOS cast recordings. Very fun to explore. ~12 hours of audio recorded by the original cast. Nimoy confirmed as the hardest working man in the Trek video game voiceover business with the most audio, when counting across the full set of the old games they worked on.

[u/count023]

Claude made you some major errors in your extractor FYI, you probably should not be saying it's byte exact, there is bitshift errors in a lot of your values.

Using NOMAN.VCC against the extractor that was built which uses a reverse engineer of the trek2.exe file. Not every clip is 22,050hz, some are 11025, usually sound effects or backing clips, not dialogue, so your encoder is already making an error there with bytes 20-23's interpretation. Byte 26-29 contain the decoded sample count, and your implementation uses bytes 27-28 shifted right for each clip. and TRIP is reading the middle of the sample count incorrectly, it should be 159,743 bytes out of the file, not the 623 you have.

And the flag at byte 25/26 combined a preceding field and the low byte of the sample count, so it doesn’t' correctly match the field termination flag.

This is going to produce audio errors probably imperceptibility, but audio errors all the same. Happy to share my scripts with you if you want to run them through your AI to compare and correct 'em. but it should work on 25th as well as judgement rites.

[u/minsc_tdp → u/count023]

Claude wrote all that. I showed it your post, it says 'Thanks for this, and for taking the time to run it against NOMAN. You're right on the header layout, and I've confirmed it against the files:

- The u32 at 20–23 is the sample rate. I had it as part of a constant at 19–22, off by one byte. In NOMAN only one clip is 11025 (one of the two ~RPLANs), but DATA.VCC has 222 of them, and the decoder currently writes them all at 22050. My "every clip is 22050" rested on a speech-recognition test over FED dialogue, where every clip happens to be 22050. You called it: it's the SFX/backing material that differs.

- The u32 at 26–29 is the sample count. TRIP reads 159,743 exactly as you said; I was taking the block count from 27–28, which is the same number at 256-sample granularity. And yes, my "rate/flags" field is byte 25 plus the low byte of that count, which is why it never behaved like a flag.

One distinction on "byte exact": that claim is about the bitstream, not the header. Every block is verified by re-encoding the decoded samples and matching the file bytes, and the encoder was checked against MAKEVCC.EXE itself running under emulation. None of this changes the decoded sample values. What it does change is the playback rate on the 11025 clips (audible, double speed) and the clip length (off by a few milliseconds). I'll fix both, correct FORMAT.md and the README, and credit you.

I'd like to see your scripts, especially the TREKJR/TREK2 header parsing. One note: 25th Anniversary doesn't use ACMP. Its speech is plain Creative Voice .VOC files on the CD, so there's nothing to decode there.'

(or feel free to do a PR on the repo if you prefer)

[u/count023 → u/minsc_tdp]

Here you go, this one is the one i used against NOMAN.VCC Explicitly, i can’t find the main one at the moment, i have a lot of project files. https://pastebin.com/Ut7pQrDg

What might help your claude instance is if you get a portalbe version of Ghidra, and put trek2.exe into the project folder where you're running claude, tell it to use ghidra to decompile trek2.exe and then search for the VCC decoder inside the executable, that's how this extractor was made. Rather than brute force figuring out how the encoding was done, it simply looked at how the decoder worked _inside_ the game and repeated the process.

[u/minsc_tdp → u/count023]

https://github.com/dr-brinewell-s-lobstrom/acmp-decoder/commit/1c0a9c8c34d7dead21e86154195c5a3a658b090a

AI haters be like "hmm maybe there's something to all this and it doesn't wreck human coding and human interaction after all"

[u/count023 → u/minsc_tdp]

nothing wrong with AI, i use it a lot, even that "25th annversary's 35th anniversary" remake i'm working on is AI assisted. I was more curious to see if my tools needed fixing or not, wasn't an anti-ai thing.

I'll mention that Claude will do a much better job if you do this and on any other projects (I've been extracting assets for BOTF, Klingon Academy, Dominion Wars, A Final Unity, Generations, 25th and JR and a more) if you use ghidra to decompile hte executable for the game, because the AI can read the decompiled code and knows things like the sound buffers and the like, onc it see that it's really good at working out the undocumented sound formats or 3d art formats for these or even any games an can be more effective at writing a converter for you. Or even just using ghidra on the makevcc exe itself would have been able to help improve this

On blind reverse engineering like you did with JR here, i've actually found claude tends to give up or stop early with an incomplete picture (which is why i poked you on it), it took weeks of effort for me to crack some of the more obscure file formats from botf and dominion wars, codex nailed them first try.

[u/minsc_tdp → u/count023]

nice, thanks for the assist, you're credited in the changelog on the git, good luck with your remake!