You can also think of delta encoding as linear predictive coding (LPC) where only the prediction residual ($x[n]-\hat{x}[n]$ in @robertbristow-johnson's notation) is stored and the predictor of the current sample is the previous sample. This is a fixed linear predictor (not with arbitrary coefficients optimized to data) that can exactly predict constant signals. Run the same linear predictive coding again on the residuals, and you have exactly predicted linear signals. Next round, quadratic signals. Or run a higher-order fixed predictor once to do the same.

Such fixed predictors are listed in Tony Robinson's [SHORTEN technical report][1], yours in Eq. 4, and are also included in the [FLAC lossless audio codec][2] although not often used. Calculating the best prediction coefficients for each data block and storing them in a header of the compressed block results in better compression than the use of fixed predictors.

For $m$-bit input the residual is an $m+1$ -bit number, because it is the difference of an $m$-bit input and an $m$-bit prediction. However, removing the most significant bit (MSB) of the residual has no consequence in $m$-bit modular arithmetic, so the residuals can be stored as $m$-bit numbers.

The linear predictor is supposed to do the whitening, making the residuals independent. In lossless compression, what is left to do is to entropy code the residuals, instead of using run-length or other symbol-based encoding that doesn't work so well on noisy signals. Typically, entropy coding assigns longer code words to large residuals, approximately minimizing the mean encoding length for an assumed distribution of the residual values. A Rice code (also known as Golomb–Rice code or GR code) variant compatible with signed numbers can be used, as is done in FLAC (Table 1), or signed [exp-Golomb code][3] as is done in the h.264 video compression standard. Rice code has a distribution parameter that needs to be optimized for the data block and saved in the block header.

*Table 1. Binary codewords of 4-bit signed integers encoded in Rice code with different Rice code parameter $p$ values, using `FLAC__bitwriter_write_rice_signed` ([source code][4]). This variant of Rice code is a bit wasteful in the sense that not all binary strings are recognized as a codeword.*<br>
$\begin{array}{rl}
\begin{array}{r}\\-8\\-7\\-6\\-5\\-4\\-3\\-2\\-1\\0\\1\\2\\3\\4\\5\\6\\7\end{array}&\begin{array}{lllll}
p=0&p=1&p=2&p=3\\
000000000000001&000000010&000110&01110\\
0000000000001&00000010&000100&01100\\
00000000001&0000010&00110&01010\\
000000001&000010&00100&01000\\
0000001&00010&0110&1110\\
00001&0010&0100&1100\\
001&010&110&1010\\
1&10&100&1000\\
01&11&101&1001\\
0001&011&111&1011\\
000001&0011&0101&1101\\
00000001&00011&0111&1111\\
0000000001&000011&00101&01001\\
000000000001&0000011&00111&01011\\
00000000000001&00000011&000101&01101\\
0000000000000001&000000011&000111&01111\end{array}\end{array}$

As a further enhancement, encoding not just one but multiple residuals into a single codeword can more accurately accommodate the true distribution of residuals and [may give a better compression ratio][5], see [asymmetric numeral systems][6].


  [1]: http://mi.eng.cam.ac.uk/reports/svr-ftp/auto-pdf/robinson_tr156.pdf
  [2]: https://xiph.org/flac/format.html
  [3]: https://en.wikipedia.org/wiki/Exponential-Golomb_coding
  [4]: https://github.com/xiph/flac/blob/master/src/libFLAC/bitwriter.c
  [5]: https://dsp.stackexchange.com/questions/56539/prefix-code-of-symbol-pairs/56545
  [6]: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems