Would it be possible to convert the PSX Doom music to module format?

I am really impressed. Though the fade in/out is still missing but nevertheless its a huge accomplishment.

How did you convert everything into soundfont format anyways?

Kaiser said:

How did you convert everything into soundfont format anyways?

I'm just using a regular end-user soundfont editor. Load the samples in, set the parameters, poof. Nothing automated.

It's trivial in such a thing to enter in ADSR envelopes that would make it sound better, but I haven't done that because my goal is to get the original ADSR envelope data from DOOMSND.WMD

Actually I meant how did you managed to get the data from PSXDoom and convert them into a soundbank :P
How were you able to look into the LCD files and grab the necessary data?

Also, sorry to sound completely clueless but what are ADSR envelopes?

Kaiser said:

Actually I meant how did you managed to get the data from PSXDoom and convert them into a soundbank :P
How were you able to look into the LCD files and grab the necessary data?

Also, sorry to sound completely clueless but what are ADSR envelopes?

The LCD files are a rather simple DPCM format. The mathematics of it is not terribly intuitive; but you don't need to understand the formulas, just to use them. I wrote a small utility that turns them into .wav


ADSR =

Attack - the increase from 0 volume to max volume when the note is first sounded
Decay - the decrease in volume right after attack
Sustain - volume is held still while the note plays
Release - after note off is requested, the decrease in volume to 0.

In the PSX sound system, there are parameters for these; and the length of time for Attack and Release are the ones I primarily need to get the fadein-fadeout working right.

natt said:

I'm going to clean up what I've done a bit and then release it for others to look at, because quite frankly, everything I haven't figured out yet, I'm stumped on. Most importantly, there are bunches of tables and headers in DOOMSND.WMD that I don't understand.

Does this mean that you're abandoning it? :( (I probably shouldn't make stupid assumptions like this :P)

Sodaholic said:

Does this mean that you're abandoning it? :( (I probably shouldn't make stupid assumptions like this :P)

I'm not abandoning anything, but you can only stare at a hex editor for so long until your eyes bleed. These sorts of things, you either "see" it or you don't. I'll release everything I've done so far, and see if anyone else comes up with anything, or maybe take another look at it in while when my brain's fresh again.

natt said:

In the PSX sound system, there are parameters for these; and the length of time for Attack and Release are the ones I primarily need to get the fadein-fadeout working right.

Thanks for the info. Though have you considered modifying or changing some values of the DOOMSND.WMD file in the hex editor and seeing what changed in the actual game/emulator?

Kaiser said:

Thanks for the info. Though have you considered modifying or changing some values of the DOOMSND.WMD file in the hex editor and seeing what changed in the actual game/emulator?

That's a great idea, and I will do it if I get around to it.

====

Real life is making me a bit busy at the moment. Anyone who's technically inclined, here are some programs and documents I've made.

http://www.mediafire.com/?dvw69jt8vafbrov

If you have questions I'll answer them. If your questions are of the type "I double clicked on the program and the box came up but it went away immediately", I won't.

Thanks for the heads up. I know your busy but do stay in touch with the community. You've made more progress than what I could ever do with psxdoom's sound system.

Nice work! at the least these midis would be a good start for hand making remakes, the timing is there.. Any chance of making midis for Doom 64? The random ambience and long tracks make these nearly impossible to re-create from scratch!

We're actually discussing about that right now. The format for the compressed sound in Doom64 is still unknown right now.

Kaiser said:

We're actually discussing about that right now. The format for the compressed sound in Doom64 is still unknown right now.

you extracted the sounds though right? if the tracking info could be extracted, with a fair bit of work, samples could be placed in and tweaked from there maybe? like using a midi file to make a mod.. alot less wrok then it was going to be anyways!

ShaneAmp said:

you extracted the sounds though right? if the tracking info could be extracted, with a fair bit of work, samples could be placed in and tweaked from there maybe? like using a midi file to make a mod.. alot less wrok then it was going to be anyways!

No N64 samples yet, but I have ideas...

Midway is definitely leveraging a lot of the standard N64 libraries for the sound. They're also calling alAdpcmPull which suggests that the sound is using a conventional ADPCM format.

So are you not reffering to the instruments used in the tracks? When attempting to remake terraformer from sratch, it sounded dead on for the first 40 seconds, which was as far as I made it, before it started to get hard to track! But some of the pieces from either the ending or intro theme were off in frequencies..

sure is vadpcm in here

http://www.mediafire.com/?z5it45ho5a4z9o0

not really much use to anyone yet, there's no accompanying soundfont or anything.

So what's the difference between vadpcm and adpcm anyways? Or for that matter, what's the magic behind adpcm/vadpcm compression?

Kaiser said:

So what's the difference between vadpcm and adpcm anyways? Or for that matter, what's the magic behind adpcm/vadpcm compression?

Well, I freely admit that I do not understand much of the internals of audio compression formats. I do my work mostly by lucky guesses; I use a hex editor and look for file structure that I do understand. In the case of vadpcm, the discovery process went like this:

1. Mupen64plus 1.99 emulated the sound of doom64 more or less successfully while using an HLE audio plugin. This is good because HLE sucks; it isn't actually emulating anything, it's just using high level code that knows what is supposed to happen. But since it got it right, I can just look at the high level code and see what's going on.

2. Looking at the source for the audio plugin, it's invoking a VADPCM decoder that it claims is for "mario 64". The source is otherwise pretty much a mess, so I download an open source N64 sound rip tool which claims to support mario 64.

3. The tool doesn't work. Examining its source, I note that the structures its looking for don't resemble what I've seen in the hex editor at all. But one thing does look familiar: VADPCM custom predictor sets. It's a simple format, and I've seen them already in the doom rom. So I guess that while the overall structures are different, the audio data itself is VADPCM.

4. I look through the source of the tool for any identifying marks I should expect to find in the actual audio data. There is one: every 9th byte contains predictor and scalar selections, instead of raw audio data. I look at the portion of the Doom rom which I think contains compressed audio data, and every 9th byte looks like that.

5. I combine what I've already figured out (tables and offsets) with this VADPCM decoder, and done. (You can forget the part where I spent half an hour with garbage spewing out of my speakers because one of the table offsets was off by a few bytes).

======

I know this is not quite what you asked, but it does explain how I can decode the audio without knowing a damn thing about it.

Fair enough :)