oggenc and channel mask, question regarding unusual (6.1, etc.) configurations Options

[msoltyspl]

Using latest official tools compiled from sources - so 1.4.0, 1.3.1 and 1.2.0 of tools, vorbis and ogg respectively.

Generally - if I have for example flac file with 0x70F (6.1) or 0x63F (7.1) channel mask included - the oggenc will create proper ogg file with necessary WAVEFORMATEXTENSIBLE_CHANNEL_MASK "comment". But, if I try to encode the same data from wav files (with necessary channel info present), the mask will not be included in the resulting ogg file.

Is this expected behavior ? Or is there some specific switch I should use to make oggenc add proper channel mask to the ogg file ?

[john33]

Using latest official tools compiled from sources - so 1.4.0, 1.3.1 and 1.2.0 of tools, vorbis and ogg respectively.

Generally - if I have for example flac file with 0x70F (6.1) or 0x63F (7.1) channel mask included - the oggenc will create proper ogg file with necessary WAVEFORMATEXTENSIBLE_CHANNEL_MASK "comment". But, if I try to encode the same data from wav files (with necessary channel info present), the mask will not be included in the resulting ogg file.

Is this expected behavior ? Or is there some specific switch I should use to make oggenc add proper channel mask to the ogg file ?

I could be wrong because I haven't checked this out, but I suspect that the channel mask comment is being copied from the flac file comment rather than being created by oggenc.

[msoltyspl]

Most likely, yes.

Well, I'm testing a bit those configurations to see when they actually work properly. The results are not too encouraging on the decoding side at least. I made trivial 6.1 wav file for testing with 0x70F setup (maybe I messed up something ?):

http://soltys.ziu.info/temp/61v2.7z (wav file - 48khz, 24bit)
http://soltys.ziu.info/temp/61v2.flac (flac encoded from that wav file)

Any ogg file I do from those (so without mask from wav, or with mask from flac) is not played properly - tested with: winamp (bad channel order in each case - wav, flac, ogg), foobar (doesn't recognize the file), official oggcodecs (assumes only 2 channels) ffmpeg-tryouts' libavcodec (bad channel order) and tremor (crash).

In comparison, flac (including mkv) and wav (excluding mkv) play fine through libavcodec and foobar.

Peeking into oggenc/audio.c - it seems that the oggenc should be able to handle it just fine through wav_open() function which has tests for different channels setup, 0x70f in particular. So my guess is that the blame is on decoders/players side.

This post has been edited by msoltyspl: Nov 1 2010, 17:42

[john33]

Most likely, yes.

Well, I'm testing a bit those configurations to see when they actually work properly. The results are not too encouraging on the decoding side at least. I made trivial 6.1 wav file for testing with 0x70F setup (maybe I messed up something ?):

http://soltys.ziu.info/temp/61v2.7z (wav file - 48khz, 24bit)
http://soltys.ziu.info/temp/61v2.flac (flac encoded from that wav file)

Any ogg file I do from those (so without mask from wav, or with mask from flac) is not played properly - tested with: winamp (bad channel order in each case - wav, flac, ogg), foobar (doesn't recognize the file), official oggcodecs (assumes only 2 channels) ffmpeg-tryouts' libavcodec (bad channel order) and tremor (crash).

In comparison, flac (including mkv) and wav (excluding mkv) play fine through libavcodec and foobar.

Peeking into oggenc/audio.c - it seems that the oggenc should be able to handle it just fine through wav_open() function which has tests for different channels setup, 0x70f in particular. So my guess is that the blame is on decoders/players side.

As you've seen, audio.c will map up to 7.1 with or without the WAVEFORMATEXTENSIBLE header as though the header was present. The resulting multichannel ogg file should subsequently be decoded to the default order with the correct header, but that does depend on the decoder used, certainly my decoder on Rarewares does. Anything over 7.1 is encoded in the channel order presented.

[msoltyspl]

As you've seen, audio.c will map up to 7.1 with or without the WAVEFORMATEXTENSIBLE header as though the header was present. The resulting multichannel ogg file should subsequently be decoded to the default order with the correct header, but that does depend on the decoder used, certainly my decoder on Rarewares does. Anything over 7.1 is encoded in the channel order presented.

Yea, and indeed your oggdec works fine (contrary to 1.4.0's oggdec - which decodes that 6.1 weirdo into silence).

Any suggestions about directshow filter that could potentially output channels in correct order (apart from workarounds such as channel swapping / manual mixer settings) ?

[john33]

Yea, and indeed your oggdec works fine (contrary to 1.4.0's oggdec - which decodes that 6.1 weirdo into silence).

Any suggestions about directshow filter that could potentially output channels in correct order (apart from workarounds such as channel swapping / manual mixer settings) ?

I'm afraid I've no idea whether the 'opencodecs' DSFilters work correctly in this regard, or not, as I've not tried them.

[msoltyspl]

Actually, I think I might have found a bug in oggenc after all. According to vorbis specs:

seven channels
the stream is 6.1 surround. channel order: front left, center, front right, side left, side right, rear center, LFE

Order as defined by 0x70F is FL, FR, FC, LFE, BC, SL, SR, so the permutation row for 6.1 entry should be:

0, 2, 1, 5, 6, 4, 3

But it is (in audio.c):

0, 2, 1, 4, 5, 6, 3

All the channel-permutation rows for other channel setups are fine. Only 6.1 one is wrong.


If I change the order to the former, then for example - libavcodec has no problems with playing the file with correct channel order. What do you think ?

ps.
I submitted tickets for both oggenc and oggdsf, for what it's worth.

This post has been edited by msoltyspl: Nov 3 2010, 01:34

[john33]

Actually, I think I might have found a bug in oggenc after all. According to vorbis specs:

seven channels
the stream is 6.1 surround. channel order: front left, center, front right, side left, side right, rear center, LFE

Order as defined by 0x70F is FL, FR, FC, LFE, BC, SL, SR, so the permutation row for 6.1 entry should be:

0, 2, 1, 5, 6, 4, 3

But it is (in audio.c):

0, 2, 1, 4, 5, 6, 3

All the channel-permutation rows for other channel setups are fine. Only 6.1 one is wrong.


If I change the order to the former, then for example - libavcodec has no problems with playing the file with correct channel order. What do you think ?

ps.
I submitted tickets for both oggenc and oggdsf, for what it's worth.

I'll check it out. The channel permutation has been wrong before.

[john33]

It would certainly appear that you are correct, but let's see whether there is a response before I make the changes to my compiles.

[xiphmont]

It would certainly appear that you are correct, but let's see whether there is a response before I make the changes to my compiles.

gmaxwell woke me up to the Trac report; msoltyspl looks to be correct, committed his patch.

[john33]

gmaxwell woke me up to the Trac report; msoltyspl looks to be correct, committed his patch.

Thanks Monty, I'll update the compiles on Rarewares post-haste, well, in the next 24 hours.