Klymins I don't know how to thank you. I also released version 0.31 thanks to you. The crazy thing is that I had to double-check all the functions that were mathematically perfect. The error, you won't believe, was in the fact that I allocated the memory inside a function and not in global mode. Absurd gcc makes these jokes. I took the opportunity to improve something. Unfortunately I don't think it is compatible with the previous version.


http://heartofcomp.altervista.org/ADCodec.htm

So what this codec uses for predicting and modelling future/past audio samples?

It should start with "adc..." ?

As for the heder structure, I haven't yet defined it well. The RIFF writing you see is due to the fact that I am currently recording the header of the Wav file to keep the structure of the wave source file in decompression.



struct WAVEHeader
{
    char  chunkID[4] = {'R','I','F','F'};       // Contains the letters "RIFF" in ASCII form
    long  chunkSize;                            // 4 + (8 + SubChunk1Size) + (8 + SubChunk2Size)
    char  format[4]  = {'W','A','V','E'};       // Contains the letters "WAVE" in ASCII form

    char  subchunk1ID[4] = {'f','m','t',' '};   // Contains the letters "fmt " in ASCII form
    long  subchunk1Size  = 16;                  // 16 for PCM
    short audioFormat;                          // PCM = 1 Values other than 1 indicate some form of compression
    short numChannels;                          // Mono = 1, Stereo = 2, etc
    long  FreqRate;                           // 8000, 44100, etc.
    long  byteRate;                             // shortRate * NumChannels * BitsPershort/8
    short blockAlign;                           // NumChannels * BitsPershort/8
    short bitsPershort;                        // 8 bits = 8, 16 bits = 16, etc

    char  subchunk2ID[4] = {'d','a','t','a'};   // Contains the letters "data" in ASCII form
    long  subchunk2Size;                        // This is the number of bytes in the data
};


struct ADCHeader
{
    char  chunkID[4] = {'A','D','C',' '};   // Contains the letters "adp " in ASCII form
    unsigned long  dataSize;                         // This is the number of bytes in the data
    unsigned long  direct_dataSize;                         // This is the number of bytes in the data
};




The structure allows me to load most .wav files


Second clarification. Unlike what I said, I had to put the predictor aside for the following reasons. It managed to get much closer to the ideal values ​​to be subtracted from the current value but it caused an anomaly. The difference data are somehow directly proportional to the wave values ​​themselves. Introducing a changing factor does not improve compression if I use multiple data writing keys.  Secondly, the predictor slowed down my compression and decompression. It follows that the predictor is nothing other than the compressed previous value. At this stage I am working on a new version which I believe will be one of the last before the definitive one. To increase the quality I will definitely have to slow down the compression but not the decompression. Once the core has been defined I will be able to think of a version that uses a VBR system. Of course, being a system that processes differences between wave values, I cannot obtain very low bitrates (<128 kbit) but I would be happy to obtain it. To do this I would have to do what mp3, AAC does, i.e. filter and remove the inaudible frequencies. This would result in very complex code.

I tried v0.60 right now with the default -q value and detected that it sounds terrible! The same sample (Melodi 6 from Supper Zill) encoded and decoded with the new version is attached below (with the original one of course). I absoulutely wouldn't use this codec for anything; it sounds terrible!