Audio format

[Khojan]

Hey,

As a side project from my regular programming job I'm working on a complete rewrite of Doom. Ground up with none of the original source code at all. The UDS doesn't have any information about the format of the audio in the wad files. Does anyone know how the sounds are layed out?

Thanks

[Khojan]

Nobody knows huh? This might be tricky.

It's going to take a while to get this project done but it should be pretty cool when it's finished. I'm trying to keep it as close to the functionality of the original Doom (and Doom2) as I can. So you can use the real wad from the game and just replace the executable. I'll have some extra stuff in there too but the behavior will default to old-school doom.

I only have about 6500 lines of code so far. You can walk around the levels and pick up objects, switch weapons, look at monsters (they just stand around right now), and play around in the menus. It's all DirectX based. Resolutions up to 1600x1200 are supported right now (full screen or window). I'll post some screenshots later.

Cheers

[myk]

Khojan said:
Nobody knows huh? This might be tricky.

I just saved DSPISTOL as a WAV and then an LMP to disk with XWE, and it seems that they are WAVs, except with different header info.

[Khojan]

Cool. Thx.

[myk]

If you use that program to compare, first use "Save as" to get a WAV and then "Save as (raw data)" to get a copy in the native format, both with the Entry menu.

[fraggle]

The sound lumps have an 8-byte header, followed by 8-bit mono PCM data.

Bytes 0 and 1 always have values of 3 and 0 respectively.

Bytes 2 and 3 are a little-endian 16-bit value containing the sample rate.

Bytes 4 and 5 are a little-endian 16-bit value containing the length of the sound (number of samples). Because the sound is 8-bit mono, this is always equal to the length in bytes.

Bytes 6 and 7 always have a value of 0.

When playing back, the length is always taken from the header, not from the lump length, so sounds can never be longer than 65535 samples. Longer sounds get cut off.

Hope this helps!

[Scet]

In DooM.Net I had to add the WAV file header to the actual PCM data to get DirectSound to play it(since DS only plays WAVs).

Basically create a byte array of size: WAV header size + actual pcm data length from lump. Then wrap a DirectSound secondary buffer around it.

You can find the info for the WAV format at wotsit.org.

If you get stuck I could send you the sound code for Doom.Net, but it's in Managed DirectX.

[RjY]

fraggle said:

Bytes 4 and 5 are a little-endian 16-bit value containing the length of the sound (number of samples). Because the sound is 8-bit mono, this is always equal to the length in bytes.

Bytes 6 and 7 always have a value of 0.

When playing back, the length is always taken from the header, not from the lump length, so sounds can never be longer than 65535 samples. Longer sounds get cut off.

I don't believe this is correct. Instead it seems that bytes 6-7 don't have to be zero, and samples do not get cut off at length 65535. I suspect bytes 4-7 are a 32-bit length.

I made a test wad, replacing the pistol sound with a 300kb sample at 44.1kHz. Deutex, which is very fussy about vanilla compatibility, happily wrote the length bytes 4-7 of the lump as E6 AC 04 00 (although I did have to hack around a bit to stop its braindead resampling to 11.025kHz!) Doom2.exe played the whole sample, as did PrBoom, but Chocolate Doom didn't like it :) Could someone else try to verify or refute these findings?

Also I've always wondered if byte 0 ("always 3") isn't just the log to base 2 of the number of bits per sample, although I've never investigated this.

[RTC_Marine]

could be, then again it could be an identifier for the type of lump it is.
Too bad graphics/sprites lumps don't have an ID

that find of yours is interesting

[CODOR]

RjY said:
I don't believe this is correct. Instead it seems that bytes 6-7 don't have to be zero, and samples do not get cut off at length 65535. I suspect bytes 4-7 are a 32-bit length.

Could be, it took seven years to discover that Doom 1.666 and higher support MIDI in addition to MUS (and then almost another three for anyone else to notice).

(although I did have to hack around a bit to stop its braindead resampling to 11.025kHz!)

There's a beta version (that's over a year old now) of deutex at http://www.teaser.fr/~amajorel/deutex/fungus/ that has this fixed (or rather, made into an option whether to resample, reject, warn, or silently accept the file).

Doom2.exe played the whole sample, as did PrBoom, but Chocolate Doom didn't like it :) Could someone else try to verify or refute these findings?

If I'm reading the PrBoom source right, it uses the length of the lump (less the 8-byte header) as the length of the sound.

And again, if I'm reading the Chocolate Doom source right, it rejects sounds where bytes 6 and 7 of the header are nonzero. Chocolate also checks the lump length, but only to make sure that the value in the sound header is sane.

Also I've always wondered if byte 0 ("always 3") isn't just the log to base 2 of the number of bits per sample, although I've never investigated this.

That could have been the intent, but if it was it doesn't seem to be implemented. Doom 1.9 ignored the sound entirely when I tried it set to both two and four.