WavPack: various fixes for multichannel & DSD files

[dbry]

• fix parsing of multichannel files with greater than 8 streams
• fix compression ratio calculation for all multichannel files
• fix DSD file parsing

[dbry]

Hi!

A user reported to me that certain multichannel files were not reporting the correct number of channels in MediaInfo (e.g., 18 instead of 19) and I tracked it down and also fixed a couple other things I found.

I hope this is useful, and thanks for the ongoing WavPack support! Please let me know if there's anything else I can do.

-David

[JeromeMartinez]

A user reported to me that certain multichannel files were not reporting the correct number of channels in MediaInfo (e.g., 18 instead of 19) and I tracked it down and also fixed a couple other things I found.

Thank you for the fixes.

Please let me know if there's anything else I can do.

Please provide sample files for both cases (or at least one if difficult to provide both), and review the changes I forced-pushed.
Force-push from your side if you want a clean PR.

__T("DSD")+Ztring::ToZtring(16<<SamplingRate_Shift))

I am fine with the DSD change (DSD is the content format, DSF a file format), but the mode shall not include the sampling rate which is a parameter and already elsewhere (in the "sampling rate" field).

Get_L4 (channel_mask, "channel_mask");

Now there is code for more than 256 channels but channel mask accepts only 32 cases, how is it working for mapping 33 channels to their positions?

[JeromeMartinez]

Additional question:

fix parsing of multichannel files with greater than 8 streams

0D with Size < 6 was supporting up to 255 channels, why do you speak about 8 and why do you speak about streams (from the new code, "stream" seems to refer to something else)? Or does it means that in the past a "single "stream" was not supporting more than 8 channels so 9 channels requires this update for working well?

[dbry]

A user reported to me that certain multichannel files were not reporting the correct number of channels in MediaInfo (e.g., 18 instead of 19) and I tracked it down and also fixed a couple other things I found.

Thank you for the fixes.

Please let me know if there's anything else I can do.

Please provide sample files for both cases (or at least one if difficult to provide both), and review the changes I forced-pushed. Force-push from your side if you want a clean PR.

384 channels

18 channels

The WavPack test suite has a DSD file (bit_depths/1bit_dsd.wv)

I have reviewed and tested your changes. No issues found. Thanks!

__T("DSD")+Ztring::ToZtring(16<<SamplingRate_Shift))

I am fine with the DSD change (DSD is the content format, DSF a file format), but the mode shall not include the sampling rate which is a parameter and already elsewhere (in the "sampling rate" field).

I know that the sampling rate field provides that information, but nobody knows what those values mean. Everyone knows what DSD64 or DSD128 mean and I would say that those are the format's names in the popular lexicon. But it's your call.

Get_L4 (channel_mask, "channel_mask");

Now there is code for more than 256 channels but channel mask accepts only 32 cases, how is it working for mapping 33 channels to their positions?

Any channels that exist that are not represented by a set bit in the channel mask are simply "undefined" speakers (the defined ones must come first). There is a mechanism to define these channels that I implemented to handle CAF channel definitions, but nobody is using CAF so it's all rather moot (if you're curious you can look up WavpackGetChannelIdentities() in the libwavpack documentation). The applications that use large number of channels (e.g., high-order Ambisonics or electrophysiology data) know what the channels mean.

[dbry]

Additional question:

fix parsing of multichannel files with greater than 8 streams

0D with Size < 6 was supporting up to 255 channels, why do you speak about 8 and why do you speak about streams (from the new code, "stream" seems to refer to something else)? Or does it means that in the past a "single "stream" was not supporting more than 8 channels so 9 channels requires this update for working well?

Multichannel files are split into a sequence of mono and stereo "streams". For example, 5.1 would normally be represented with a stereo stream for FL+FR, a mono stream for FC, a mono stream for LFE, and a stereo stream for BL+BR. Frames containing audio data would cycle through those 4 streams (with the first marked INITIAL_BLOCK and the last flagged FINAL_BLOCK).

Before version 5.0, WavPack files could only have a maximum of 8 such streams, which results in a maximum of 8 channels (assuming no pairing) to 16 channels (assuming all channels paired into stereo blocks).

For version 5.0 I wanted to eliminate that limit and so I created the new version of the ID_CHANNEL_INFO block with 6 or 7 bytes. It specifies both the number of channels and the number of streams (so they can be pre-allocated), and allows up to 4096 channels and streams. To reduce breakage of old decoders (like FFmpeg) I only use this variation if there are more than 8 streams. Old decoders will error on the metadata block being 6+ bytes, but most multichannel files will still work fine.

[JeromeMartinez]

I know that the sampling rate field provides that information, but nobody knows what those values mean. Everyone knows what DSD64 or DSD128 mean and I would say that those are the format's names in the popular lexicon.

I'll think to something generic (about DSD sampling rate, not WavPack) about that.

The applications that use large number of channels (e.g., high-order Ambisonics or electrophysiology data) know what the channels mean.

OK, so for the moment no support of something else than the current 32-bit channel mask.