[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] FMHEncode1/2 and ambdec
Thanks Joseph. In the help file for FMHEncode1 and 2 : "Output channels
are in order W,X,Y,Z, R, S, T, U, V". So it looks like it's using some
other ordering standard or one of its own. I plan to record the sound in
a HO format for editing and storage purposes, and I'll be sure to use
one of the standards. I'm testing FMHEncode0 now with ambdec and I
believe it's working OK. FMHEncode0 has no help file, but it also seems
to be using the W,X,Y,Z,R,S,T,U,V ordering.
Best,
Iain
Em Seg, 2015-12-21 às 10:42 -0800, Joseph Anderson escreveu:
> Hi Iain,
>
>
> I expect you know this, but there are a few things you need to get
> correct. There are several different channel scaling (normalisation)
> schemes, along with a variety of channel order formats for HOA. Rather
> than repeat all that here, I'll just refer you to the Ambisonic data
> exchange formats page on Wikipedia.
>
>
> My guess would be that FMH would use 'maxN' normalisation with 'FuMa'
> channel ordering.
>
>
> Hope that helps!
>
>
> Joseph Anderson
>
>
>
>
> http://www.ambisonictoolkit.net/
>
>
>
>
>
> On Mon, Dec 21, 2015 at 9:30 AM, Iain Mott <mott@xxxxxxxxxxxxxxx>
> wrote:
> Thanks Florian, will have a look at this although I'm really
> aiming to decode outside of SC.
>
> I sent my original message to Fons. He replied with the
> following and given what he said, I'll likely use FMHEncode0
> (which I was unaware of) along with ambdec:
>
> FMHEncode0 seems to produce correct FuMa scaled levels.
>
> FMHEncode1,2 try to do something with distance. As far as
> I can see, the way the 'rho' paramter is used does NOT
> produce correct encoding for rho = 1, and the wComp
> thing seems to be an attempt to correct for this. You
> could check this by comparing the output with that of
> FMHEncode0.
>
> It is possible to create some 'internal' effect by
> reducing the non-zero order components and that is
> probably what this 'rho' thing is supposed to do.
> But it doesn't look correct to me. And anything
> beyond the radius of the speakers is nonsense, it
> just produces completely incorrect decoding and
> completely destroys any advantages that higher
> order could offer.
>
> Distance perception is better controlled by reverb
> and early reflection levels.
>
> Anyway whatever those two ugens seem to do is meant
> for a decoder expecting FuMa scaling. So yes, you
> could use Ambdec.
>
>
>
>
>
>
> Em 20-12-2015 23:55, fgrond escreveu:
> Hello Iain,
>
> I have no experienece with Fons Adriaensens ambdec,
> but I recently explored the ambisonics decoder toolbox
> by Aaron Heller:
> https://bitbucket.org/ambidecodertoolbox/adt.git
> It is a Matlab / Octave toolkit which allows you to
> generate decoders of various orders and flavours
> (FUMA, ambix, ...).
> The outputfiels are either for ambdec, the ambix suite
> or as Faust .dsp files, which you can then compile
> amongst others as SuperCollider Ugens, so you can do
> the decoding directly in SuperCollider.
>
> Cheers,
>
> Florian
>
>
> On 20/12/15 14:23, Iain Mott wrote:
> Hello list,
>
> Is it possible to use Fons Adriaensen's ambdec
> to decode FMHEncode1/2 encoded 2nd order
> signals? If so, which of FMHEncode's two
> scaling modes correspond to one (or two) of
> the 'N3D', 'SN3D' and Furse-Malham scalings
> available in ambdec?
>
> I'll paste below the paragraph on scaling in
> the ambdec manual
>
> Thanks,
>
> Iain
>
>
> In order to correctly use some of the options
> discussed below, the following must be
> understood.
> Ambisonic signals are traditionally scaled in
> a number of di erent ways.
> For mathematical analysis it is very
> convenient to use the normalised form, meaning
> that each
> spherical harmonic has unity power when
> integrated over the sphere. This is called the
> 'N3D'
> form of Ambisonic signals. A close variation
> on this is the 'semi-normalised' or 'SN3D'
> form. This also has desirable
> mathematical properties, and is used by some
> existing software, for example the Ambisonic
> tools from IEM, Graz. The alternative to both,
> and widely used, is the so-called Furse-Malham
> form. This applies some gain factors to the
> signals so that they all have the same maximum
> level over all directions. The
> only exception is the pressure signal W which,
> for historical reasons, is attenuated by 3 dB.
> Many Ambisonic applications and audio les use
> the Furse-Malham representation.
> AmbDec allows to use all three
> representations, both for the input signals
> and for the matrix
> coe cients. If the two settings are di erent,
> AmbDec will automatically apply the necessary
> gain factors to convert between them. So you
> can design a decoder matrix using the
> normalised
> form (which is usually less confusing, in
> particular for higher orders), and then use it
> with signals
> scaled according to the Furse-Malham standard.
> Important note: the normalised form used is
> always the 3-D one, even for an
> horizontal-only decoder. The reason for this
> is that all decoders are used in 3-D space |
> unless your speaker are in nite vertical line
> sources the rules of physical 3-D space apply,
> even when analysing a 2-D
> decoder.
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive:
> https://listarc.bham.ac.uk/marchives/sc-users/
> search:
> https://listarc.bham.ac.uk/lists/sc-users/search/
>
>
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: https://listarc.bham.ac.uk/marchives/sc-users/
> search: https://listarc.bham.ac.uk/lists/sc-users/search/
>
>
>
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/