123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|683|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> Data -> ADPCM -> Data

Sat, 14 May 2022, 09:10
spinal

Data -> ADPCM -> Data


OK, I've been trying to decode ADPCM audio using the many identical code examples online, but fail each and every time. So I thought I'd give it a go in blitz, using image data so I could SEE whats going on.
Turns out, it either doesn't work OR I'm mis translating the code.

Can anyone tell me which it is?

Original example - https://www.avrfreaks.net/sites/default/files/Adpcm.c

Blitz3D version


The output



I know ADPCM is lossy, so I don't expect the exact same image as a result, but surely it should look similar at least...
Can it be a simple as some of the variable types being wrong?

-=-=-
Check out my excellent homepage!
Sat, 14 May 2022, 12:28
Jayenkai
Step One..
The bitshifting's wrong..


11 and 5, not 15 and 11. (if you shift a number left 15, then chop it down to a 16 bit number, you ain't getting much out of it!!)

(and don't forget to change the output to 11 and 5, too)

Step Two..
Chop the value to 16 bits. (sixteenbit and $0000FFFF)

.. Now delving into the rest of it!

-=-=-
''Load, Next List!''
Sat, 14 May 2022, 13:16
Jayenkai
Sorry, brain said no!!
I'll give it a go tomorrow.

There's a mistype/delete thing near the end, though.


should be predsample..

-=-=-
''Load, Next List!''
Sat, 14 May 2022, 14:27
spinal
I also thought of something that might make a difference, adpcm expects signed 16but audio samples, whereas my pixel data is unsigned, so it maybe needs to be -32767 before and +32767 after the conversion...

-=-=-
Check out my excellent homepage!
Sun, 15 May 2022, 01:17
spinal
Slightly better...





-=-=-
Check out my excellent homepage!
Sun, 15 May 2022, 06:36
Jayenkai
Alternative source linkage
Right from the very get go.. Your IndexTable should be -1's not 255's.

-=-=-
''Load, Next List!''
Sun, 15 May 2022, 07:28
Jayenkai
Tip : You need to reset the prevsample and previndex at the start of the second for x loop, so that both start from zero, not just the first loop.

-=-=-
''Load, Next List!''
Sun, 15 May 2022, 14:04
spinal
hmmm..... Can't tell if better or worse





-=-=-
Check out my excellent homepage!
Sun, 15 May 2022, 15:45
Jayenkai
I can't manage this one!!!
Been tweaking and poking and prodding it all day, and still getting nothing.
Sorry

-=-=-
''Load, Next List!''
Mon, 16 May 2022, 07:19
spinal
I have an idea to check how well I should expect it to work, I plan to load the raw image data into cooledit, save it as adpcm, reopen it, save it raw, redraw in blitz. Then I should at least know if this test is even possible.

-=-=-
Check out my excellent homepage!
Mon, 16 May 2022, 10:52
spinal
OK, did that test.
Loaded the image in blitz, did the screen pixel to 16bit conversion, saved to output file.
Loaded output file in cooledit, saved as ADPCM, closed cooledit.
Loaded ADPCM file into cooledit again, saved as RAW PCM data.
Loaded PCM data into blitz, converted the data from 16bit to RGB and plotted on the screen.
Result, to the human eye it's exactly the same.

So in theory, saving an image as ADPCM works 100%. But for some reason this code does not.

-=-=-
Check out my excellent homepage!
Mon, 16 May 2022, 14:19
spinal
Grrrrr, Closer, yet further...





-=-=-
Check out my excellent homepage!
Mon, 16 May 2022, 16:12
shroom_monk
I've never come across ADPCM before now, but here's some assorted thoughts after looking at this...

It looks like ADPCM is a lossy compression format, so we shouldn't expect the final image to be identical to the initial image, as some data will be lost. Since it seems to be intended for audio rather than images, I don't think there's any guarantee that the data lost in compression will 'look' sensible in image form. But I don't know enough about this algorithm to know what that would look like. (e.g. if it mangles the high bits of your colour, then the colour will change massively) So it could be that your current result is already 'correct'! Although it certainly does look sufficiently weird that there is probably more to fix. Testing it on audio is going to be the only way to be sure though, I think.

In the avrfreaks example your code is based on, the 'sample' input to 'ADPCMEncoder' is used purely to compare to the previous value to calculate 'diff'. Consequently I don't think your 'sample = sample - 32768' line does anything meaningful, since it doesn't change the result of the 'diff' calculation? Though if you are going to do that, you should probably initialise 'prevsample' with '-32768' to account for the shift there.

Since I'm less familiar with the hidden corners of Blitz3D: does 'code And 8' behave equivalent to '(code And 8) != 0' as the equivalent C code does? If it does you're fine, but if not then that code won't be behaving as expected. Ditto for the other places using this pattern.

Does bitshifting have higher order of precedence than maths operators in Blitz3D? If not, your 'If code And 1 Then diffq = diffq + QStep Shr 2' and similar line below it probably need some brackets around the bitshifting. I'd be tempted to add them regardless for clarity's sake.

I think Jay is correct that your index sizes translated from '0xff' should be -1, not 255. Given the magnitude of the other indices, and *especially* given the fact that these values are added to an 'index' variable that is clamped at 88, I don't see how adding 255 can ever make any sense. It's worth noting that the avrfreaks code dates from 1996, and while I don't know what size an int was in those days and Google is being entirely unhelpful, I could believe that this code was relying on it being 8 bits rather than anything more. The GitHub Gist example linked from your code also uses -1.

Other than the above, I can't see any other issues with your port, so hopefully it's some combination of the above. Hope that helps!

-=-=-
A mushroom a day keeps the doctor away...

Keep It Simple, Shroom!
Tue, 17 May 2022, 00:47
spinal
OK, the best I have is the following image....



But I think you're correct, about an image perhaps not being a good test. I reconverted the image to and from ADPCM using cooledit, and got similar results, I don't know what went wrong with my first test, perhps I accidentally reloaded the original image again (!?). But here is what cooledit did to the picture...



-=-=-
Check out my excellent homepage!
Fri, 27 May 2022, 01:36
spinal
OK, next question...



Currently, it seems, when reading the 'prevsample' from the file, it is read as a positive number. But it is realy a 2's compliment signed value. so this is always interpreted wrongly.

Does blitz know anything about signes 16bit numbers?

Here is an example of some of the readings...

current sample, current index, prevsample, previndex
111, 26, 36, 26
-454, 22, 65038, 22

That 65038 is supposed to be interpreted as -498


|edit| This doesn't seem to be working...


|edit|
That's because it's wrong...


-=-=-
Check out my excellent homepage!
Fri, 27 May 2022, 03:45
spinal
Aha!





The above code *almost* restores a file saved as IMA ADPCM as well as cooledit does. There is the occasional loud bit, I assume that either commercial software has some sort of filtering going on when loading, or I'm still missing something.
But for my needs, this is probably close enough.

-=-=-
Check out my excellent homepage!
Mon, 30 May 2022, 04:51
spinal
Something is still wrong, I get a very regular 'burst' of volume, so it still isn't decoding correctly. How though, I have no idea. This is supposed to be one of, if not *the* simplest audio compressions there is.

-=-=-
Check out my excellent homepage!