# A High Efficiency Multistage Coder for Lossless Audio Compression using OLS+ and CDCCR Method
## 8 Schematic Diagram of the Proposed Cascading Audio Data Encoder Method  
In Figure 3, the diagram of the target encoder proposed in this work is presented. Although the cascading concept was previously used [24; 29] and was considered the most effective way of lossless audio compression, our approach demonstrates that there is scope for further significant improvement within this concept. In general, we can distinguish two main stages: In the first stage, the prediction value \(\hat{x}(n)\) and prediction error \(e(n)\) are calculated (see Formula (23), which was executed by the blocks in the border in the form of a dashed line: OLS+, 3 stages of LMS, CDCCR). The second stage is coding prediction error to binary stream (implemented by Golomb code and CABAC blocks). Figure 3: Schema of our approach for lossless audio coding. Introducing our proposal of OLS+ method to the initial prediction stage allows to remove the interchannel dependencies with the highest correlation with the currently coded sample \(x(n)\). The Formula (2) is used here and the method of adaptation of the prediction coefficients described in Section 4.2. The resulting prediction error \(e_{1}(n)\) and previous errors \(e_{1}(n-i)\) contained in the buffer become an input data stream for the next block, which is the first stage of LMS. In LMS1, the dependencies between further samples are removed by linear prediction of the order \(r_{1}=1000\). Because as an optimised version of adaptive linear prediction (NLMS, see Section 3) with a relatively slow convergent coefficient adaptation procedure (Formula (5)) is used; it cannot fully remove these dependencies. For this reason, this method is used in a cascade manner in two further steps of prediction improvement (using descending orders \(r_{2}=380\) and \(r_{3}=10\)), minimising the mean of prediction error. These three LMS blocks use the Formula (20) to calculate consecutive predictive values \(y_{2}(n)\), \(y_{3}(n)\) and \(y_{4}(n)\) and the corresponding prediction errors \(e_{2}(n)\), \(e_{3}(n)\) and \(e_{4}(n)\) obtained from Formula (22). The last stage in the prediction part is an attempt to remove the context dependent constant component by using our proposal CDCCR method, which has not been widely used in lossless audio compression before. After subtracting from \(e_{4}(n)\), the constant component \(C_{\text{mix}}\) calculated from Formula (24), we obtain the final form of the prediction error \(e(n)\), which is transmitted to the input of the adaptive Golomb encoder (Section 7.2). This block generates a bit stream, which by use of context dependencies between individual bits is encoded using an arithmetic encoder. In contrast to frequently used multivalue arithmetic encoders, the binary variant of the CABAC adaptive binary encoder is used (see Section 7.3). The proposed solution is time symmetrical, which means the same complexity is also in case of decoding. The decoding procedure is very similar to the coding stage. In the first two steps (arithmetic decoder and Golomb decoder), the prediction error \(e(n)\) must be recovered from the binary stream. This prediction error is added to the predicted value, which is calculated in the same way as in the encoder (see the blocks in the border made by the dashed line in Figure 3), obtaining a decoded sample of \(x(n)\). This is a simple transformation of Formula (23) into the following generalised form of the \(K\)-step predictive cascade:  
\[x(n)=e(n)+\lfloor y_{1}(n)+y_{2}(n)+\ldots+y_{K}(n)+C_{\text{mix}}+0.5\rfloor. \tag{35}\]  
Our implementation of the solution proposed here was done in the C language, without considering optimisation of the code or attempts to its parallelisation. However, even with stereo and 44,100 samples per second, it still works online, and the encoding and decoding times are linearly dependent on the number of samples. The encoding program uses one 3.4 GHz i5 processor core in 69.07% (version with ALCM+, see Figure 2) and 93.36% (version with OLS+ block, see Figure 3).