One note which I had commented about before my blog began, was that if authors decide to capture sound at 96k samples /second, the resulting sound should compress well using
But now that I have experimented with ‘
QTractor‘ and an external sound card, I have realized that we will probably also be capturing that sound in 24-bit sample-format, instead of 16-bit. And the sad fact is, that
FLAC will not compress the 24-bit format as well, as it did 16-bit.
The reason seems clear. Using ‘Linear Predictive Coding’ means that
FLAC will be able to predict the next sample in a set of so-many, to maybe 8 bits of precision, except that the next sample will always deviate from this prediction by a small residual. So 8-bit sound should compress brilliantly.
But then with 16-bit, the accuracy of the encoding stays the same. So again, the ‘LPC’ is really only 8-bits accurate at best, meaning that we get a larger residual. The size of that residual is what makes up most of a
Well at 24-bit, again, the LPC will only predict the next sample, accurately to within 8 bits. And so the residual is likely to be twice as large, as it was with 16-bit, completing 24-bit accuracy this time. We are not left with much compression then.
When I recorded my 14-second sound session the other day, I selected
FLAC as my capture file format. I had a noisy air-conditioner running in the background. Additionally, the compression level defaults to Fastest, because the file needs to be written in real-time, and not chewed on.
At 96 kHz, 24-bit stereo, raw audio will take up about 4.6 mbps. At 44.1 kHz, 16-bit stereo, raw audio takes up about 1.4 mbps.
Well I was capturing to a stereo
FLAC File, but was only using one channel out of the two. So the
FLAC File that resulted, had a bit-rate of 2.3 mbps. This means that
FLAC recognized the silent track and used ‘Run-Length Encoding’ on it,
but that was about all this CODEC could do for me.
Now, we do have a command-line tool which will-re-compress that file:
$ flac -8 infile.flac -o outfile.flac $ flac -8 infile.flac --channels=1 -o outfile.flac $ flac -8 infile.flac --channels=1 --blocksize=8192 -o outfile.flac
The -8 means to use maximum compression.
For me, the bit-rate went down to 2.2 mbps either way.
It beats using a raw format, because using the latter would have meant, nothing would have detected my silent stereo channel, and the file would have been twice as large.
Afterthought: Actually, while my mike was plugged in to the left side of my sound card, the other channel was recording small electronic background-noise generated by the input amplifier, and mapped to the right side according to my software. The 24-bit sound format will be accurate enough to record that input noise for certain blocks. This will be white noise with about 1-2 bits of amplitude.
QTractor has the idiosyncrasy, that as it displays the waveform being recorded, it normalizes each stereo channel waveform separately. So even if the sound level on my left channel was 100db higher than that on my right, I saw sporadic wave-shapes in the GUI for both channels. And then, when I imported this
FLAC File into ‘
Audacity‘, the latter program was displaying the wave-shape of each channel, not normalized, so that the right channel showed a flat line again.
Hence, the right stereo channel sometimes contained a non-zero residual. Hence,
FLAC was compressing slightly. It was not just using RLE on the right stereo channel after all.
And, in cases where there is very little compression succeeding, I thought that maybe increasing the block-size will decrease the amount of header information which offsets that. I found that this latter setting made the difference between 2221000 and 2218000 bps.