Skip to main content

Notice

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: 5.1 Channel Mappings (Read 25430 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

5.1 Channel Mappings

After searching this board, I have gleaned that all the channel mapping inconsistencies from transcoding AC3 to Vorbis (and WAV to Vorbis) have been worked out. Correct? Also, Winamp (with what plugins?) and Foobar play the 5.1 files fine. Correct?

Please correct my information about the following channel mappings as I understand them:
Vorbis: FL FC FR RL RR LFE (This was the one agreed upon?)
Old Winamp and WAV: FL FR FC LFE RL RR (Is this WAVEFORMATEX, WAVE_FORMAT_EXTENSIBLE, or some other version?)
"Facts do not cease to exist just because they are ignored."
—Aldous Huxley

5.1 Channel Mappings

Reply #1
I have spent a number of hours experimenting and researching, and I believe I have finally made sense of the current state of affairs for multichannel Vorbis.

EDIT: I have updated this post thanks to the efforts of john33 in helping me understand the issues surrounding oggdropXPd.

oggdropXPd 1.8.9 and oggenc 2.82 encode 5.1-channel WAV to Vorbis properly, remapping the channels from WAV order to Vorbis order.  However, they only do this if the input WAV file has a WAVEFORMATEXTENSIBLE header.  If that header is missing, they will encode the input file straight without reordering the channels.  This is fine if the input WAV already has its channels in Vorbis order, but it will produce an unintended result if the WAV file has its channels in WAVEFORMATEXTENSIBLE order.

The CoreVorbis DirectShow filter (as of version 1.1) performs the necessary channel remapping from Vorbis order to WAVEFORMATEXTENSIBLE order, so it will play correctly-encoded multichannel Vorbis streams to the correct speakers.

The Vorbis decoder in ffdshow (as of the 29-Nov-2005 build) also performs the necessary channel remapping, so it will play correctly-encoded multichannel Vorbis streams correctly.

The Illiminable DirectShow Vorbis decoder filter (as of version 0.71.0946) does NOT remap from Vorbis channel order to WAVEFORMATEXTENSIBLE order, so it will play correctly-encoded multichannel Vorbis streams incorrectly.  Unfortunately, the Illiminable package has the only Ogg splitter that currently supports Theora outputs, so Ogg Theora files require it to be installed for playback.

The Nullsoft Vorbis Decoder plugin (as of version 1.44) for Winamp properly performs the necessary channel remapping if it is set to "remap 6 channels" with "correct" source order on its multichannel options page.  When configured this way, it will play correctly-encoded multichannel Vorbis streams correctly!

5.1 Channel Mappings

Reply #2
oggdropXPd 1.8.9 and oggenc 2.82 encode 5.1-channel WAV to Vorbis properly, remapping the channels from WAV order to Vorbis order.  However, oggdropXPd decodes the resulting Vorbis incorrectly.  You can verify this by encoding a 5.1 WAV to Vorbis with oggdropXPd and then decoding the Vorbis back to WAV with oggdropXPd: the original WAV and the final WAV will have different channel orders.  I have not tested oggdec.

I do not believe that you are correct here.
)

The channel order, on decoding, is the mirror of what it was was on encoding. However, for multichannel ogg files that were encoded prior to the mapping being resolved, they will not decode to the same channel order as the original as the original channel mapping will have been ignored.

5.1 Channel Mappings

Reply #3
5.1 WAV  FL , FR , FC , LFE, SL , SR 
5.1 AC3  FL , FC , FR , SL , SR , LFE
5.1 DTS  FC , FL , FR , SL , SR , LFE
5.1 AAC  FC , FL , FR , SL , SR , LFE
5.1 AIFF  FL , SL , FC , FR , SR , LFE

5.1 Channel Mappings

Reply #4
This image shows, on the left hand side,  the 6 channels from the original wave file, and on the right hand side, the 6 channels from the decoded ogg file that was created from the wave file on the left.

What tools did you use to encode and decode?  I have a multichannel WAV that I dropped on "oggdropXPd V1.8.9 - libvorbis aoTuVb4.51" and then dropped the resulting Ogg on again.

Using those settings, the original WAV plays with a different channel mapping than the one that oggdropXPd writes out.  I just performed the experiment again to be sure.  There is something fishy going on here.

The intermediate Ogg file in my experiment plays correctly with decoders that respect the proper Vorbis channel mapping like Winamp's.  (Also just now reverified.)

5.1 Channel Mappings

Reply #5
I'll check thru it again and get back to you.

5.1 Channel Mappings

Reply #6
OK, encoded and decoded with oggdropXPdV1.8.9. The top 6 waves are the original wave file and the bottom 6 are the decode of the ogg file created from the top 6.

5.1 Channel Mappings

Reply #7
OK, encoded and decoded with oggdropXPdV1.8.9. The top 6 waves are the original wave file and the bottom 6 are the decode of the ogg file created from the top 6.

Heh, but did you actually listen to it?  In something other than Adobe Audition?  Play the original WAV file and the decoded WAV file in Windows Media Player or even GraphEdit to be sure you don't have any crazy filters in your graph.





These two graphs play DIFFERENTLY.  The BMG.orig.wav graph plays with the correct channel mapping, while BMG.wav (the one that oggdropXPd wrote from the Ogg that oggdropXPd produced from BMG.orig.wav) plays with messed up channels.  I'm not imagining this: Dave Matthews is definitely singing from the center channel in BMG.orig.wav and from the right channel in BMG.wav.

Would you like me to send you BMG.orig.wav?  I can put it up on YouSendIt.  It's 119 MB.

5.1 Channel Mappings

Reply #8
The test file I use is the 5.1 channel test file that is available from Microsoft near the bottom of this page: http://www.microsoft.com/windows/windowsme...ltichannel.aspx

This file makes it very simple to ascertain whether the channel mappins are correct. Using this file oggdropXPdV1.8.9 and oggenc 2.82 map the channels correctly on encoding. Playback through foobar0.8.3 generates the correct channel outputs. Similarly, decoding via oggdropXPdV1.8.9 and my oggdecV1.9.2 remaps the channels correctly and generates the correct WAVEFORMATEXTENSIBLE header.

I have also just tested a 6 channel file that was originally a DTS file extracted from a DVD. This DTS file was decoded to wave file using foobar0.8.3 and having just checked this using a hex editor, this decoded wave file does NOT contain a WAVEFORMATEXTENSIBLE header. Therefore, the encoded ogg file and the subsequently decoded wave file output do not play correctly as the channel mapping on decode of mutlichannel files assumes conformance with the Vorbis I spec, which of course it doesn't.

Are you absolutely certain that your 5.1 channel wave files contain the correct headers? I have checked this extensively both by viewing the code and comparing to the various specs, and by listening. I do not believe that there is a fault in the code as using correctly conforming input generates the correctly conforming output in all the tests I have performed.

Perhaps you would like to try the small file referred to at the start of this post and tell me whether you get the correct results? I'm very happy to explore this further, but right now I have no evidence to support the idea that there is a problem.

5.1 Channel Mappings

Reply #9
Are you absolutely certain that your 5.1 channel wave files contain the correct headers?

No, I'm not absolutely certain.  In fact, given the Microsoft test file, I would be fairly certain that my DTS-originated WAV file does not contain the WAVEFORMATEXTENSIBLE header.

What then is the assumption made by oggdropXPd?  If a 6-channel WAV file with no WAVEFORMATEXTENSIBLE header is fed in, it won't do the channel remapping?  Does it assume the channels are already in Vorbis order?  And they are only remapped if there is a WAVEFORMATEXTENSIBLE header?

It would be great if there were an option in oggdropXPd for what to do with multichannel non-WAVEFORMATEXTENSIBLE WAV files.

Also, Winamp properly decoded the intermediate Ogg of the Microsoft test file when I set its Vorbis decoder plugin to "remap 6 channels" with "correct (FL FC FR BL BR LFE)" source order.

So everything seems fine with oggdropXPd except what it does in the case where a multichannel WAV has no WAVEFORMATEXTENSIBLE header.  Granted, I would agree that it shouldn't assume any particular channel order in this case, but I would like to see an option that would make it possible to interpret such files as having the standard WAV channel order.

Thanks for all your time helping me see what's going on with this!

5.1 Channel Mappings

Reply #10
No, I'm not absolutely certain.  In fact, given the Microsoft test file, I would be fairly certain that my DTS-originated WAV file does not contain the WAVEFORMATEXTENSIBLE header.

What then is the assumption made by oggdropXPd?  If a 6-channel WAV file with no WAVEFORMATEXTENSIBLE header is fed in, it won't do the channel remapping?  Does it assume the channels are already in Vorbis order?  And they are only remapped if there is a WAVEFORMATEXTENSIBLE header?

Basically, if a WAVEFORMATEXTENSIBLE header is not found, then, as no channel mask has been specified, the channels are encoded in the order presented. Suppose you have a 5.1 channel file, without the correct header but in vorbis channel order, then all will be well. The encoded file will play back correctly and will be decoded to a 5.1 channel wave file with the correct headers, channel mask, etc., but the decoded file will differ from the original because the channels will now be in WAVEFORMATEXTENSIBLE order. Conversely, if the 5.1 channel original file was without the WAVEFORMATEXTENSIBLE header but in WAVEFORMATEXTENSIBLE channel order, all will be screwed!! 
It would be great if there were an option in oggdropXPd for what to do with multichannel non-WAVEFORMATEXTENSIBLE WAV files.

I guess it wouldn't be too tough to add an option to select from a range of predefined mappings in the event that the correct header was absent. If someone would like to provide a sensible list, I could add that in the next release. Is the list provided by Dzamburu, above, correct and complete?
Also, Winamp properly decoded the intermediate Ogg of the Microsoft test file when I set its Vorbis decoder plugin to "remap 6 channels" with "correct (FL FC FR BL BR LFE)" source order.

So everything seems fine with oggdropXPd except what it does in the case where a multichannel WAV has no WAVEFORMATEXTENSIBLE header.  Granted, I would agree that it shouldn't assume any particular channel order in this case, but I would like to see an option that would make it possible to interpret such files as having the standard WAV channel order.

Thanks for all your time helping me see what's going on with this!

I agree that it would be helpful to deal with these possibilites in the event that the files are incorrectly produced. It's unfortunate that there are applications out there that are not formatting the output correctly in the first place.

5.1 Channel Mappings

Reply #11
Thanks for clearing that all up, John.  I have edited my original overview post with this information.  :-)

Looking forward to some remapping options in oggdropXPd and oggenc.

Maybe oggenc could even allow the user to specify the channel order of the input WAV file explicitly.  An option like "--channelorder=FL,FR,FC,LFE,BL,BR".  Then oggenc would know exactly which channel was which and could shuffle them around into Vorbis order.  Of course, if the WAV file actually had a WAVEFORMATEXTENSIBLE header but the user-specified channel order differed from the WFE order, a warning should be printed.

5.1 Channel Mappings

Reply #12
To completely reverse my previous claims...

[a href="http://imageshack.us" target="_blank"]

5.1 Channel Mappings

Reply #13
Below is my patch against the latest CVS version of vorbis-tools. It produces oggenc.exe and oggdec.exe that produce correct results for WAV that are not WAVEFORMATEXTENSIBLE, at least when playing in foobar2000 0.9.4.2. I tried the file 6CH.wav ("Left front.... center... right front.... right surround... left surround... LFE"):

6CH.wav -> oggenc.exe -> ENCODED.ogg -> oggdec.exe -> DECODED.wav -> oggenc.exe -> ENCODED2.ogg -> oggdec.exe -> DECODED2.wav

and played all sound files above in foobar2000. The channels sound identical.

I also tried to encode directly from within Foobar2000 and played the resulting file. The channels are placed in a way identical to the other files above.

vorbis-tools-channel-order.patch

Code: [Select]
diff -urNp vorbis-tools-svn.orig/oggdec/oggdec.c vorbis-tools-svn/oggdec/oggdec.c
--- vorbis-tools-svn.orig/oggdec/oggdec.c    Sat Jun 30 00:42:17 2007
+++ vorbis-tools-svn/oggdec/oggdec.c    Sat Jun 30 01:10:47 2007
@@ -230,8 +230,8 @@ static FILE *open_output(char *outfile)
static void
permute_channels(char *in, char *out, int len, int channels, int bytespersample)
{
-    int permute[6][6] = {{0}, {0,1}, {0,2,1}, {0,1,2,3}, {0,1,2,3,4},
-        {0,2,1,5,3,4}};
+    int permute[6][6] = {{0}, {0,1}, {0,2,1}, {0,1,2,3}, {0,2,1,3,4},
+        {0,2,1,4,5,3}};
     int i,j,k;
     int samples = len/channels/bytespersample;

diff -urNp vorbis-tools-svn.orig/oggenc/audio.c vorbis-tools-svn/oggenc/audio.c
--- vorbis-tools-svn.orig/oggenc/audio.c    Sat Jun 30 00:42:18 2007
+++ vorbis-tools-svn/oggenc/audio.c    Sat Jun 30 00:51:17 2007
@@ -371,14 +371,21 @@ int wav_id(unsigned char *buf, int len)
     return 1;
}

+/*
+using the master channel layout at
+http://www.microsoft.com/whdc/device/audio/multichaud.mspx
+and Vorbis specification (4.3.9)
+http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#id2540617
+*/
+
static int wav_permute_matrix[6][6] =
{
     {0},
     {0,1},
     {0,2,1},
     {0,1,2,3},
-    {0,1,2,3,4}, /* No equivalent in wav? */
-    {0,2,1,5,3,4}
+    {0,2,1,3,4},
+    {0,2,1,4,5,3}
};

int wav_open(FILE *in, oe_enc_opt *opt, unsigned char *oldbuf, int buflen)


I also had problems compiling libogg and libvorbis in MinGW, so, here are my patches for them too:

ogg_size_t.patch

Code: [Select]
diff -urNp ogg.orig/include/ogg/os_types.h ogg/include/ogg/os_types.h
--- ogg.orig/include/ogg/os_types.h    Thu Jun 28 22:19:25 2007
+++ ogg/include/ogg/os_types.h    Thu Jun 28 22:20:09 2007
@@ -16,6 +16,9 @@
  ********************************************************************/
#ifndef _OS_TYPES_H
#define _OS_TYPES_H
+
+/* for size_t */
+#include <stddef.h>

/* make it easy on the folks that want to compile the libs with a
    different malloc than stdlib */


vorbis-intl.patch

Code: [Select]
diff -urNp vorbis-tools.orig/oggdec/Makefile.am vorbis-tools/oggdec/Makefile.am
--- vorbis-tools.orig/oggdec/Makefile.am    Fri Jun 29 00:12:20 2007
+++ vorbis-tools/oggdec/Makefile.am    Fri Jun 29 00:13:10 2007
@@ -9,9 +9,9 @@ DEFS = -DLOCALEDIR=\"$(localedir)\" @DEF

bin_PROGRAMS = oggdec

-INCLUDES = @OGG_CFLAGS@ @VORBIS_CFLAGS@ @SHARE_CFLAGS@
+INCLUDES = @OGG_CFLAGS@ @VORBIS_CFLAGS@ @SHARE_CFLAGS@ @I18N_CFLAGS@

-oggdec_LDADD = @LIBICONV@ @SHARE_LIBS@ @VORBISFILE_LIBS@ @VORBIS_LIBS@ @OGG_LIBS@
+oggdec_LDADD = @LIBICONV@ @SHARE_LIBS@ @VORBISFILE_LIBS@ @VORBIS_LIBS@ @OGG_LIBS@ @I18N_LIBS@
oggdec_DEPENDENCIES = @SHARE_LIBS@

oggdec_SOURCES = $(oggdecsources)

 

5.1 Channel Mappings

Reply #14
I test the last 2.84 version in rarewares and I can't see any progress about this problem.
Really is strange encode wit oggenc2 a multichannel wav, or a raw PCM, with correct channel order (without WAVE_EXTENSIBLE_HEADER of course) and decode with oggdec obtaining a different result.

The problem is know:
Basically, if a WAVEFORMATEXTENSIBLE header is not found, then, as no channel mask has been specified, the channels are encoded in the order presented. Suppose you have a 5.1 channel file, without the correct header but in vorbis channel order, then all will be well. The encoded file will play back correctly and will be decoded to a 5.1 channel wave file with the correct headers, channel mask, etc., but the decoded file will differ from the original because the channels will now be in WAVEFORMATEXTENSIBLE order. Conversely, if the 5.1 channel original file was without the WAVEFORMATEXTENSIBLE header but in WAVEFORMATEXTENSIBLE channel order, all will be screwed!!


And the solution also:
I guess it wouldn't be too tough to add an option to select from a range of predefined mappings in the event that the correct header was absent. If someone would like to provide a sensible list, I could add that in the next release. Is the list provided by Dzamburu, above, correct and complete?


Of course the Dzamburu list is correct, but only need the first input:
if the input is WAV or PCM uncompressed data, the order is FL-FR-FC-LFE-BL-BR, any other option must be considered like a exception and can be supported or not, but the default is clear.

What soft can output a different uncompressed channels order? Only a few old or outdated.
The same OggDec output the default order.

I agree that it would be helpful to deal with these possibilites in the event that the files are incorrectly produced. It's unfortunate that there are applications out there that are not formatting the output correctly in the first place.


I acclaim the OggDec (and Faad) behavior with WAVE_FORMAT_EXTENSIBLE header output and correct ChannelMask, but if others decoders/editors output the standard WAV header (with correct order) is not question to punish the users with a unnecessary problem.

Thanks for your job and attention.