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.

A script may be busy or may have stopped working.  You can stop the script now or let it continue.

Panel: {panel name}: Library Tree
Script: adc02ef6a06f0d6db553bc56b2c: ###

• Weighted adaptive shaping method modified. Previous optional parameters have been removed and the option now takes a single optional parameter to determine the "width" of curve averaging to smooth the desired noise shaping curve over up to <n> FFT bins (dependent on the distance from each of the FFT the centre bin is located). Valid in the range 0 to 64; default = 0, i.e. no smoothing.
  
• Low quality preset range extended down to -10.0, with presets "U, unadvised" at q=-10, "D, dubious" at q=-8.75, "Q, questionable" at q=-7.5, "A, aggressive" at q=-6.25. Quality presets at and above "X, extraportable", q=-5, remain unchanged
  

-q U -s W 8 taps 20 -A 0.14 -a 4 --limit 13782 --feedback 10

https://youtu.be/siKBrO14Aw4?si=A2TMfjDMVq4X6SQW

Obviously, download latest version of component, not that is used in video. ffmpeg build is used in video for example. You can use any ffmpeg build that works on your system.