Hi there ...
do you know if there is "lossless ADPCM" or is it always lossy? From what I've gathered, the most common mode is lossy ADPCM at 4-bit. Do you know if there exists a 16-bit mode, too ? 44,1 Khz ?

thanks a lot!

The reason for asking is that I am interested in a digital recorder, which has these features:

* WAV recording (ADPCM)
* 2GB storage (~3,5h using WAV)

(that's part of the features description)

So I was wondering, if these 3,5 hours would be "true" PCM wave (16 bit, 44,1 khz) or lossy ADPCM .... ?

No, there is no lossless ADPCM. The only compression that ADPCM achieves comes precisely from reducing the bit-depth (roughly speaking) to 4 bits, so a 16-bit ADPCM would basically achieve no compression at all.

Thanks for helping me!

So what's the maximal bit-depth you can use with ADPCM? I've heard 8-bit, is that correct ?
I thought the good thing about ADPCM is that the continuation of waveform is predicted and that only the difference (of the actual value vs. the predicted value) is stored. In theory this would be lossless (at 16-bit) and still achieve file size reduction, no ?

You could fit 3 hours 9 minutes of 44.1kHz 16-bit stereo audio in 2GB - that's without using ADPCM, which would make it 12.5 hours.

Cheers,
David.

You're welcome.


I wouldn't know, but you're probably right.


In theory, yes, if the difference is losslessly stored you can perfectly recreate the entire waveform. But there is one problem to that. Storing the difference takes twice as many bits as just storing the waveform as is. (I'll explain why if you're interested.)

ADPCM achieves compression by truncating data. Why do you think the lossless coders don't achieve such levels of compression?

Thanks for looking into this, too!

If you can fit 3 hours 9 mintues of PCM wave at 44.1kHz/16bit stereo in 2GB and 12.5 hours with ADPCM, what do you think "3,5 hours" correspond to ?

If that's true, you are right of course. I just don't have an encoder for ADPCM@8bit or 16bit, so I cannot compare file sizes ....


Yes, I'd be VERY interested (I'd die for this information ... almost

Because when you look at joint stereo for example, you can reduce losslessly reduce the file size by using the waveform difference ....

BTW, here is the mp3player/sound recorder I was talking about:

http://www.soundman.de/

I translated the german feature description which differs from the english description, but I used it as the company's native language is german, and I guess the german description is therefore more accurate in case of doubt.

Er, I just realised a mistake I've made - you don't need two times more bits, you need just one additional bit.

But let me at least explain that.

So let's say that we've got a 2-bit audio file - yes, ridiculous, but let's keep it simple. So the possible sample values are 00, 01, 10 and 11. And now, we want to store the differences between two samples. So what are the possible differences we might encounter? Let's look at the example where the current sample has a value of 00 and we want to store the difference between that sample and the next one. The possible values of the next sample are, obviously, 00, 01, 10 and 11 - so the possible differences are 0, +1, +2 and +3. But that's not all - those are positive differences. What if the current sample has a value of 11 and we want to store the difference between that sample and the next one? Then, obviously, the possible differences are 0, -1, -2 and -3. So all in all, we need to be able to store "-3", "-2", "-1", "0", "+1", "+2" and "+3" - that's seven unique values. Can we store seven unique values using only two bits? Not a chance - with two bits you can only have four unique words - 00, 01, 10 and 11. We need one more bit - with three bits we can assign eight unique values (even though we need only seven). So, for example, we might store the differences like this:
000 = -3
001 = -2
010 = -1
011 = 0
100 = +1
101 = +2
110 = +3

The reason why this happens is simple - since the differences can be positive or negative, you need an additional bit which will tell you whether the difference is positive or negative (except for zero, which is the reason why we don't need all eight unique values but only seven).


In fact, there is also a catch with joint stereo - at least the conversion to mid/side, which I believe you're talking about.
See, if you want to convert left and right channel to mid and side channel losslessly, you will also need one additional bit...
Do you want me to explain why is that, too?

yes, I was talking about conversion to mid/side. And no, you wouldn't need to explain that, too, as I guess the reasons are exactly the same as those you already mentioned here.

But when looking into your example, I can't help but wondering if you aren't wrong ....

(1) First of all you started off talking about a 2-bit audio file, but the example you subsequently used is 3-bit audio (000,001,etc.), with 8 possible values (000 through to 001), so the differences wouldn't have to be encoded in 2-bit, but 3-bit which is possible as you can see

(2) I think you are unclear as to where the file size reduction actually comes from. It does NOT come from the fact, that you need less bits to store all the possible difference values, BUT from the fact, that the difference is LIKELY to be smaller than the absolute values!
Besides: that's the reason, why mid/side stereo CAN represent more information to encode than ss stereo and a good mp3-encoder (for example) decides on which blocks to use ss or ms. At least that's my take on it.

I'd honestly love to see a documentation, that clearly states what is possible for ADPCM in terms of kHz and bit depth. Even Wikipedia is mute on that point ...

Let me explain it that way: If your waveform prediction were perfect, you would have to store these differences: 0,0,0,0,0,0,0 .... Or with an almost-perfect prediction : 0,2,1,1,1,0,0,1,0,0,1,2,0,1 ...

This difference values would be more compressable when running some lossless mathematical algorithms on them (huffman coding, etc.). But does ADPCM use lossless compression too (in addition to lossy bit-reduction to 4-bit) ?

I didn't use 3-bit audio.

As I clearly said:

The values of all samples there are two-bit values. The point is that, to store the resulting differences, you need to use three bits.

I'm not sure what confused you there.


Yes, exactly. But what in the case when the difference is not smaller than the original values? In that case ADPCM truncates data.

Of course, you used 3 bit.

1 bit = 0,1
2 bit = 00,01,10,11
3 bit = 001,010,011,100,101,110,111
4 bit = 0000,0001,etc...

No. If A and B represent any value between 0 and 255 (8 bit), the difference can also be encoded with 8 bit (as the difference can be 255 at most if A=0 and B=255 and vice versa). This holds true for any bit depth x.

Well of course I used three bits - I used three bits in order to store the differences! If you actually read my post carefully you'd perfectly understand what was going on. :-/


I'm sorry, but you are wrong. The absolute value of the difference will, indeed, always be in-between 0 and 255. But it's not the absolute value of the difference we're interested in, but the actual difference - meaning that whether the difference is positive or negative also matters. If you want you can try re-reading the post in which I've explained it already. If not, here is a shorter version again:

Ok, let's say it is 8-bit this time. So values range from 0 to 255. Nice. And we want to store the difference between each two samples - so far everything is clear. But carefully now:

If one sample has a value of 200 and the next sample has a value of 201, the difference is +1. If, however, one sample has a value of 200 and the next value is 199, the difference is -1.

Is that clear? I hope it is. So, therefore, you need to be able to store both +1 and -1.

The same goes if one value is 200 and the next is 202, or one value is 200 and the next value is 198 - you need to be able to store both +2 and -2.

Increasing the difference like that, we'll finally get to the maximum possible difference in both positive and negative directions:

• when first value is 0 and the next value is 255, the difference is +255,
• when first value is 255 and the next value is 0, the difference is -255.

So notice that for every number from 1 to 255 we have two possible differences involving that number - positive and negative. For zero, we've got only one possibility.

How many values did we start with? Here they are: 0, 1, 2, 3, 4, 5,..., 255.

And how many values did we end up with? Here they are: 0, -1, +1, -2, +2, -3, +3, -4, +4, -5, +5,...,-255, +255.

Is it now obvious that we have two times more values than what we started with (actually two times minus one, because zero wasn't doubled)?

OK, I understand you now. Sorry, that I was on the wrong track.


This outcome is still very surprising ... to say the least !!! I've never heard that storing the difference would need more information than just storing the absolute values .... that's so .... well, surprising ...

That's strange, my calculations yield 3,38 and 3,30 hours respectively (for 1GB=1024 or 1000).

Well... that's how it is.

To me it is obvious, because, for example, for 8 bits, you still have 256 possible differences - but whether the difference is positive or negative also matters. Note: positive or negative - two possibilities - that means that you're certainly going to need one additional bit in which to store whether the difference is positive or negative.

If it's still confusing, let's look at the simplest example possible: 1-bit!

The possible values are 0 and 1. Now you want to store differences between two samples.

Now, let's assume the first value is 0. There are two possibilities for the next value: it can be either 0 or 1.
If the next value is 0, the difference is 0.
If the next value is 1, the difference is +1.

Now we only need to see what happens if the current value is 1. Again, there are two possibilities for the next value:
If the next value is 0, the difference is -1.
If the next value is 1, the difference is 0.

And again - the difference can have three possible values (0, +1 and -1), which is more than two possible values which we started with, and it would require an additional bit in order to be stored.

If you want to learn, how lossy ADPCM works, you may for instance read this (pdf) ADPCM specification at multimedia.cx (my first result at google, there will be others).

If you want to evaluate, what can be achieved with lossless compression of the sample differences, you may try FLAC -0.

@doccolinni: Yes, I already got it, but thanks for posting one more example to make it clear! I was just confused and still am ... not because I don't understand the maths, but because it "feels" weird that the difference would need more bits to be encoded (at least in a worst-case scenario).

@TBeck: Thanks for the infos. What should I try FLAC -0 with ? ADPCM ? To see file size difference or what ? I also had a look at your pdf. It seems very interesting. Unfortunately it doesn't say anything about:

There are so many ADPCM codecs... http://wiki.multimedia.cx/index.php?title=...CM_Audio_Codecs

About MS ADPCM:
1) http://msdn.microsoft.com/en-us/library/bb943864(VS.85).aspx - "PCM input files must have a sample rate in the range of 1Khz-50Khz".
So at least frequencies from 1kHz to 50 kHz are supported.

2a) http://msdn.microsoft.com/en-us/library/cc677008(VS.85).aspx - "ADPCM can achieve compression ratios of up to 4:1."
2b) http://www.xentec.be/products/vox_studio/h...dpcm_format.htm - "The compression ratio obtained is relatively modest: 16-bit data samples encoded as 4-bit differences result in 4:1 compression format".
So MS ADPCM stores 4-bit differences between the current sample and the previous.

Well, for example, a value of 240 can't have a difference of +255, so you could reduce the amount of possible differences to -128 to 255 (or -127? I always have problems with such math ), if you say that 240 with a difference of +255 should be read as a difference of -255...

That doesn't shave of a single bit (-128 to 255 still requires 9 bits) but probably you could spread this to get less truncation when used with 8-bit or lower. (Sounds quite simple to me... is something like this used? I don't know anything about ADPCM)

I think you mean frequencies from 0.5 to 25 kHz.

The worst case for encoding differences is a full-scale square wave at 1/2 the sample rate. For 8 bits this means alternating 0 255 0 255 ...

The difference value is alternately +255 and -255, requiring 9 bits. Understood?

ADPCM is a technique, of which there are many variants. The technique itself could operate on any sample frequency, bit depth, and use any ratio of bits to represent the compressed signal vs the original (more bits = more quality obviously).

I think the main thing glossed over in this back and forth discussion is the "Adaptive" part of ADPCM. These codecs don't simply store the difference - that would be DPCM, and be fairly pointless (except the result probably would be more compressible by other techniques). Audio signals are predictable to some extent. If you looked at a sine wave, the changes in difference from one value to next see that each difference value is similar to the previous one (but slightly different). The adaptive part of ADPCM kicks in here. From what I remember of IMA ADPCM, there is a table of difference values, that range from very small to very large, in a non-linear layout (I think it is about 128 entries). The 4 bit values along with an index into that table actually determine which value from the table is selected to use as the difference value. The index into the table is the adapating part, as it will slide along the table if it sees that the predicted differences were not optimal. I think in the case of IMA ADPCM the moving along the table happens in response to the 4-bit pattern - the extreme value of 0 would see it shift down the table, and 15 would see it shift up, etc. All in all it makes for not a very good codec as it really falls apart on signals it can't predict well.

Anyway, to the original question, no, there is no lossless version of a purely ADPCM based codec. ADPCM is a compression technique that could be used as a larger more complex codec to achieve lossless (or lossy) compression. I have no idea how lossless codecs work but I wouldn't be surprised if ADPCM techniques were used within them as the residual might indeed be more compressible.

So what you're basically proposing is this:

• Values range from 0 to 255.
• For the value of 0, the possible differences between it and the next value range from 0 to +255, so let's ignore the differences which are possible only in other cases and assign values from 0 to 255 to these differences, which are possible in this case.
• For the value of 1, the possible differences between it and the next value range from -1 to +254, so let's ignore the differences which are possible only in other cases and assign values from 0 to 255 to these differences, which are possible in this case.
• For the value of 2, the possible differences between it and the next value range from -2 to +253, so let's ignore the differences which are possible only in other cases and assign values from 0 to 255 to these differences, which are possible in this case.
  .
  .
  .
• For the value of 255, the possible differences between it and the next value range from -255 to 0, so let's ignore the differences which are possible only in other cases and assign values from 0 to 255 to these differences, which are possible in this case.

Well, a neat idea.

But, do you see what we've done with this?

Let's take a look at a couple of examples of possible situations and how would we end up encoding them with this rule.

Let's assume that the current value is 0. If the next value is:

• 0, then the difference is 0. Looking at how we assigned values from 0 to 255 in the case when previous value is 0, we would store this difference simply as "0".
• 1, then the difference is +1. Looking at how we assigned values from 0 to 255 in the case when previous value is 0, we would store this difference simply as "1".
• 2, then the difference is +2. Looking at how we assigned values from 0 to 255 in the case when previous value is 0, we would store this difference simply as "2".
  .
  .
  .
• 255, then the difference is +255. Looking at how we assigned values from 0 to 255 in the case when previous value is 0, we would store this difference simply as "255".

Ok, let's assume now that the current value is 1. If the next value is:

• 0, then the difference is -1. Looking at how we assigned values from 0 to 255 in the case when previous value is 1, we would store this difference simply as "0".
• 1, then the difference is 0. Looking at how we assigned values from 0 to 255 in the case when previous value is 1, we would store this difference simply as "1".
• 2, then the difference is +1. Looking at how we assigned values from 0 to 255 in the case when previous value is 1, we would store this difference simply as "2".
  .
  .
  .
• 255, then the difference is +254. Looking at how we assigned values from 0 to 255 in the case when previous value is 1, we would store this difference simply as "255".

Let's see one more example. We'll assume now that the current value is 255. If the next value is:

• 0, then the difference is -255. Looking at how we assigned values from 0 to 255 in the case when previous value is 255, we would store this difference simply as "0".
• 1, then the difference is -254. Looking at how we assigned values from 0 to 255 in the case when previous value is 255, we would store this difference simply as "1".
• 2, then the difference is -253. Looking at how we assigned values from 0 to 255 in the case when previous value is 255, we would store this difference simply as "2".
  .
  .
  .
• 255, then the difference is 0. Looking at how we assigned values from 0 to 255 in the case when previous value is 255, we would store this difference simply as "255".

Well interesting. So in every case, when the next value is n, you are going to store n. I would hardly call that storing the difference - it's actually called not doing anything to the audio data and just storing it as it already is!

Well, yes, that sound quite ridiculous But if you do it like this?

For value 0, the possible differences are -127 to 127, in order 0, 1, -1, 2, -2, 3, -3,....,127, -127
For value 1, the possible differences are -128 to 126, in order 0, 1, -1, 2, -2, 3, -3,....,126, -126, -127, -128
For value 2, the possible differences are -129 to 125, in order 0, 1, -1, 2, -2, 3, -3,....,125, -125, -126, -127, -128
...
For the value 255, the possible differences are -255 to 0, in order 0, -1, -2, -3, ...., -254, -255

You are storing differences in a really simple way which still takes up 8-bit (so not more than the original) but is is easier to compress, as most values will be in the lower range. (that's were the adaptive part kicks in)

Er... wait, how do the differences for 0 range from -127 to 127?

Are you saying that, if the current value is 0 and the next value is also 0, then we would store -127?

I'm not really sure what do you mean by "in order 0, 1, -1, 2, -2, 3, -3,....,127, -127", either...

Sorry, was thinking wrong again xD I was confusing signed and unsigned PCM.

For value 0, the possible differences are 0 to 255, which you store in order 0, 1, 2, 3, ..., 255
For value 1, the possible differences are -1 to 254, which you store in order 0, -1, 1, 2, 3, ..., 254
...
For value 100, the possible differences are -100 to 155, in order 0, -1, 1, -2, 2, -3, 3, ...., 154, 155
...
For the value 255, the possible differences are -255 to 0, in order 0, -1, -2, -3, ...., -254, -255

With "which you store in order" I meant
map the first with 0
map the second with 1
map the third with 2
....
map the last with 255

If you map it like this, and the data is quite easy to compress (i.e., the values are close to each other) most values will be in the lower range, from 0 to for example 64. That would use only 6 bits.

Well, it was just a thought, I'm not really good at math

IMHO lossless DPCM/ADPCM must have the same bitrate as original PCM.