To convert to this you'd need some tool that generates IMA, I expect sox would be good for it. Generate a headerless IMA stream (with reversed nibbles) for each channel. Calculate the header values from the size of one channel. Pad the header out to 0x20 bytes, then append the left channel and the right channel. You may need to play with padding a bit, try padding the channels out to 1k or so. You should probably use 32khz like these files were.
Well, you get a hex editor, and you write out the size in big endian. For instance:
Say a channel is 361890 bytes. 361890 is 0x585A2 in hexadecimal, you can convert this with the windows calculator or any number of other programs/web sites. You then open a hex editor and type it out like this:
00 05 85 A2
It has to be padded out with zeroes to fill 4 bytes. You do the same with with other values.
With 1k I meant to write zeroes to the end of the files until their size is a multiple of 1024 (0x400 hex), 1 kilobyte. I don't know if this is required by the driver.
help by superberny at 7:35 PM EST on January 22, 2010
Forgive me for my bad English.
Someone has managed to pass a wav to myspd and operating on the wii? I tested "sox in.wav -r 32000 -N -t ima out.myspd" for each channel and then create the header according to his information but does not work.
Your header seems a little weird, it looks like you decided to use the channel size -1 instead of the channel size. I'd have done: 0x00: 00 46 A7 F0 (size of channel) 0x04: 00 00 7D 00 (sample rate, 32khz) 0x08: 02 35 3F 7C (size of channel * 8 - 4) 0x0C: 02 35 3F 7C (size of channel * 8 - 4) 0x10: 00 8D 4F DF (size of channel * 2 - 1)
As for sox, that's a bit of a pickle. First, it doesn't seem like sox is capable of generating reverse-nibble IMA. Second, when I have it generate IMA normally, and reverse the nibbles myself, in vgmstream it looks like the signal gradually accumulates a DC bias. The issue is caused by a variation on the decoder that both vgmstream and a lot of other code uses, it is slightly different from the real specification. I don't know if the decoder used in U-Sing will have the same issue. It might not even be noticeable. In any case, you can try it out by encoding with sox and then reversing the nibbles with my little nibble reversal tool].
---
Been up all night poking at this, I've built a modified sox that uses the broken decode method in its encoder, this is the type of rounding that vgmstream expects. Get it here.
Note: This is the latest (released) version of sox, it uses dithering automatically so you might want to disable that with -D at least during testing so you're not wondering why your files change.
Also note: I wasn't able just yet to track down how the nibble reversing should get applied to output, so you'll still have to use nibble_reverse on the output .imas.
I don't know what rounding method U-Sing expects, I suggest trying both with my modified sox and with regular sox and see which sounds better.
I don't think so, without using some funky named pipe stuff. sox only can handle one output file at a time, and I don't think it has any mechanism for dealing with noninterleaved files.
Thanks HCS. It works! I used SOX-mod to create a ima in each channel, then reverse with your tool and finally Panding 32.
Now I need (and I think also Lif3styl3) a command that allows me to extract a MP3 to WAV as independent channels to do: "Mp3towav in.mp3 -channel L | sox-t outL.ima ima" and "Mp3towav in.mp3 -channel R | sox-t ima outR.ima "
Lif3styl3: I think we are working on the same project. I would like to talk to you about it: superberny@gmail.com
Ok, I was just hoping that someone would try both ways in the game itself and see which sounds better so you can tell which decoding method is being used. I may have to dig into the executable to satisfy my curiosity.
Right, they use somewhat different methods to encode. If the right decoder is used the signal will stay AC, otherwise it will accumulate a fairly large DC offset, in the negative or positive direction depending on the mismatch.
Interestingly, the original files seem to decode fine using either method, so there may be a way to adjust the encoder to avoid accumulating rounding errors in any case.