0
$\begingroup$

I'm looking to compress multiple mono sound tracks together, as one track (with loads of channels), however, I was wondering if this is stupid - because I may lose out on real compression, as these algorithms are design to compress channels with some correlation. Also the each track is not actually audio, (and wont oscillate like audio does).

$\endgroup$
1
  • 1
    $\begingroup$ All bets are off when you apply audio compression to non-audio. It's kinda designed for audio. $\endgroup$
    – user253751
    Jan 29, 2022 at 9:46

4 Answers 4

3
$\begingroup$

Also the each track is not actually audio, (and wont oscillate like audio does).

Then don't use a lossy audio codec like MP3, AAC, etc. These are PERCEPTUAL codecs, i.e. they are heavily leveraging properties of the human auditory system. The signal to noise ratio of these codecs is atrocious, but they still sound good.

Instead use a lossless codec like FLAC (or zip).

If you need more compression than FLAC or ZIP, the best choice will depend heavily on your application: what type of signals do you have and which signal properties are more important than others.

do audio compression algorithms encode channels in parralel?

Lossy audio codecs do joint channel coding. Again, these are based on what channel differences are the least audible, not on data preservation.

$\endgroup$
5
  • $\begingroup$ Yeah, I decided to go for image comrpession. I'm giong to test out FLIF / WEBP $\endgroup$
    – Tobi
    Jan 29, 2022 at 13:21
  • 1
    $\begingroup$ That's probably not much better since JPEG (for example) is optimized about the visibility of compression artifacts, not data preservation. You are trading the perceptual properties of the human ear against that of the human eye. $\endgroup$
    – Hilmar
    Jan 29, 2022 at 13:49
  • $\begingroup$ FYI, its a spectrogram $\endgroup$
    – Tobi
    Jan 29, 2022 at 16:13
  • $\begingroup$ So what will be using the spectrogram for ? Looking at it has different requirements than feeding it to a neural network. $\endgroup$
    – Hilmar
    Jan 29, 2022 at 22:15
  • $\begingroup$ I won't be looking at it. I'll try ZLIB vs FLIF vs WEBP $\endgroup$
    – Tobi
    Jan 29, 2022 at 22:25
2
$\begingroup$

It feels like you're missing some basics. Audio, video and static image compression algorithms are optimized for, well, audio, video and static images. They exploit the nature of natural sounds and pictures to obtain best compression ratios. Sure, you can encode sound as a picture, or a picture as a sound - but you'll be working against the compression algorithm and the results will be poor.

Not to mention the fact that many (but not all) algorithms are "lossy" - that is, they lose information when compressing. They do this in a smart way, taking into account the workings of human hearing and vision, so that we don't perceive the loss of information - but it's still there.

If you took a text file, compressed it via MP3, and then decompressed again, it wouldn't be readable anymore.

But there are also general data compression algorithms which work on any type of data. If you're trying to compress video/audio/image, then they won't be as good as the specialized algorithms (and an order of magnitude worse than the lossy ones), but they are completely lossless and always work.

The .ZIP compression algorithm is the most common one (and built into Windows too), but there are many others. For a good compression ratio, try 7-zip (free) or RAR (cheap; perpetual trial available). And there might be others that I don't know about. Even for these algorithms there are parameters that you can play around to see what gets you the best compression.

Also remember, that at the end of the day, all compression algorithms rely on finding patterns in the data (typically repeating patterns) and encoding those in a more efficient way. Like, instead of writing out 100 identical bytes, they might encode "repeat this byte 100 times".

But a corollary of that is that the more random your data is, the less patterns there will be, and the less efficient the algorithms will become. At some point it becomes more efficient to NOT compress your data.

This is also the reason why compressing something that is already compressed is going to work poorly - most of the usable patterns have already been encoded away.

$\endgroup$
2
  • $\begingroup$ You put this very well, thanks $\endgroup$
    – Tobi
    Jan 29, 2022 at 16:37
  • $\begingroup$ @Tobi - Thanks! I added one more important bit. $\endgroup$
    – Vilx-
    Jan 29, 2022 at 16:49
1
$\begingroup$

I believe that many lossy as well as lossless audio codecs will try to exploit the correlation often found between channels. One way to do this is to do form a «channel» that is the sum of the input channels, and another that is the difference. Another is to encode mainly a summed mono channel and add in some metadata for panning.

If you have multichannel input that have different statistics from typical audio, then all bets are off if an audio codec will be a good idea. The waveform out of an mp3 decoder can visually be quite different from the input waveform. As long as it sounds nearly the same and require fewer bits, the codec fills its purpose.

$\endgroup$
0
$\begingroup$

First suppose that your so-called stereo file is composed by the duplication of a single mono-channel on the left and right ($L$ and $R$).

If you compress losslessly them separately, you end up with a compressed $L_c$ and a compressed $R_c$ files, that are identical. Now, if you average them as average $A=(L+R)/2=R=L$ and difference $D=(L-R)=0$. Thus, you have (almost, see later) the same amount of information: you can recover $L$ and $R$ from $A$ and $D$. Then, the compressed average $A_c$ will be the size of $L_c$, and tat of $D_c$ will be mostly zero: zero-files compress well. Consequently, doing an appropriate preprocessing on channels (here, average and difference) can divide the compressed size by a factor of almost two.

Now, if the channels are similar with a little offset, but still have a predictably visible behavior, then we can expect three novel features:

  • $A$ will still be of the same order of magnitude as $L$ or $R$ (same compression factor expected), and may be a little smoothed, hence possibly easier to predict/compress than each individually
  • $D$ should be of smaller amplitude, with two potential effects: tiniest binary words to be encoded on (eg 12 bits versus initial 16 bit audio), less sample diversity allowing entropy coders to work more efficiently.
  • the residue (error) between $L$ and $R$ on the one hand, and $A_c$ and $D_c$ reconstructed on the other hand, ought to be less perceptible (for lossy compression).

Of course, there are catches (like the tricky average) depending on data nature and dependencies between channels. For instance, $D=(L-R)$ may require one more bit than $L$ or $R$ in worst cases (fro integer coding).

But, if $L$ original channels are independently compressible by factor $\alpha > 1$ and are close enough in some sense, one may hope that a proper decorrelating operation between channels (average/difference, principal component analysis, independent component analysis), one can hope to get $K<L$ novel channels as, or slightly better compressible than the originals, and the remaining $L-K$ transformed channels compressible by a higher factor $\beta > \alpha > 1$.

Thus, independent compression of $L$ channels of unit size yields a final size of $S_i= L/\alpha$. Combined compression may get $S_c=K/\alpha+(L-K)/\beta$. One easily sees that

$$ L/\alpha = K/\alpha+(L-K)/\alpha \ge S_c$$

Yet, compressed files need overhead, including the compression format, the decorrelation transform, to be more efficient.

Many working examples exist in medical signals, seismology, etc. showing that not parallel can be more efficient.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.