Arc Developments AVF-95 .huf video by hcs at 5:39 AM EDT on September 24, 2019
I picked up a copy of the PC version of Johnny Bazookatone, mostly for the audio CD, but I'd like to do a proper rip of the game as well. The music is mostly CDDA, and there's sfx that are normal RIFF WAV, but the video is in a format with extension .huf and magic word "[AVF-95]". I assume this is some in-house thing, no trace of it on the web as far as I can tell. I also assume the audio is in there, I don't think they just use the CDDA tracks during video, but I'm not 100% sure.
It's probably not worth spending too much effort on, as we have the audio for the videos in all the console versions, but I figured I'd put the data up here in case someone wants to take a crack at it: JOHNNY_B.
by WDLmaster at 10:12 AM EDT on September 24, 2019
Never heard of the game or the video format but after a few minutes of dissecting I can tell that the audio is uncompressed unsigned 8-bit mono PCM @22050 Hz. It's interleaved with frame data. Every audio chunk except the first one is 1470 bytes long, which is 22050/15 which leads me to believe the video frame rate is 15 FPS. The first audio chunk is 132300 bytes, which is exactly 6 seconds of audio.
Should be no problem when I have time. I haven't looked deeper into it since my last post. If we/I can find some bytes that tell me about chunk lengths it should be very simple. But I have no idea about the video frame format. The Folder name is "flics" so I looked around the net for the structure of the Autodesk FLIC format. I thought the frames might be compressed with FLICs methods but it doesn't seem to be the case. It's probably proprietary. If you're just interested in audio, well, that's certainly possible.
Well, I decided to write some half-assed extractor that kinda works. You can download it here. Just drop a .huf file onto the application window and press [Extract Audio].
It can only extract audio at the moment. I couldn't find any info about actual frame offsets so far. Fortunately the file header contains pixel dimensions and number of frames. I simply used a certain set of 25 bytes which are always identical in all frames and all files to identify a frame's offset. The actual offset is 5 bytes before the identified one. Every frame starts with a ridiculously big (and redundant) header of more or less 380 bytes which is always identical across the whole file with the only exception being the first DWORD, which seems to be the de-compressed frame size.
Not every extracted audio is perfect. Some of them have garbage at the end. I double checked the extraction method a few times and noticed that the actual audio chunks contain garbage. It's not an extraction error or some wrong offset. It's possible that the file format has some "end of stream" bytes which prevent the video(s) from playing to the end, effectively skipping those chunks. Who knows...