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 ?
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.
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) ?
seven channels the stream is 6.1 surround. channel order: front left, center, front right, side left, side right, rear center, LFE
Actually, I think I might have found a bug in oggenc after all. According to vorbis specs:Quoteseven channels the stream is 6.1 surround. channel order: front left, center, front right, side left, side right, rear center, LFEOrder 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, 3But it is (in audio.c):0, 2, 1, 4, 5, 6, 3All 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.
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.