"sh_2444" contains 5 files with 24 bit and 44 or 48 Khz.

Quote from: TBeck on 2006-09-17 02:34:13

"sh_2444" contains 5 files with 24 bit and 44 or 48 Khz.

And these are compressed to around 60% of the original file sizes?
Unbelievable!
Are the lower bits of the samples constant?
Is the audio signal very quiet?

Doesn't 24/44 usually compress to around 80%?
(taking typical recording levels into account)

If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.

As a rule of thumb i would say:

If music is sampled at 44/48 KHz, you can expect compressors similar to mine to remove about the same amount of bits from the same music sampled at 16 or 24 bit. If it can remove 8 bits, you will achieve 50 percent compression ratio for 16 bit and 67 percent for 24 bit files.

If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.

If someone knows a place to download some more 48K/24-bit samples of high quality (not sampled with a cheap and noisy soundcard), please let me know.

this isn't very useful for your situation but i hope posting this link is still ok
it contains samples of different and non-standard wave-files...perhaps
this helps you improving the wave-reader.

http://www-mmsp.ece.mcgill.ca/Documents/Au...VE/Samples.html

You may be able to find stuff at archive.org. Alot of it has been converted to 44.1khz and 16bit though
Archive.org 24bit Flacs Some of these may be 48khz

          Yalac V0.11a                                    |  FLAC  | Monkey | Mpeg4  | Ofr    |
          Turbo  Fast   Light  Normal High   Extra  Insane|  -8    |  High  |  -7    | High   |
----------------------------------------------------------+--------+--------+--------+--------+
sh_2444                                                   |        |        |        |        |
Ratio:    58.53  58.23  57.98  57.87  57.76  57.64  57.57 |  60.28 |  57.77 |  57.45 |  57.64 |
EncoTime:  6.33   8.48  10.88  15.05  19.65  27.70  86.32 |  96.54 |  20.96 | 877.74 |  63.29 |
----------------------------------------------------------+--------+--------+--------+--------+
sh_2496                                                   |        |        |        |        |
Ratio:    54.58  54.33  54.21  54.18  53.84  53.79  53.76 |  57.92 |  53.88 |  53.65 |  53.50 |
EncoTime: 12.66  17.34  22.04  29.22  38.18  48.59 107.73 | 184.58 |  40.78 |2458.40 | 121.57 |
----------------------------------------------------------+--------+--------+--------+--------+

I hope i am not boaring you with my reports. It's just some kind of a reward for me to post about some progress after many lonely hours of work.

i have read that you cascade different predictors (up to 5 if i remember correctly).
do you use a special weighting between the different stages (such as a sign-sign lms filter)?

Do you mean this statement: "...Possibly it works better if only one Lpc-Filter is beeing used. But yalac currently sends the signal through up to 4 different filters...."?

The signal may go through up to 4 filters:

1) Initial filtering
2) PreFilter (optional)
3) Channel decorrelation (optional)
4) Linear prediction

I would expect an weighting approach of different parallel filters to be most efficient, if it is adapting very fast to changes of the signal characteristics. Because it isn't efficient to store the updated filter parameters and weights too frequently into the bit stream, you would have to perform the adaption on the encoder and decoder side to avoid the need to store the parameters.

But i don't want the decoder to perform any (continous) adaption, because 1) it would be slower and 2) i suppose, that it is far more probable to run into patent issues witch such adaptive approaches. Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.

weight0 = weight1 = weight2 = init_weight

for (i=0;i<NumSamples;i++)
{
  P0 = first stage predictor
  P1 = second stage predictor
  P2 = third stage predictor

  PW = (weight0 * P0 + weight1 * P1 + weight2 * P2) >> Shift

  Error = Input - PW

  if (Error > 0)
  {
    (P0<0)?weight0--:weight0++;
    (P1<0)?weight1--:weight1++;
    (P2<0)?weight2--:weight2++;
  } else if (Error < 0)
  {
    (P0<0)?weight0++:weight0--;
    (P1<0)?weight1++:weight1--;
    (P2<0)?weight2++:weight2--;
  }
}

1) Initial filtering
2) PreFilter (optional)
3) Channel decorrelation (optional)
4) Linear prediction
Each next filter is working on the output of the previous one.

Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.

i think that the weighting of a cascade is better because it's more stable against sudden changes
in signal characteristics. ...

the algorithm i mentioned is extreme simple. it's used in MP4ALS btw.

And with what precision do you work here? Are the samples quantized to the original precision after each stage? If yes: Have you thought about that the quantization noise adds up and is likely to decrease compression performance?

Quote from: TBeck on 2006-09-27 13:16:21

Hence abolutely no adaption in the decoder and only a block (subframe) based adaption in the encoder.

I assume you're talking about forward-adaptive versus backward-adaptive prediction and that you're using a pure forward-adaptive scheme. Correct?

Possibly i will work on another (adaptive) encoder if the current encoder has been released...

the algorithm i mentioned is extreme simple. it's used in MP4ALS btw.
here's some C pseudo code

The MPEG-4 ALS codec uses forward-adaptive Linear
Predictive Coding (LPC) to reduce bit rates compared
to PCM, leaving the optimization entirely to
the encoder.

That's news to me. I havn't found any informations on the net regarding ALS doing backward-adaptive prediction. From what I know it's strictly forward-adaptive and nonlinear quantized parcor coefficients are transmitted per subblock. At least this was the case a year ago. 

Cheers!

that's nice to know. i've hacked something together in 1month and it's on par with Monkey's Audio
compression wise.
...

You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!

Quote from: TBeck link=msg=0 date=

You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!

that was not my intention. that you've archived such a high compression ratio with a foward-only predictor is really awesome.
and since i'm working in the field of compression for about 10 years i'm able to code very fast 
but as always i'm too shy to publish something...

Quote from: TBeck link=msg=0 date=

You shouldn't tell me this! It's cruel!  I have spend years to be on par with at least Monkey High!

that was not my intention. that you've archived such a high compression ratio with a foward-only predictor is really awesome.

but as always i'm too shy to publish something...

V0.12 is done