sound sample rate

Hi!

I already brought this up in the beginning of freedom. It seems like most submitted sound are sampled in 22050 khz, but are converted to 11025 khz. I don't think this is neccessary, because the original shotgun reload sound is also 22050 khz, so even the original Doom.exe can play that. If a sourceport doesn't support such sampes it should be fixed then. I think the sound quality would get noticable better with the higher sample rate.

Florian

you are correct

excerpt from build.output:

Making Sounds
Warning: shrinking 22050 to 11025 sample/s

and then it says that a bunch more times.

the only conclusion i can come to is that whoever coded this aspect of deutex had a brain lapse, considering the fact that the sound format in doom allows for different sample rates, and that some of the original .iwad sounds (the ssg ones i believe) are 22050, demonstrating that doom can handle 22050 sounds correctly.

a source port doesnt support 22050? it's broken. in fact i remember reading a log excerpt once from i forget which, but a programmer's log of one of the doom ports. he noticed that the ssg sounds were broken. he investigated the sound code problem. he fixed it to keep his port compatible with original doom.

i was going to put this in my "random comments" thread but clean forgot it

Yes, I remember the original dosdoom (port of the released linux source code that was released) played all the sounds right except some of the super shotgun sound effects, which played at half speed.

deutex seems to "helpfully" resample the sound effects, I'll try and find if theres a way to turn this off.

..or insert the sounds as lumps using a diff. program perhaps?

any luck fraggle? i could whip up a program that converts the .wav -> .lmp and then you could deutex them in as lumps if nessecary.

well i got bored so i wrote a program to do it anyway, whether or not you end up needing it :)

it's in /incoming, the basic theory of usage is use it to convert the .wav into .lmp, then reconfigure the deutex to insert the .lmp instead of converting the .wav

make sure to read read1st.txt and the comments at the top of the source because they go into much more detail than that miniparagraph i just wrote does :)

akk! i made one stupid error (never code at 3 in the morning): the program reads and writes one byte off the end of a malloc()ed memory area. of course, windoze didnt catch it :). i uploaded a revised source.

Hmm, doesn't Boom support 16bit samples?

matt fell's doom spec indicates no way in the sound lump to specifiy bit depth; it is assumed at 8 bit. so my program (and most likely all others) write 8 bit sound for doom

edit: boom 2.02, i_sound.c, line 55

static SAMPLE *raw2SAMPLE(unsigned char *rawdata, int len)
{
  SAMPLE *spl = malloc(sizeof(SAMPLE));
  spl->bits = 8;
  // killough 1/22/98: Get correct frequency
  spl->freq = (rawdata[3]<<8)+rawdata[2];
  spl->len = len;
  spl->priority = 255;
  spl->loop_start = 0;
  spl->loop_end = len;
  spl->param = -1;
  spl->data = rawdata + 8;
  _go32_dpmi_lock_data(rawdata+8, len);   // killough 3/8/98: lock sound data
  return spl;
}

fraggle said:
deutex seems to "helpfully" resample the sound effects, I'll try and find if theres a way to turn this off.

If not, I can have a look at fixing this "feature". No reason to do a workaround when we can fix the problem and other projects can benefit too :-)

cph said:

If not, I can have a look at fixing this "feature". No reason to do a workaround when we can fix the problem and other projects can benefit too :-)

cph: i just looked it up. in deutex 4.4.0, file sound.c, beginning on line 395. very simple to fix, but no way to specifiy on cmdline apparently. i'll leave it to you to fix because you're a 1337 coder where as i almost let the fact that strings are null terminated slip by me a few hours ago ;)

looks like this will obsolete my wav2lmp even before it ever gets used :( well i don't care, i had fun writing it =D

oh my, i was really asleep, there's another bug in my program which breaks 16 bit support (not fair! i had nothing to test it on!). if anyone has any use for this thing, search and replace

      for (i = 0; i < doomnumsamples; i++)
      {
        fread (&ustemp, 1, 1, fil);
/* replace with */
      for (i = 0; i < doomnumsamples; i++)
      {
        fread (&ustemp, 2, 1, fil);

I wrote a patch to the deutex source to add a -noshrink option to deutex. It was actually quite simple to do (surprisingly simple considering how horrible the source is). This should fix it.

Thanks to oblivion for his convertor program, although we didnt use it in the end :)

heh, cool :)

this should be good: i played freedoom a bit with the sounds from my converter and they sounded a lot better that way.

note that i was reading on the deutex page, apparently the 11025 thing is for compatability with 1.2 and earlier doom versions, which are, well, old ;)

esayeek said:

note that i was reading on the deutex page, apparently the 11025 thing is for compatability with 1.2 and earlier doom versions, which are, well, old ;)

I guessed it was probably something like that. deutex had the code to output at any sample rate, but was just deliberately resampling everything. The sound code had a major overhaul at around 1.2 i think (remember pitched sound in the early versions?)

fraggle said:

I guessed it was probably something like that. deutex had the code to output at any sample rate, but was just deliberately resampling everything. The sound code had a major overhaul at around 1.2 i think (remember pitched sound in the early versions?)

hell yeah i loved that! i never wanted to upgrade from 1.1 because i loved the pitched sound so much. i think it sounds better than the new pitched sound that was added back in by various source ports too.

/me goes and remakes the imp sounds...

once the new sprites are finished.