Vorbis dev - May 2008 - Channels ordering bug

Hi.

I think that vorbis-tools use a wrong order for channels when dealing with
5.1 surround WAV files.

More precisely, I find in the Vorbis specification that the output order is:

0: front left
1: front center
2: front right
3: rear left
4: rear right
5: LFE

(source: http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#id342556 )

At the same time, the order of channels in WAV files seems to be:

0: front left
1: front right
2: front center
3: LFE
4: rear left
5: rear right

(source: http://www.microsoft.com/whdc/device/audio/multichaud.mspx#E4C )

Now, in oggenc/audio.c, I see that the permutation array is used that way in
wav_ieee_read:

            buffer[j][i] = buf[i*f->channels + f->channel_permute[j]];

To accommodate the specified orders, the permutation array should therefore
be:

	0, 2, 1, 4, 5, 3

But wav_permute_matrix defines it as "0,2,1,5,3,4".

The same incorrect array is also present in oggdec.c.

I hope this problem can be fixed.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20080531/8c1f1810/attachment.pgp

Nicolas, hi,

I'm not sure if you just registered for the mailing list, but some
hours ago I posted about a patch[1] that needs to be tested by the
community to fix this very same issue.  If you do not mind, read the
thread[2] and contribute some feedback.

-Ivo

[1] https://trac.xiph.org/ticket/1326
[2] http://lists.xiph.org/pipermail/vorbis-dev/2008-May/019432.html

Le tridi 13 prairial, an CCXVI, Ralph Giles a ?crit?:
> Is there any convention for what the length is in these extended wav files?
> It would be nice if we could handle this automatically, based on a magic 
> length, or lack of an EOF, instead of needing an explicit option.
We can find the following values:

		RIFF size	data size
mplayer		0x7FFFF024	0x7FFFF000
ffmpeg		0		0
arecord		0x80000024	0x80000000
ogg123		0x7FFFFFF7	0x7FFFFFD3
mpg123		0x24		0

So there are two common ideas, but nothing definite an consistent.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20080531/69275e1d/attachment.pgp