For those who did not follow the previous discussions, I am talking about optimizations for >=4x upsampled data, so the parameters listed above are not suitable for encoding "real" hi-res files.
General
Complete name : C:\~~~~~~~\test-other.tar\test-other\LibriSpeech\test-other\2414\128292\2414-128292-0009.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 235 KiB
Duration : 13 s 125 ms
Overall bit rate mode : Variable
Overall bit rate : 146 kb/s
Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 13 s 125 ms
Bit rate mode : Variable
Bit rate : 141 kb/s
Channel(s) : 1 channel
Channel layout : C
Sampling rate : 16.0 kHz
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 227 KiB (97%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
MD5 of the unencoded content : C6C1AF5F80BB643A4172F406186017E7
General
Complete name : C:\~~~~\librispeech-8bit.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 74.4 KiB
Duration : 13 s 125 ms
Overall bit rate mode : Variable
Overall bit rate : 46.4 kb/s
Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 13 s 125 ms
Bit rate mode : Variable
Bit rate : 41.4 kb/s
Channel(s) : 1 channel
Channel layout : C
Sampling rate : 16.0 kHz
Bit depth : 8 bits
Compression mode : Lossless
Stream size : 66.3 KiB (89%)
Writing library : libFLAC 1.4.3 (UTC 2023-06-23)
MD5 of the unencoded content : 17D503AC844BB657FC6BE24F755B9BE7
I'm not familiar with that Sox command-line, so let me ask: did you just recreate the WAV header such that one 16-bit sample is interpreted as two 8-bit samples, i.e., the high-byte as one sample and the low-byte as another sample?It is a normal bit-depth reduction command. It is not a command to split one file into two. As expected from being 8bit, it has lower S/N. It is wholly dithered.
How can this be better compressible by FLAC than a meaningful unscrambled 16-bit waveform? Have you listened to the resulting files or looked at them in an audio editor? Do they contain long passages of digital silence?
So I tried it. The total duration of the two attached playlists is 41h 39m 06s. The playlists contain single tracks and images, so not every single track name is shown.Same corpus with same settings transcoded from pre-upsampled flac files (16/44 -> 24/192 with -2dB preamp), using foobar multi-file multi-thread, flac 1.4.3. Decoding times are single-threaded using foobar x64 benchmark, all tested on NVMe SSD, i3-12100.
-8
38.1 GB (41002782313 bytes)
-8b8192 -A "subdivide_tukey(3);blackman"
37.7 GB (40507157807 bytes)
5 files out of 306 still clipped with -2dB gain. Yes, if one keeps throwing Merzbow to the chain that requires like -10dB it would harm the stats, so don't do that. Clipping should be controlled to as low as possible, or not at all (e.g. by using RG max non-clip gain).
For simplicity and speed, I did all the conversions within foobar and foo_dsp_resampler.
[attach type=image]27188[/attach]
[attach type=image]27190[/attach]
gaussworkGauss, like other windows, works best when coupled with an optimal blocksize. Also, the gauss parameter needed to be calculated for best performance. For example, the target 192kHz sample rate has a Nyquist of 96kHz, if the resampler is lowpassed at about 23kHz like the red plot below, then the value should be 23/96, so it would be gauss(24e-2), the green and yellow plots would be 23e-2 and 25e-2.
Here come the times when for encoding you shouldn't consider only the size of encoded files, but executable and dictionary/model size too. Computing power and memory bandwidth requirements rose significantly too.Exactly! That's common practice in both MPEG and 3GPP codec standardizations, btw, especially when the codec in question is supposed to run on a mobile device (so basically every codec nowadays).