Handling of sequences of zero/silence frames (RLE-like compression)

[vadimkantorov]

When working with WebRTC-produced audio of mult-speaker conference call recordings, every channel has a lot of silence.

I wonder, does flac encoder have a feature of efficiently skipping fully long sequences of zero frames (especially if there are seconds and minutes of of silence)?

If so, flac could be used as an intermediate format for sending decoded audios to a speech recognition model.

Along with verbatim mode, flac could then be used for basic RLE compression:

• [question] Forcing only verbatim and constant modes #656

[ktmf01]

I wonder, does flac encoder have a feature of efficiently skipping fully long sequences of zero frames (especially if there are seconds and minutes of of silence)?

Yes, and no. It does not "skip" anything, because it is a lossless encoder. If it would skip anything, it wouldn't be lossless. However, it can very efficiently encode silence. So much in fact, that the encoder has a function specifically to raise the bitrate to an acceptable minimum in case of encountering just silence, see #90.

Along with verbatim mode, flac could then be used for basic RLE compression:

* [[question] Forcing only `verbatim` and `constant` modes #656](https://github.com/xiph/flac/issues/656)

Well, I'd say, try and find out? I'm not sure what help I can provide here?

[vadimkantorov]

If it would skip anything, it wouldn't be lossless

By skipping I mean encoding only a constant piece of information for very long frames considered silence (in the most basic cases - just strictly zero int16 values). But yeah if it's compact as is for encoding minutes of silence, it's very good news!

Well, I'd say, try and find out? I'm not sure what help I can provide here?

I'll try it out and report here what --analyze output would be like (if all goes as expected, it should only be a sequence of verbatim and constant frames) !

[H2Swine]

The longest block that FLAC-the-format admits, is 65535 samples (per channel), using --lax -b 65535. So at least every 65535, there has to be a frame header and the same number of subframe headers as channels. Say if you have 8 channels, it compresses 48000/16-bit silence down to around 100 kilobytes per hour. Downside of such a long block size is of course that if someone makes a noise, that triggers a full block where you cannot use CONSTANT.

Since you mention that your application is a multi-speaker conference call ... how many is "multi"? If you have > 8 channels, you must either go by way of some container, or choose something else than FLAC. WavPack is arguably the to-go codec for high channel count. It is apparently not as efficient at silence, 100 kilobytes isn't much ... is it?