IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Wrong channel mapping for 6.1 (7 channels)
Muxson
post Nov 15 2013, 17:53
Post #1





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



Iíve been using oggenc2 and oggdec for a while now and came across what I think are still bugs, or channel mapping error.

The issue is wrong channel mapping with 7 channels (6.1).
I made some tests with 4, 5 and 6 channels and it works well.

My test procedure was to create a wav file with 4, 5, 6 and 7 channels (with Audacity), encode it with oggenc2 and then decoding it with oggdec.
For 4, 5 and 6 channels, the tracks are back to the position they were originally and, in the middle or the process, the ogg file respects the Ogg Vorbis I Definition.

But with 7 channels, they are messed up.
If we had 1 2 3 4 5 6 7.wav, the encoding followed by decoding would render 1 2 3 7 5 4 6.wav

Looking into each function individually, I think they both do not comply with the Ogg Vorbis I definition!

If we had 1 2 3 4 5 6 7.wav, oggenc2 would give 1 3 2 6 7 5 4.ogg, where it should be 1 3 2 5 6 7 4.ogg.

And oggdec remaps the channels the wrong way.
If we has 1 2 3 4 5 6 7.ogg, it would give 1 3 2 5 6 7 4.wav, where it should give 1 3 2 7 4 5 6.wav

I'm using
Windows 7,
Audacity 2.0.5,
OggEnc v2.87 (libvorbis 1.3.3) (as in oggenc2.exe),
OggDec v1.9.7 (libVorbis 1.3.1) Compiled on: Mar 29 2010

Any thoughts?

Thanks,
Muxson
Go to the top of the page
+Quote Post
ktf
post Nov 16 2013, 16:07
Post #2





Group: Members
Posts: 333
Joined: 22-March 09
From: The Netherlands
Member No.: 68263



QUOTE (Muxson @ Nov 15 2013, 17:53) *
Looking into each function individually, I think they both do not comply with the Ogg Vorbis I definition!

If we had 1 2 3 4 5 6 7.wav, oggenc2 would give 1 3 2 6 7 5 4.ogg, where it should be 1 3 2 5 6 7 4.ogg.

And oggdec remaps the channels the wrong way.
If we has 1 2 3 4 5 6 7.ogg, it would give 1 3 2 5 6 7 4.wav, where it should give 1 3 2 7 4 5 6.wav

Could you please explain why you think this is wrong? oggenc seems to do fine, but maybe I missed something?

The usual way of mapping in WAV, AFAIK, is like the FLAC format does it: front left, front right, front center, LFE, back center, side left, side right
The way of OGG mapping is, as specified: front left, center, front right, side left, side right, rear center, LFE

So, when converting the first spec to the second, you'd get 1 3 2 6 7 5 4, just like oggenc 2 did. Reversing the process would give you 1 3 2 7 6 4 5, which is neither of the two. You're sure you did the numbers all right?


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
Muxson
post Nov 16 2013, 18:34
Post #3





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



Thanks for your input ktf.
I wish I could agree with you when you say:

QUOTE (ktf @ Nov 16 2013, 16:07) *
The usual way of mapping in WAV, AFAIK, is like the FLAC format does it: front left, front right, front center, LFE, back center, side left, side right


If you look at the Wave spec , you will see that that mapping is Front Left - FL, Front Right - FR, Front Center - FC, Low Frequency - LF, Back Left - BL, Back Right - BR, Front Left of Center - FLC, Front Right of Center - FRC, Back Center - BC, Side Left - SL, Side Right - SR, Top ...

If we have only 7 channels, I assume we can call then FL, FR, FC, LFE, BL, BR, Back Center - BC.
So, as you see, it is not like FLAC (FL, FR, FC, LFE, BC, BL, BR)

You are right on this one:

QUOTE (ktf @ Nov 16 2013, 16:07) *
The way of OGG mapping is, as specified: front left, center, front right, side left, side right, rear center, LFE


But,

QUOTE (ktf @ Nov 16 2013, 16:07) *
So, when converting the first spec to the second, you'd get 1 3 2 6 7 5 4, just like oggenc 2 did.


yes, this is what I get.
It would be right if the Wave mapping was the same as FLAC, but it's not, and that is the problem.

QUOTE (ktf @ Nov 16 2013, 16:07) *
You're sure you did the numbers all right?


Yes, I'm.

Please have a look at the illustration attached.


Go to the top of the page
+Quote Post
Muxson
post Nov 16 2013, 20:43
Post #4





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



And that was only talking about oggenc...

Here is an illustration about mapping for encoding and decoding.
That makes it easy to see what I mean by
QUOTE (Muxson @ Nov 15 2013, 17:53) *
oggdec remaps the channels the wrong way.


Go to the top of the page
+Quote Post
nu774
post Nov 17 2013, 03:58
Post #5





Group: Developer
Posts: 514
Joined: 22-November 10
From: Japan
Member No.: 85902



@Muxson
Why do you feed FL-FR-FC-LF-BL-BR-BC to oggenc when the spec clearly says "side left" and "side right"?
In the Microsoft WAV layout, it will be FL-FR-FC-LF-BC-SL-SR, not FL-FR-FC-LF-BL-BR-BC.

Of course it would be nice if oggenc recognizes both layouts and takes care of order difference when input layout is given by dwChannelMask field.
Go to the top of the page
+Quote Post
ktf
post Nov 17 2013, 13:42
Post #6





Group: Members
Posts: 333
Joined: 22-March 09
From: The Netherlands
Member No.: 68263



QUOTE (nu774 @ Nov 17 2013, 03:58) *
Of course it would be nice if oggenc recognizes both layouts and takes care of order difference when input layout is given by dwChannelMask field.

Maybe it does, maybe the dwChannelMask field specifies side left and right. I don't know what Audacity saves to by default.


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
Muxson
post Nov 17 2013, 14:00
Post #7





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



Yes, you are right nu774, side is not back.

But in my original post, I spoke about channel number, not spacial distribution.
The reason is because I'm using Ogg Vorbis to encapsulate 6 discrete channels. And because LFE is not keeping the full spectrum (for a good reason), I'm using 7 channels and disregard LFE.

So, for that specific application, I need the have the channels back to their original position.
1 2 3 4 5 6 7.wav > oggenc | oggdec = 1 2 3 4 5 6 7.wav
That is not the case yet and I don't see a good explanation why.
Therefore I think it is a mapping error as I demonstrated earlier.

By the way, I found a way around the problem (SoX remix)... (just so the discussion remains focused!)

Now, nu774, could you help me find where Microsoft defines WAV as FL-FR-FC-LF-BC-SL-SR?
All I could find I documented in earlier posts.
QUOTE (nu774 @ Nov 17 2013, 03:58) *
In the Microsoft WAV layout, it will be FL-FR-FC-LF-BC-SL-SR, not FL-FR-FC-LF-BL-BR-BC.

If what you say is true, then it would explain the oggenc mapping. But what is true??
Go to the top of the page
+Quote Post
Muxson
post Nov 17 2013, 14:17
Post #8





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



QUOTE (ktf @ Nov 17 2013, 13:42) *
I don't know what Audacity saves to by default.

Audacity doesn't remap anything.
1 2 3 4 5 6 7.wav > 1 2 3 4 5 6 7.ogg, no LFE filtering!
And this is true for other formats and channel number as well.

I don't know about dwChannelMask 'cause I can't read it. I'm not equipped for that...
But I suspect Audacity doesn't follow all the format specs...
Go to the top of the page
+Quote Post
lvqcl
post Nov 17 2013, 14:21
Post #9





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



QUOTE
Now, nu774, could you help me find where Microsoft defines WAV as FL-FR-FC-LF-BC-SL-SR?

Vorbis specification defines 7 ch as 6.1 surround:
"channel order: front left, center, front right, side left, side right, rear center, LFE"

And the corresponding WAV channel mask is 0x70F:
SPEAKER_FRONT_LEFT + SPEAKER_FRONT_RIGHT + SPEAKER_FRONT_CENTER + SPEAKER_LOW_FREQUENCY + SPEAKER_BACK_CENTER +
SPEAKER_SIDE_LEFT + SPEAKER_SIDE_RIGHT
Go to the top of the page
+Quote Post
Muxson
post Nov 17 2013, 14:36
Post #10





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



QUOTE (lvqcl @ Nov 17 2013, 14:21) *
QUOTE
Now, nu774, could you help me find where Microsoft defines WAV as FL-FR-FC-LF-BC-SL-SR?

Vorbis specification defines 7 ch as 6.1 surround:
"channel order: front left, center, front right, side left, side right, rear center, LFE"

And the corresponding WAV channel mask is 0x70F:
SPEAKER_FRONT_LEFT + SPEAKER_FRONT_RIGHT + SPEAKER_FRONT_CENTER + SPEAKER_LOW_FREQUENCY + SPEAKER_BACK_CENTER +
SPEAKER_SIDE_LEFT + SPEAKER_SIDE_RIGHT


Yes, understood.
I think my wav has a 0x07F mask, and not 0x70F.
Or no mask at all... (can that be?)
Does Audacity set masks?
How can I see what mask is in my file? (I'm not a progamer, "just" a CLI user...)
Go to the top of the page
+Quote Post
lvqcl
post Nov 17 2013, 14:45
Post #11





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



QUOTE
I think my wav has a 0x07F mask, and not 0x70F.

I doubt it... FL-FR-FC-LF-BL-BR-BC is 0x1 + 0x2 + 0x4 + 0x8 + 0x10 + 0x20 + 0x100 = 0x13F

QUOTE
How can I see what mask is in my file?

You can use sndfile-info.exe (from libsndfile)
Go to the top of the page
+Quote Post
Muxson
post Nov 17 2013, 18:41
Post #12





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



QUOTE (lvqcl @ Nov 17 2013, 14:45) *
You can use sndfile-info.exe (from libsndfile)

Wow, thanks lvqcl! You opened my eyes. Now I understand the thinking with masks.
Sorry for my ignorance... But I'm learning!

Now I have some answers.

Audacity DOES NOT add a channel mask to a multitrack wav!

SoX -M does, except for 7 ch...
for 6 ch: 0x3F (L, R, C, LFE, Ls, Rs)
for 7 ch: 0x0 (should not be zero)

And so does oggdec
for 6 ch: 0x3F (L, R, C, LFE, Ls, Rs)
for 7ch: 0x70F (L, R, C, LFE, Cs, Sl, Sr)

Following that logic, I can now review my statements made in the first post.
QUOTE (Muxson @ Nov 15 2013, 17:53) *
If we had 1 2 3 4 5 6 7.wav, oggenc2 would give 1 3 2 6 7 5 4.ogg, where it should be 1 3 2 5 6 7 4.ogg.

Correction: If we had 1 2 3 4 5 6 7.wav, oggenc2 would give 1 3 2 6 7 5 4.ogg and that is correct!

QUOTE (Muxson @ Nov 15 2013, 17:53) *
And oggdec remaps the channels the wrong way.
If we had 1 2 3 4 5 6 7.ogg, it would give 1 3 2 5 6 7 4.wav, where it should give 1 3 2 7 4 5 6.wav

Correction: If we had 1 2 3 4 5 6 7.ogg, oggdec should give 1 3 2 7 6 5 4.wav

Confusing? Yes it is.

QUOTE (nu774 @ Nov 17 2013, 03:58) *
In the Microsoft WAV layout, it will be FL-FR-FC-LF-BC-SL-SR, not FL-FR-FC-LF-BL-BR-BC.

Yes, nu774, you are right. I got it now.
So if I understand correctly, when oggenc sees 7 channels, it assumes the mask is 0x70F and not 0x07F, as I (wrongly) guessed.

Here is my corrected visual

Go to the top of the page
+Quote Post
Muxson
post Nov 18 2013, 14:34
Post #13





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



QUOTE (Muxson @ Nov 17 2013, 18:41) *
Correction: If we had 1 2 3 4 5 6 7.ogg, oggdec should give 1 3 2 7 6 5 4.wav


Oops, sorry, correction2: If we had 1 2 3 4 5 6 7.ogg, oggdec should give 1 3 2 7 6 4 5.wav
Go to the top of the page
+Quote Post
john33
post Nov 21 2013, 23:42
Post #14


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



New compile of oggdec v1.9.8 uploaded to Rarewars that fixes this issue. Thanks to all for bringing this to my attention and for the advice, smile.gif

This also affects the decoding within oggdropXPd, and I'll fix this ASAP.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Muxson
post Nov 22 2013, 11:41
Post #15





Group: Members
Posts: 9
Joined: 15-November 13
Member No.: 112228



QUOTE (john33 @ Nov 21 2013, 23:42) *
New compile of oggdec v1.9.8 uploaded to Rarewars that fixes this issue. Thanks to all for bringing this to my attention and for the advice, smile.gif


Thank you John for the correction.

On RareWares you mention it is affecting 7 and 8 channels decoding.
I'm only using the 7 channels scheme but I thought I could as well check the 8 ch configuration.
And, lo and behold, there is an error in that one as well...

To make it easier for you, here is the fix:
src / audio.c / line 477:
CODE
int permute[8][8] = {{0}, {0,1}, {0,2,1}, {0,1,2,3}, {0,2,1,3,4}, {0,2,1,5,3,4}, {0,2,1,6,5,3,4}, {0,2,1,6,7,5,3,4}};

Should read
CODE
int permute[8][8] = {{0}, {0,1}, {0,2,1}, {0,1,2,3}, {0,2,1,3,4}, {0,2,1,5,3,4}, {0,2,1,6,5,3,4}, {0,2,1,7,5,6,3,4}};


And here is the visual to explain it:


Hope this helps...

This post has been edited by Muxson: Nov 22 2013, 11:42
Go to the top of the page
+Quote Post
john33
post Nov 22 2013, 13:14
Post #16


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



Thanks again!! smile.gif

New compile available at Rarewares now.

Edit: oggdropXPd correction will have to wait until next week, but I'll try to have done in the early part of the week. This will also use SoXR resampling library in place of libsamplerate.

This post has been edited by john33: Nov 22 2013, 13:15


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th July 2014 - 12:14