gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Are there limits for sound .raw files? [SOLVED]

#83467 - Dark Knight ez - Tue May 16, 2006 3:31 pm

I've been using the sample raw-sounds of devkitPro until now, and they work properly with my code.
Now, I've created some new samples... 1 channel, 22050 samples per second, 17275 data bytes, wav, and converted them to 8-bit.

Using sox and the normally used line: "sox -V in.wav out.raw" gives me on-screen output which is quite similiar to that found in Chris Double's tutorial, only replace his sample rate with my sample rate and also replace his sample's length by my own. One more thing is listed: the amount of samples per channel (which is equal to my sample rate).
Link to the tutorial I was refering to: http://www.double.co.nz/nintendo_ds/nds_develop4.html

When I put the created raw files in my data-folder, add them as I did with the sample sounds, change the code to reflect the samples per seconds and sorts, and then after compiling try to play them... it sounds like complete rubbish.

Snippet of code to play one of the new samples:
startSound(22050, snd_drumbeat_raw, snd_drumbeat_raw_size, channel, 127, 64, 1);

So, is there a limit to maybe the sample rate? Did I exceed that limit? Is my conversion using sox just rubbish? *shrugs*
I've uploaded the drumbeat wav-file, so you people can have a look at it. It plays alright in Windows Media Player, and I can't see sox having trouble converting it, but on the DS it just doesn't play properly. Please help me out on this one.
Link to the uploaded drumbeat wav: http://www.few.vu.nl/~ssstolk/temp/snd_drumbeat.wav

Last edited by Dark Knight ez on Wed May 17, 2006 10:18 am; edited 1 time in total

#83603 - melw - Wed May 17, 2006 9:09 am

It's definitely not using too high samplerate, at least 44kHz still works perfectly with the DS. Check your raw sample files by some sound editor to see if they're ok. Otherwise the code is not playing the correct file... playing from wrong memory offset results in neat rubbish sounds too :).

#83606 - Dark Knight ez - Wed May 17, 2006 9:42 am

Thanks for the response.
I didn't realise sound editors can play raw files, but I've checked, and it seems the converted raw file is good. Must be something in my code.

Oh. it seems the sample raw files use signed 8 bit, and I'm using unsigned 8-bit. (I'm used to having 8-bit samples unsigned, since that's the standard for 8-bit wav files. Weird though that the tutorial does use unsigned 8-bit samples. Bah.)

Does anyone know of a program which can either convert a raw file from 8-bit unsigned to 8-bit signed, or a wav file from 8-bit unsigned to 8-bit signed?
Audacity doesn't seem to support it, neither does Soundforge. Might have overlooked some option in Sox, but I'm not seeing it in there either.

EDIT: Sox does support it. "sox -V in.wav -s out.raw"
The raw files now play perfectly. This stuff might be useful to add in tutorials.

#83669 - tepples - Wed May 17, 2006 7:53 pm

Dark Knight ez wrote:
Does anyone know of a program which can either convert a raw file from 8-bit unsigned to 8-bit signed, or a wav file from 8-bit unsigned to 8-bit signed?

When you load the sample, XOR every byte with 0x80. Untested code:
Code:
void toggleSignBit(unsigned char *sample, size_t len) {
  for(; len > 0; --len, ++sample) {
    *sample ^= 0x80;
  }
}

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#83704 - Dark Knight ez - Wed May 17, 2006 11:24 pm

Wouldn't that "mirror" the wave over the horizontal axis compared to the original? (I guess that probably wouldn't make a difference.)

Still, "loading the sample" in this case is just pointing to the included file for playback, and in your case, I'd have to reserve space in memory, convert the sample with XORs, and then point to it for playback... if I'm right.

I appreciate your reply though. If Sox couldn't handle converting it to signed, I would have tried your approach (only not on the DS itself, but before that, converting the sample by a self-written piece of code).
It does seem that sox adds a "click" at the end of a sample (comment perhaps?), but that can easily be edited out with a hex editor.

#83713 - DekuTree64 - Thu May 18, 2006 12:28 am

The XOR just converts it to signed format. A more clear way to do it is to subtract 128 (basically changing the 0,255 value to -128,127). It just happens that flipping the top bit has the same effect as subtracting the top bit, plus you can use it on 4 samples at once if you need it to be speedy, since it doesn't affect the bits above it like subtraction would:
Code:
void toggleSignBit(unsigned char *sample, size_t len) {
  for(; len > 3; len -= 4, sample += 4) {
    *((u32*)sample) ^= 0x80808080;
  }
  for(; len > 0; --len, ++sample) {
    *sample ^= 0x80;
  }
}

Assuming that sample is 4-byte aligned to begin with.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#83727 - tepples - Thu May 18, 2006 1:50 am

Dark Knight ez wrote:
If Sox couldn't handle converting it to signed, I would have tried your approach (only not on the DS itself, but before that, converting the sample by a self-written piece of code).

It's not that difficult to make the conversion from 8-bit unsigned to signed work on the DS. Then you can store .wav files on the CF or in the GBFS, converting them as you load them.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#83754 - Dark Knight ez - Thu May 18, 2006 10:26 am

That would have a couple of benefits, but I'm afraid I can't do that for several reasons. That is to say, I want to use GBFS for just two to three (customization) files and not also for sound effects and such.