[NUT-devel] [nut]: r613 - docs/nutissues.txt

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

>> >> >> > > On a related subject, it might also be useful to define
>> >> >> > > the channel disposition when there is more than one. Mono
>> >> >> > > and stereo can go by with the classical default, but as
>> >> >> > > soon as there is more channels it is really unclear. And
>> >> >> > > imho such info could still be usefull with 1 or 2
>> >> >> > > channels. Something like the position of each channel in
>> >> >> > > polar coordinate (2D or 3D?) should be enouth.
>> >> >> > 
>> >> >> > I agree
>> >> >> > What about that LFE channel thing?
>> >> >> 
>> >> >> I was thinking about simply setting the distance to 0,
>> >> >> however a flag for "non-directional" channels might be
>> >> >> better.
>> >> >
>> >> > This is wrong, LFE is not about direction but about the type
>> >> > of speaker.  LFE stands for "Low-frequency effects".  If id
>> >> > move a other random speaker at disatnce 0 and the LFE one out
>> >> > and switch channels it wont sound correct ...
>> >> >
>> >> >> 
>> >> >> > And where do we put this info, The stream header seems the logic
>> >> >> > place if you ask me ...
>> >> >> 
>> >> >> I agree, this is essential information for proper presentation it
>> >> >> definitly belong there.
>> >> >
>> >> > Good, now we just need to agree on some half sane way to store it.
>> >> > for(i=0; i<num_channels; i++){
>> >> >     x_position                  s
>> >> >     y_position                  s
>> >> >     z_position                  s
>> >> >     channel_flags               v
>> >> > }
>> >> >
>> >> > CHANNEL_FLAG_LFE             1
>> >> >
>> >> > seems ok?
>> >> 
>> >> I'm not convinced this is the right way to go.  Consider a recording
>> >> made with several directional microphones in the same location.  Using
>> >> spherical coordinates could be a solution.
>> >
>> > The above was intended to specify the location of the speakers not
>> > microphones.
>> 
>> I'm having a hard time imagining a player moving my speakers around
>> depending on the file being played.
>> 
>> > And spherical coordinates would just drop the distance, thats the same
>> > as setting the distance to 1 and storing that as xyz.
>> 
>> Spherical coordinates without radius needs only two fields.
>
> True, but that gets tricky with integers and precission.

Use rational numbers.  That's essentially what you suggest below anyway.

>> > Actually the main reason why i didnt use spherical is that with integers
>> > theres a precission to decide on or you end up with rationals. And this
>> > somehow starts looking messy ...
>> 
>> I don't see any fundamental difference.  If restricted to integer
>> coordinates, an arbitrary point can be described only with a certain
>> precision, regardless of coordinate system.
>
> True but if you map the points to a sphere, then x,y,z gives you arbitrary
> precisson on the surface of the sphere while with spherical coordinates
> this needs some additional "tricks".
> Thus x,y,z give you arbitrary directional precission at quite low complexity.

I didn't realise you were only interested in direction.  Not that I
know what you'd use the distance for, or how.

>> >> Whatever the coordinate system, the location and orientation of the
>> >> listener must be specified, even if there is only one logical choice.
>> >
>> > of course
>> > right_position               s
>> > forward_position             s
>> > up_position                  s
>> >
>> > And
>> > "the listener is at (0,0,0), (1,0,0) is right, (0,1,0) is forward,
>> > (0,0,1) is up"
>> 
>> You're forgetting the measurement unit, i.e. metres, feet, etc.
>
> Hmm, I was thinking that only x/y, x/z that is the direction would matter.
> If theres some sense in also storing distance then we would need a 4th
> variable to specifiy the precission like:
> (x/p, y/p, z/p) meter
>
> We can surely do this if someone thinks this is usefull.

I don't think it's useful, but there's no telling what people who
measure the copper purity of their speaker cables might believe.

-- 
Måns Rullgård
mans at mansr.com