Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Good requantizers? (Read 9064 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Good requantizers?

What requantizers do you know for changing PCM bit depth? For example from 16 to 8-bits.
I know about simply discarding bits, rounding, dithering with noise shaping.
This one sounds quite impressive: https://www.bitsnbites.eu/hiqh-quality-dpcm-attempts/
I also remember 2Bdecided saying that lossyWAV would be quite an efficient requantizer, but I see no options for forcing bit limits to use no more than 8-bits for example?
What else?

Re: Good requantizers?

Reply #1
Do you want PCM requantization or compression?  If the former, Sox is a good choice, but there are many other options too.  If you want compression, FLAC or MP3 have better compression than DPCM. 

 

Re: Good requantizers?

Reply #2
Comment from https://github.com/gcp/opus-tools/blob/master/src/opusdec.c#L148:

Quote
This implements a 16 bit quantization with full triangular dither and IIR noise shaping. The noise shaping filters were designed by Sebastian Gesemann based on the LAME ATH curves with flattening to limit their peak gain to 20 dB. (Everyone elses' noise shaping filters are mildly crazy)
The 48kHz version of this filter is just a warped version of the 44.1kHz filter and probably could be improved by shifting the HF shelf up in frequency a little bit since 48k has a bit more room and being more conservative against bat-ears is probably more important than more noise suppression.
This process can increase the peak level of the signal (in theory by the peak error of 1.5 +20 dB though this much is unobservable rare) so to avoid clipping the signal is attenuated by a couple thousandths of a dB. Initially the approach taken here was to only attenuate by the 99.9th percentile, making clipping rare but not impossible (like SoX) but the limited gain of the filter means that the worst case was only two thousandths of a dB more, so this just uses the worst case.
The attenuation is probably also helpful to prevent clipping in the DAC reconstruction filters or downstream resampling in any case.

And this is it:
https://wiki.hydrogenaud.io/index.php?title=Noise_shaping
(Sampling rate of 44100 Hz, derived from LAME's ATH formula)

Also I remember S. Gesemann published a re-quiantizer app based on this, built with Java,  here in HA... but I don't remember the exact thread.

Re: Good requantizers?

Reply #3
Do you want PCM requantization or compression?  If the former, Sox is a good choice, but there are many other options too.  If you want compression, FLAC or MP3 have better compression than DPCM. 
I want requantization, not compression. Especially reduction to 8-14 bits.

I know about sox but it mostly does dithering (with noise shaping), I'm interested in other methods with as little noise as possible (or at least having adaptive requantization and noise shaping like lossyWAV, but I'm unable to output 8 bit PCM with it).
DPCM sounds very impressive but it decodes to 16bit PCM and after decoding I see more bits in use than selected.

Re: Good requantizers?

Reply #4
Do you want PCM requantization or compression?  If the former, Sox is a good choice, but there are many other options too.  If you want compression, FLAC or MP3 have better compression than DPCM. 
I want requantization, not compression. Especially reduction to 8-14 bits.

I know about sox but it mostly does dithering (with noise shaping), I'm interested in other methods with as little noise as possible (or at least having adaptive requantization and noise shaping like lossyWAV, but I'm unable to output 8 bit PCM with it).
DPCM sounds very impressive but it decodes to 16bit PCM and after decoding I see more bits in use than selected.

The reason encoding to DPCM sounds good is that it is a form of lossy compression.  If you don't want compression, then your options are much more limited since there is a fixed amount of noise that must be present in an uncompressed bitstream of a given size.  You can use things like noise shaping to move that noise around (usually to higher frequencies where it is less noticeable), but you can't get rid of it without either introducing compression or increasing the bitrate. 

Re: Good requantizers?

Reply #5
So when on https://www.bitsnbites.eu/hiqh-quality-dpcm-attempts/ they show 8 bit file, there actually is 16 bits of data but compressed to a file of an 8 bit equivalent?
I thought that they actually requantize to 8 bits and the file is simply half of the 16 bit size no matter if in DPCM or PCM form.

Re: Good requantizers?

Reply #6
DPCM, and also ADPCM, compress the file to delta values, usually of lower precision than the actual sample size. The decoded output would actually be 16 bits, but the compressed file is either 8 or even 4 bits per sample. Information is sometimes lost in the compression process, due to precision limits or other errors, but it usually only differs on the level of mostly inaudible noise.

Re: Good requantizers?

Reply #7
If we create 8 bit DPCM file, can we decode it losslessly to 8 bit PCM?

Re: Good requantizers?

Reply #8
Not really. And there's no point to encoding 8 bit PCM to 8 bit DPCM, except to possibly make certain waveforms more compressible with conventional compression algorithms on top of the DPCM transformation.

The site you mentioned above encodes 16 bit PCM to 8 bit DPCM, but the deltas still decode to 16 bit samples.

Re: Good requantizers?

Reply #9
Yes I do mean about encoding 16bit PCM to 8bit DPCM, but I thought that it would decode losslessly to 8 bit PCM (that delta is only used for convenience, like L/R vs M/S coding). Now I understand that deltas are 8 bit and we need more than 8 PCM bits to decode it losslessly.

So, to summarize - are there any other interesting ways to requantize 16 PCM bits to 8 PCM bits except simply discarding bits, rounding, or dithering with noise shaping?
There's so many resampling algorithms...

Re: Good requantizers?

Reply #10
So, to summarize - are there any other interesting ways to requantize 16 PCM bits to 8 PCM bits except simply discarding bits, rounding, or dithering with noise shaping?

No, or at least none that are better.  An 8 bit PCM signal has an SNR of < ~48dB.  You can use noise shaping to move noise to low frequencies or to high frequencies, but the SNR is still limited to 48 dB.  If you want to increase SNR,  you need more bits or to compress those bits.

Re: Good requantizers?

Reply #11
There is also A-law and µ-law as another form of lossy compression with fixed bit-per-sample count, but as saratoga indicated, those don't sound better than DPCM since they are missing the prediction part (and are, therefore, less efficient).

Note that A-law and µ-law are similar in concept to a floating-point number representation. I just rediscovered this Float16 discussion which I remembered, and A/µ-law are a kind of "Float8" representation. But all of this represents lossy requantization, I don't think any requantization to a fixed lower bit-depth can, in general, be lossless.

Chris
If I don't reply to your reply, it means I agree with you.

Re: Good requantizers?

Reply #12
These kinds of discussion really blurred the line between lossy and lossless. For instance, int32 and float32 only have 25 bits of overlapping lossless values (+/-16777216) so both formats are "lossy" if you are converting back and forth and it is unfair to call either format "lossless".

Let's say, if 16-bit a-law/mu-law were being chosen as the CDDA data format in the 1980s, would we still call 16-bit LPCM "lossless"?

BTW, if I have something to complain about typical floating point formats, I would say they have too many wasted NaNs, and there is no flexibility to choose the amount of exponent vs fraction bits. If you define your own floating point types, then they are not accelerated by generic processors.

Integers are wasteful in another way as well, of course.

Re: Good requantizers?

Reply #13
These kinds of discussion really blurred the line between lossy and lossless. For instance, int32 and float32 only have 25 bits of overlapping lossless values (+/-16777216) so both formats are "lossy" if you are converting back and forth and it is unfair to call either format "lossless".

Let's say, if 16-bit a-law/mu-law were being chosen as the CDDA data format in the 1980s, would we still call 16-bit LPCM "lossless"?
This thread is about requantization of existing digital waveform data to a lower bit-depth. So if your "master" audio format (e.g. Float16 taken from a hypothetical companding CDDA format, as you say) would not be requantized, there wouldn't be any reason to call it lossy IMHO.

I think the major source of confusion here is that people tend to mix up the concepts of "lossy" and "perceptual coding". Converting e.g. 16-bit PCM from CD to 8-bit PCM (or DPCM, or A/µ-law), or Float32 to Float16, is lossy since you lose information in that process. The only principal difference between that kind of bit-rate reduction and more sophisticated MP3/AACish compression is that the latter use an adaptive frequency representation along with a perceptual model to "hide" the distortion introduced by the requantizer (which, in case of MP3, AAC, and later MPEG standards is quite similar to A/µ-law, by the way).

Chris
If I don't reply to your reply, it means I agree with you.

Re: Good requantizers?

Reply #14
Yes. It makes more sense to use the term "perceptual coding".

Re: Good requantizers?

Reply #15
By lossy/lossless I meant:

16bit PCM --lossy--> 8bit DPCM --lossless--> 16bit PCM

I was hoping it looks like that:
16bit PCM --lossy--> 8bit DPCM --lossless--> 8bit PCM

It's obvious that requantizing to lower bit depth is lossy. I thought that conversion from DPCM to PCM at the same bit depth is lossless though.

Re: Good requantizers?

Reply #16
Hmm, I guess that depends on the 'D', i.e. way the predictor in your particular DPCM format works. Generally speaking, when decoding each DPCM value (by adding the predicted value which is also requantized to 8 bit), you may in some cases end up with a larger value range than what would fit into 8 bit. But with proper format constraints in place, such situations could be avoided, and then indeed the decoding might be lossless. But I don't know of any such simple DPCM format (without adaptive requantization).

Chris
If I don't reply to your reply, it means I agree with you.

Re: Good requantizers?

Reply #17
OK I made another non-DPCM companding format for fun, let's call it UA-law. It compresses to 8 bits and expands to 16 bits.
X

To encode, drag one or more uncompressed 16-bit .wav files into UA-law.exe, new files will be saved in the same location as the original files, with "-ComP.waV" added at the end of the file names. The encoded files have same format and size as the original, but only the lowest +/-127 sample values are used, therefore volume level is very low, and can achieve high compression ratio with 7z and FLAC.

The program uses file name to switch between encode/decode modes, if the files end with "-ComP.waV" (case sensitive), decode mode will be engaged. To decode, drag the "-ComP.waV" files into UA-law.exe, the decoded files will end with "-ComPand.wav" and can be directly played.

If for whatever reason you can't or unwilling to run the program, I attached some sample files, using the infamous eig.wv, compared to u-law and a-law.


Re: Good requantizers?

Reply #18
Quote
16bit PCM --lossy--> 8bit DPCM --lossless--> 8bit PCM

It's obvious that requantizing to lower bit depth is lossy. I thought that conversion from DPCM to PCM at the same bit depth is lossless though.
No.    Any change (any irreversible change) is a loss of information/data.     And in the end you have a regular 8-bit PCM file with the usual quantization noise and resolution limits.

...In the video world they call it "LPCM" (linear PCM).

Off topic, but I'm old enough to remember the analog days and the early digital days.    I was surprised that normal-everyday digitization (CDs and in recording, etc.) was linear.    (Except I believe the telephone system never used linear PCM.)    

Re: Good requantizers?

Reply #19
FYI, both u-law and a-law use 8 bit samples to store the data, using something vaguely resembling floating point. The 8 bits contain a sign bit, an exponent (shift count), and a quantized almost mantissa of the data. Both have different ways of dealing with the exponent value. A-law, for instance, has the two lowest exponent values shortcut to adding two specific smaller fractions to the quantized value.

So they're sort of logarithmic precision samples, but not much else, since there's no delta math involved. They still have minor 8 bit quantization noise, but apparently A-law handles this better than u-law.

VGMStream contains decoders for both in its pcm_decoder.c source file, since there are a number of random games which use these formats.

Re: Good requantizers?

Reply #20
OK I made another non-DPCM companding format for fun, let's call it UA-law. It compresses to 8 bits and expands to 16 bits.
Can you give some more details on your algorithm? Which encoded 8-bit sample values map to which decoded 16-bit values?

Chris
If I don't reply to your reply, it means I agree with you.

Re: Good requantizers?

Reply #21
It's a .net program, so the source can be viewed with ILSpy.
For encoding, second column is the input value threshold, can handle -32768. Zeros are unchanged.
For decoding, column 1 is translated to column 3.
Code: [Select]
1       2       1
2       5       3
3       10      7
4       17      13
5       26      21
6       38      32
7       52      45
8       68      60
9       86      77
10      106     96
11      129     117
12      154     141
13      182     168
14      212     197
15      244     228
16      279     261
17      317     298
18      357     337
19      399     378
20      445     422
21      493     469
22      543     518
23      597     570
24      653     625
25      712     682
26      774     743
27      839     806
28      907     873
29      978     942
30      1052    1015
31      1128    1090
32      1209    1168
33      1292    1250
34      1378    1335
35      1468    1423
36      1561    1514
37      1658    1609
38      1758    1708
39      1861    1809
40      1968    1914
41      2078    2023
42      2192    2135
43      2310    2251
44      2432    2371
45      2557    2494
46      2686    2621
47      2819    2752
48      2956    2887
49      3097    3026
50      3242    3169
51      3391    3316
52      3544    3467
53      3701    3622
54      3863    3782
55      4029    3946
56      4200    4114
57      4375    4287
58      4554    4464
59      4738    4646
60      4927    4832
61      5121    5024
62      5319    5220
63      5522    5420
64      5730    5626
65      5944    5837
66      6162    6053
67      6385    6273
68      6614    6499
69      6848    6731
70      7087    6967
71      7332    7209
72      7583    7457
73      7839    7711
74      8101    7970
75      8368    8234
76      8642    8505
77      8921    8781
78      9207    9064
79      9498    9352
80      9796    9647
81      10100   9948
82      10411   10255
83      10728   10569
84      11051   10889
85      11381   11216
86      11718   11549
87      12062   11890
88      12413   12237
89      12771   12592
90      13136   12953
91      13509   13322
92      13888   13698
93      14276   14082
94      14671   14473
95      15073   14872
96      15484   15278
97      15902   15693
98      16328   16115
99      16763   16545
100     17206   16984
101     17657   17431
102     18116   17886
103     18585   18350
104     19062   18823
105     19548   19305
106     20043   19795
107     20547   20295
108     21060   20803
109     21583   21321
110     22116   21849
111     22658   22387
112     23210   22934
113     23771   23490
114     24343   24057
115     24926   24634
116     25518   25222
117     26121   25819
118     26735   26428
119     27360   27047
120     27995   27677
121     28642   28318
122     29300   28971
123     29970   29635
124     30651   30310
125     31345   30998
126     32050   31697
127     32767   32408

Re: Good requantizers?

Reply #22
I was hoping it looks like that:
16bit PCM --lossy--> 8bit DPCM --lossless--> 8bit PCM

It's obvious that requantizing to lower bit depth is lossy. I thought that conversion from DPCM to PCM at the same bit depth is lossless though.
Hmm, I guess that depends on the 'D', i.e. way the predictor in your particular DPCM format works. ... with proper format constraints in place, such situations could be avoided, and then indeed the decoding might be lossless.
No.    Any change (any irreversible change) is a loss of information/data.     And in the end you have a regular 8-bit PCM file with the usual quantization noise and resolution limits.
Since your 'no' partially contradicts my answer, I sat down this morning and implemented a basic DPCM codec in Octave/Matlab to check. Attached the .m script, where you can change the fourth line to specify a different input/output file name (the encoded file gets a 'wavEnc.wav' extension, the decoded file a 'wavDec.wav' extension). Sorry, since it's C-style scripting, it's really slow, so I also attach demo Wave files.

The decoding part indeed does what rutra80 is looking for: it decodes the B-bit DPCM Wave file to a B-bit PCM Wave file, losslessly. You can verify that by tandem coding the decoded file, by specifying the ...wavDec.wav as input when running the script a second time. That should result in exactly the same encoded and decoded audio as in the first run. I scaled the dither such that, when the input audio is already at the target bit-depth, no noise will be added.

The crucial part is value clipping to B bit at the right places and the absence of companding and other adaptive types of quantization (as done by e.g. bennetng; that would increase the value range and, thereby, the bit-depth). Conceptually, this simple codec is actually very similar to how FLAC, and possibly some other lossless codecs with a "wasted bits" feature, work.

That was fun, reminded me of my first experiments into audio coding roughly 20 years ago :)

Chris
If I don't reply to your reply, it means I agree with you.

Re: Good requantizers?

Reply #23
Very interesting : ) Your sample has quite compressed dynamics so it favors low bit depths, but I tried it with some more challenging samples and it performs quite well.
I personally seem to like sox requantizing with noise shaped dither most, for example I tried gesemann noise shaping and I barely can hear any noise at all, but some people find it hissing and already begin to hear the very quiet dithering at 5kHz.
Your dithering is quiet but quite spread across frequencies, some people find it more pleasant than very loud noise at very high frequencies...

In case of low rate samples when dithering with noise shaping is less useful - are there algorithms which instead of noise introduce some other kind of artifacts? Which requantizer uses simply rounding?

Re: Good requantizers?

Reply #24
OK I made another non-DPCM companding format for fun, let's call it UA-law. It compresses to 8 bits and expands to 16 bits.
[attach type=image]20360[/attach]

To encode, drag one or more uncompressed 16-bit .wav files into UA-law.exe, new files will be saved in the same location as the original files, with "-ComP.waV" added at the end of the file names. The encoded files have same format and size as the original, but only the lowest +/-127 sample values are used, therefore volume level is very low, and can achieve high compression ratio with 7z and FLAC.

The program uses file name to switch between encode/decode modes, if the files end with "-ComP.waV" (case sensitive), decode mode will be engaged. To decode, drag the "-ComP.waV" files into UA-law.exe, the decoded files will end with "-ComPand.wav" and can be directly played.

If for whatever reason you can't or unwilling to run the program, I attached some sample files, using the infamous eig.wv, compared to u-law and a-law.


New version:
-Lower distortion, check the re-encoded eig.wv.
-Much faster en/decoding speed. About 2 seconds for an uncompressed ~700MB CDDA image on a 6 years old Haswell i3 using RAM disk.
-Source and .exe file included.