Skip to main content


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: Lossless codec comparison - part 1: multichannel (Mar '22) (Read 7692 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Lossless codec comparison - part 1: multichannel (Mar '22)

Reply #25
And the only thing that WavPack does to take advantage of interchannel correlation in 5.1 files is to group the appropriate channels into 2 mono and 2 stereo "streams" which are then compressed independently using the existing methods.

My usual curiosity: a file with 7.1 channel allocation FL FR FC LFE BL BR SL SR will then be grouped
FL + FR as stereo (because they are called "FL" and "FR", not because they are the first two?)
FC as mono (because it is called "FC" which is a center, not because it is the third?)
LFE as mono (likewise)
BL + BR as stereo for same reason as FL + FR
SL + SR as stereo (likewise)

Then with -x (and with -x2 to -x6), WavPack will for each of the three "paired" pairs try L+R vs M+S and choose the best?
And the "--pair-unassigned-chans" does only literally that - it pairs only unassigned, not "assigned as something considered unrelated", so because FC & LFE are "assigned", --pair-unassigned-chans -x  will not group them together, they will be each one mono?

(It would of course not be too surprising if FC was found to correlate with the mid "FL + FR" ... in some signals.)

Re: Lossless codec comparison - part 1: multichannel (Mar '22)

Reply #26
Your description of how a 7.1 file would be encoded is correct. There's actually a table in the source (here) that indicates which channels can be paired this way. Unfortunately some "pairs" are not consecutive (like TFL and TFR, which have TRC between them) and those pairs will not be paired unless the middle one is missing because any Microsoft channels present in WavPack files must be in Microsoft channel order (other channels can be in any order, and must come after the MS channels).

The --pair-unassigned-chans was originally intended to allow more channels when WavPack files were limited to 8 streams (i.e., it allowed up to 16 channels). It's really not much use now that we have essentially unlimited streams, but might provide better compression in cases where there would be many somewhat correlated channels (e.g., high-order Ambisonics). And yes, it only applies to truly unassigned channels; you can't use it to combine FC and LFE.