Oggenc appears not to remap 5.1 channel order from WAV order (L/R/C/LFE/BL/BR) to Vorbis order defined by xiph's specifications :
Tested with rarewares build 2005-07-10.

Note that this problem is not limited to oggenc.exe - it's also present in OggDropXPd etc.

Interesting!! Obviously requires looking at.

How can you tell it doesn't? If you play it back, your player is supposed to send the right channel to the right output no matter how they're ordered in the stream, so it wouldn't differ from any other format... If you decode it to WAV, oggdec might be remapping the channels to a more common order: Lf, Rf, C, LFE, Ls, Rs...

And how is my player supposed to guess which channel of libvorbis output is supposed to go to which output? Magic?

While at it, add oggdec to offender list (channel order is ignored entirely again, so it decodes incorrect oggenc output back to correct WAVs).

Just like you do: if it's in the specs, there's a chance a given decoder implements it correctly.

Which surely would lead it to sending the wrong channel to the wrong output? If the decoder follows the specs but the eoncoder doesn't it may very well send Channel 2 to Front Center instead of Front Right.

That's why I asked how he could tell the order was wrong. If the playback is correct (each channel goes to the right output), how can he tell the order is wrong in the encoded Ogg Vorbis file? And even if the playback is incorrect, how can he tell whether it is the player's decoder that's wrong (i.e. it doesn't respect the specs) or if the file itself is wrong ?

Obviously it isn't correct when following the specs, otherwise he wouldn't have asked, would he?

I wonder whether channel mapping infos are saved in WAVs (at least not in the standard format AFAIK; you'd need the extensible one)? Or is the ch order Peter wrote standard for WAV? If you decode an AC3 to WAV you'll get the ch order Vrobis wants - unless you remapped it.

So is it really a problem of oggenc (does it oparse the extensible format)? Or rather a problem with no infos in the offending WAV file?

Channel order is fixed for WAVE_FORMAT_EXTENSIBLE, you cannot reorder them, only mask out channels you're not using. See comments to this MSDN document.

http://bugs.xiph.org/

I'm sure patches would be very welcome.

You don't need to register anymore. Just enter an email address.

How else you think I could have noticed the problem if not from order of channels being mangled when the player follows the specs, and working "correctly" when assuming WAV channel order in libvorbis output instead?
This is even more of a problem because people writing vorbis support in other players will often skip reading documentation and duplicate behaviors of reference software (oggdec), and then even conclude that their code is working correctly after playing incorrect multichannel file created with one of offending encoders.
No, thank you. If they need third party contributors to fix trivial bugs in reference encoder/decoder, their project is short-lived anyway.

You could have fixed this in the days of in_vorbis 1.2.x, couldn't you?

Well, anyway, why not just report it?

http://trac.xiph.org/cgi-bin/trac.cgi/ticket/736

It is sad if the offical tools get it wrong. It was also questionable to >>have<< based the channel order on something different from WAVE, it is the defacto standard and cross-platform.

To clarify this problem is not knowing what channels are in the file, 5.1 is L R C BL BR LFE, it is rather the order of these items, which is unique for ogg.

To confuse matters more, a 4 channel ogg file, what are the speaker mappings? (I bet that is not in the documentation) the problem is there for anything > 2 channels, wave sort of had these defined (4 channel in wave would be L R BL BR) and the wfx_extensible helps further. I suppose as long as theyget 5.1 and 7.1 right that covers most bases.

Edit: added >>have<< as to not suggest they change their 'standard'

http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#id2540617
Actually the standard defines mapping for up to 6 channels, including less common configurations such as 3,4 and 5 (scroll down to 4.3.9).
Another problem is that most of software out there just refuses to read waveformatextensible WAVs, e.g. I ended hacking my frontend to use WAVEFORMATEX header when channel flags match default ones, because otherwise hardly anything would work with it.

Nope, it is ac3 ch mapping and I think therefor vorbis took it over.

IIRC, the in_vorbis plugin actually has a "broken channel ordering" switch, which is probably there for exactly the same reasons.

"The nice thing about standards is that there are so many to pick from!"

I have just uploaded oggdropXPdV1.8.7alpha here: http://homepage.ntlworld.com/jfe1205/oggdr...pha-generic.zip

The only real changes here are that I have modified the i/o routines to handle multi-channel input with channels re-mapped to the vorbis specs and also to re-map on decode. In both cases, WAVEFORMATEXTENSIBLE headers are read/written as appropriate.

I've tested this with 5.1 and it appears to function correctly. I'd much appreciate some testing with other channel configurations that fall within the vorbis spec. Channel configurations that are outside the vorbis spec are simply processed in the order presented.

Valid configurations within the vorbis spec are:

Mono = Front Left.
In WAVEFORMATEXTENSIBLE = SPEAKER_FRONT_LEFT
Stereo = Front Left, Front Right.
In WAVEFORMATEXTENSIBLE = SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT
3 Channel = Front Left, Front Centre, Front Right.
In WAVEFORMATEXTENSIBLE = SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | SPEAKER_FRONT_CENTER
4 Channel = Front Left, Front Right, Rear Left, Rear Right
In WAVEFORMATEXTENSIBLE = SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT
5 Channel = Front Left, Front Centre, Front Right, Rear Left, Rear Right
In WAVEFORMATEXTENSIBLE = SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | SPEAKER_FRONT_CENTER
| SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT

I would appreciate feedback even if only to tell me that the re-mapping is OK.

it works just fine with 4.0 (quadro) and winamp & wmp 10 plays it with no problems BUT it doesn't work with 4.1 (quadro+Lfe) . Is it possible to make support for 4.1 (that would be very nice...)?

Thanks for the feedback. The problem is that it is only sensible to follow the re-mapping as currently specified within the vorbis spec. To do anyhting unofficially would only lead to potential problems at a later date.

could you add something like option how to treat 5 channels? Then you could choose to decode to 4.1 or 5.0. (or something else).

It would be possible, such as adding a CHANNEL_MASK vorbis tag, but unless the player/decoder is aware of this option it will achieve nothing.

Another possibility would be to add a digital silence channel, and encode the user's 4.1 input as a vorbis 5.1 stream. Vorbis compresses digital silence very well (~1kbps, IIRC).

This could be done by the user before passing the source to oggenc/oggdrop, or it could be done by oggenc/oggdrop (perhaps with a warning that the encoded file will have another stream in it).

This would be easy enough to do and it could be added as an option. Would it cause any issues on playback? Would the speaker config need to specifed as 5.1?

I've just uploaded oggdropXPdV1.8.7beta 1 here: http://homepage.ntlworld.com/jfe1205/oggdr...eta-generic.zip. With this version, multi-channel decode works both for writing to file and for playback. It also adds the option to downmix the multi-channel output to stereo, also for decode to file and playback.

Once I'm satisfied that there do not appear to be any problems with this, I'll release this, a similarly modified oggdec and also a similarly modified oggenc2.