Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Trying to "mixdown" two wavs to one wav using memblocks. Hmm???

Author
Message
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 14:21 Edited at: 23rd Dec 2013 15:46
Link
G'Afternoon,

I'm attempting to mix two wavs using memblocks.



The "mixdown" happens but with lots of static (whitish noise).
I know this is rather ambitious with AppGameKit but I'm so close.
Does anyone have any ideas how to make it work properly.

Also, can the 'record sound' command be functional sooner rather than later.

I'd love to be able to make a multi-track recorder for Android.

festive regards,
miki.

in the end
Back to top
Profile PM Email Website
Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 23rd Dec 2013 14:57
Link
I haven't looked at your code in much depth, but where you add the two bytes of the sounds together could be the issue. Firstly, if its a 16 bit wav you'll need to be adding two bytes together and writing them back, rather than doing them individually. Secondly, if the addition of the two bytes is more than 256 and the byte overflows you'll create distorted wrapped values. You'll want to cap the additions at a max value. This will cause hard limited distortion but sound better with less noise.

Back to top
Profile PM
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 15:09
Link
thanx fallout,

I've done this....

for t = 13 to memblocksize3

r1 = getmemblockbyte(1,t)
r2 = getmemblockbyte(2,t)
r3 = r1 + r2
if r3>255 then r3 = 255

setmemblockbyte(3,t,r3)
next t


and it still sounds the same.

in the end
Back to top
Profile PM Email Website
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 15:31
Link
For the record,

I tried the same thing on dark basic pro and got the same result.

in the end
Back to top
Profile PM Email Website
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 23rd Dec 2013 15:35
Link
How do you know that the wave file is stored as 8-bit?

I mean, if it's stored in standard 16-bit format, then that white noise might just be the wave file, assuming 8-bit but playing back as 16-bit, which might still sound like it's working, but really it's not. If the system is expecting 16-bit and you feed it 8-bit, then it'll play each pair of bytes as if they were 16-bit, so basically in pairs of bytes, which means every second byte is being played as the second half of the 16-bit sound data - which might explain the noise you hear.

I think you need to work with integers and shorts, not bytes... unless you know for a fact that the files are both stored as 8-bit and are replaying at 8-bit.

I am the one who knocks...
Back to top
Profile PM Email
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 16:08 Edited at: 23rd Dec 2013 16:23
Link
both sounds are 16bit, 11025 samples per second, mono as displayed below..



I've just tried writing back using shorts and integers.
Bytes sound the best yet...

I'm writing back like this..

creatememblock(3,memblocksize3+13)
setmemblockshort(3,0,channels[n])
setmemblockshort(3,2,bitspersample[n])
setmemblockint(3,4,samplespersecond[n])
setmemblockint(3,8,numberofframes[n])
`
for t = 13 to memblocksize3
`
r1 = getmemblockbyte(1,t)
r2 = getmemblockbyte(2,t)
r3 = r1 + r2
if r3>255 then r3 = 255
`
setmemblockbyte(3,t,r3)
next t

What is odd... this is a picture of the mixdown wav opened up on cooleditpro..



the properties say it is also 16bit 11025 mono

a little one sided??

in the end
Back to top
Profile PM Email Website
Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 23rd Dec 2013 16:22
Link
You need whichever datatype is a signed 2 byte integer, probably! So is a short 2 bytes and signed? I dont know. In any case, you need to do some research into how a 16 bit sample in a wav is stored at the bit level. From that you can get a better idea of how to combine them, but its definitely 2 bytes at a time you want to work with.

Your one sided wav image suggests to me that all the values are being interpretted as negative. Thats because your byte to byte addition is setting a negative bit somewhere in the final value.

Back to top
Profile PM
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 23rd Dec 2013 16:24
Link
That's what I mean...

for t = 13 to memblocksize3
`
r1 = getmemblockbyte(1,t)
r2 = getmemblockbyte(2,t)
r3 = r1 + r2
if r3>255 then r3 = 255
`
setmemblockbyte(3,t,r3)
next t

You are taking 2 16-bit sound files and reading the byte data back, adding together, and writing back byte data. It's no wonder the data isn't right. It only sounds ok because the 8-bits are being written from the first half of the 16-bit data, so basically breaking it down to 8-bit, but then adding a fairly random byte value after it.

You need to work in 16-bits if your working in 16-bits!

You probably need to work out the maximum sound level in each file as well, then normalize it - so rather than just adding the values and limiting them - you'd add the values and multiply them so they are normalized... then you won't get the same distortion from the flatouts. It has to be consistent through the whole sound, so scan through them both get the maximum values, then work out the total of the 2 values, divide by 65536, and then each 16-bit sound value that you calculate, you can divide by this multiplier to keep it normalized within 0-65535. You can actually generate whatever-bit format you want at this point... like divide all that by 256 to get the byte value, but you have to specify the format, otherwise it'll just play at whatever it has already set for the sound. Like you'd have to set the bits per sample to 8, then you might have a true 8-bit sound instead of a confused 16/8-bit one.

I am the one who knocks...
Back to top
Profile PM Email
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 16:45
Link
I'll try the whole exercise using 8bit wavs as a starting point and then tinker with it from there.
Thank you very much for the input.
I'm sure I'll sort it out eventually.

Merry Christmas.

festive regards,
miki.

in the end
Back to top
Profile PM Email Website
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 23rd Dec 2013 17:05
Link
Yeah, converting them to 8-bit first should give much more predictable results, and it'll be easy to adjust them for signed or unsinged format. Good luck!

I am the one who knocks...
Back to top
Profile PM Email
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 23rd Dec 2013 19:15 Edited at: 23rd Dec 2013 23:51
Link
You can't just add the bytes up. You need to to set the high order byte in an integer. Depending on little or big endian you need to read them into an integer (a full 32-bit integer).

For ONE sample you need to do this:

Read a byte into a
Read a byte into b
IntegerA = a SHL 8 or b

Do the same with other wave form into IntegerB

then Value (for this sample) = IntegerA + integerB /2

To put it back you need to write a byte of Value AND $FF00
Then a byte of Value AND $FF

WAVs are normally little-endian. If they are not, the FOURCC is RIFX instead of RIFF

I don't know if MemBlocks have a read shortint equivalent - if so, life gets easier. Either way, DO NOT use a shortint to get the addition - it will overflow and be nasty.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 20:15 Edited at: 23rd Dec 2013 20:17
Link
Hi JimHawkins,

It sounds as if you know what you're talking about.
Unfortunately, I haven't got a clue what you mean.

After some Googling I understand that SHL is shift left.
I can grasp (I think),
Read a byte into a
Read a byte into b

Would that be,
a = getmemblockbyte(1,t)
b = getmemblockbyte(1,t+1)

But... No! I'm lost

Could you put it into basic please...

I feel like an Old Thicky

in the end
Back to top
Profile PM Email Website
miki
19
Years of Service
User Offline
Joined: 7th Jan 2005
Location:
Posted: 23rd Dec 2013 22:48 Edited at: 23rd Dec 2013 22:49
Link
Success !!

Mixed 2 wav files using this code..



I've uploaded the resulting wav file. Have a listen to the quality...

Thanks Jim, Van and Fallout.

regards,
miki.

p.s.

thanx xGEKKOx, V2 is cool!!

in the end

Attachments

Login to view attachments
Back to top
Profile PM Email Website
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 23rd Dec 2013 23:50
Link
That's not quite right. I think you're getting lucky!

This:

r3 = r1 + r2

should be

r3 = (r1 + r2) / 2

You'll be okay if the sum doesn't exceed +- 32786 - but for reasonably full amplitude waveforms it will. You have to take the average of the two samples. If you were adding four tracks you would have to divide by 4 etc.

Thanks - yes I do know about this! Written lots of music programs and the original sound installations for the London Transport Museum. (Try bending a range of samples of a bus with automatic transmission so people can sit and "drive" it!)

It's important not to assume that WAV files are uncompressed 16-bit PCM data. They may be 24-bit, 32-bit or floating point values. 99% of the time they are exactly like CD data, but high-end music programs like Cubase may well write 32-bit 96 samples/sec data.

SHL is really a fast way of doing a multiply. Shifting left 8 bits is the same as multiplying by 256. The "high order" byte of a 16-bit number is worth 256 times that number. The "low order" byte is from 0 to 255. So if you have binary bytes 0001 0001 that is 256 + 1 = 257. However, for signed numbers (like your audio samples) the most significant byte uses the leftmost bit for sign, and the number is then inverted. Fortunately, you don't have to worry about this for simple summing - the processor does it for you.

You can modify the ratio of your track volumes by dividing before you sum. So if you want the sound in track A to be half the volume in track B after mixing:

R = ((A /2) + B) / 2

Although you can amplify by multiplying you have to be very careful not to go past the peak point(clipping). But that's for another day - which happens shortly to be Christmas Eve!

Let's hope Santa and his elves will drop some goodies and take all the bugs away...

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-05-02 08:14:52
Your offset time is: 2024-05-02 08:14:52