pan law bug?

It's hard to know what's going on without knowing what the signal you're using contains.

Can you provide a sample?

Where did the OMF come from? and what pan law was used in the project that made the OMF?

And have you checked Offset mode? Press "o" (letter not number) and see it the fader is at zero there.

Tom

Sdog,

I think you're right about there being a bug (or something) that's affecting Sonar's pan laws.  I imported the file you linked into an empty project and started switching between the different panning laws.  However, the default "0dB center, sin/cos taper" pan law showed the correct peak value.  IOW, the file was peaking at 0dB FS when set to this pan law.  I made a comparison between Sonar 8.3.1 and Sonar 8.5.1 using your file and here's what I got:
.
.
Sonar 8.3.1

• 0dB Center, sin/cos taper, constant power = 0dB FS
• -3dB Center, sin/cos taper, constant power = -3dB FS
• 0dB Center, squareroot taper, constant power = 0dB FS
• -3dB Center, squareroot taper, constant power = -3dB FS
• -6dB Center, Linear Taper = -6dB FS
• 0 dB Center, Balance Control = 0dB FS
  

.
.
Sonar 8.5.1

• 0dB Center, sin/cos taper, constant power = 0dB FS
• -3dB Center, sin/cos taper, constant power = -6dB FS
• 0dB Center, squareroot taper, constant power = 0dB FS
• -3dB Center, squareroot taper, constant power = -6dB FS
• -6dB Center, Linear Taper = -12dB FS
• 0 dB Center, Balance Control = 0dB FS
  

.
.
As you can see, Sonar 8.5.1 is reducing all the non-0dB pan laws by twice the amount of the pan law.  For example, a -3dB pan law lowers the signal by an extra 3dB, while a -6dB pan law lowers it by an extra 6dB.  This reduction is constant when you pan the track all the way to either side (Left or Right).  For example, if you use "-6dB Center, Linear Taper" as your panning law you will get 12dB of reduction in the center and 6dB of reduction when panning hard L/R.  All the 0dB panning laws seem unaffected by this change, as well as Sonar 8.3.1 (which works as advertised). 

Can anyone else confirm this behavior before I file a bug report?

Sdog, thanks for bringing this up to our attention.

Bit,

Could you link your reference test tone in here so I can test with it?

Just wanna make sure that it is not a setting that's causing this.  Thanks!

I just used a generic 32-bit mono 1KHz sine, generated by Audition. It shouldn't make any difference where the wave comes from. I'm not at my desk right now, but I'll take some screenshots tomorrow.

I'll also try it with sdog's test wave, but I really think if you want to validate the pan law you should do it with a sine wave. RMS calculations on complex waveforms are inherently inaccurate because they have to be averaged over some time window.

The convenient thing about sine waves is that the average RMS is the same as the actual RMS value of any cycle in the waveform, and the peak value is steady with a consistent relationship to the RMS value.

The test file OTOH contains a wide dynamic range, about 24db, plus significant overs. I don't know how the harmonics added by severe clipping affects the RMS calculation, but it's probably not an ideal test tone.

Can someone else please test this? 

Thanks!

Thanks Mudgel.  I really appreciate it :-)

tarsier


I just gave it a try: Mono test tone, Sine wave 997 Hz, -20 dBFS Peak.

Sonar 8.5.1. brand new empty project, no busses, automation etc. Track is mono interleave, with that mono sine clip, panned center.

0 dB Center: -20 dB on Sonar's peak meters.
-3 dB Center: -26 dB
-6 dB Center: -32 dB

Looks like a bug.

Yeah, looks like stereo and mono are reversed; Using -6 pan law and a mono -6, 1k sine with track set to mono shows -18 on the meters.  Change the track interleave to stereo and it shows -12.  Convert the mono clip to stereo and with stereo interleave set to stereo I still get -12.  Change it to mono and it reads -15!  Split the difference I suppose. No big deal but it can't be right.

If the pan laws aren't working right, they haven't been working since version 7 (the oldest version I have on this machine), because  I am getting consistent results between versions 7, 8 and 8.5 (32-bit):

SONAR    Law        Pan       Peak     Stereo Interleave
7.0.2    0db        Left      -3db     -6db
7.0.2    0db        Center    -6db     -6db
7.0.2    -3db       Left      -9db     -9db
7.0.2    -3db       Center    -12db    -9db
7.0.2    -6db       Left      -12db    -12db
7.0.2    -7db       Center    -18db    -12db

8.3.1    0db        Left      -3db      -6db
8.3.1    0db        Center    -6db      -6db
8.3.1    -3db       Left      -9db      -9db
8.3.1    -3db       Center    -12db     -9db
8.3.1    -6db       Left      -12db     -12db
8.3.1    -6db       Center    -18db     -12db

8.5.1    0db        Left      -3db      -6db
8.5.1    0db        Center    -6db      -6db
8.5.1    -3db       Left      -9db      -9db
8.5.1    -3db       Center    -12db     -9db
8.5.1    -6db       Left      -12db     -12db
8.5.1    -6db       Center    -18db     -12db

The first column of levels are with the track set to mono interleave; the second column is with the interleave set to stereo.

The help file states that the default 0db pan law "causes a 3db boost" when  hard-panned. That means the center measurement represents the unaltered signal and the left measurement reflects an adjustment. As shown above, that's just what happens: my test signal is at -6db when panned center but rises to -3db when panned left.

[NOTE: This may seem contrary to the original definition of the "0db pan law" as implemented on hardware consoles in the 1960's. Back then, it mean no compensation for the natural 3db boost. Actually, it's not a contradiction; the full description of SONAR's default pan law is "0db center, sin/cos taper, constant power". The equivalent to the original "0db pan law" in SONAR is called "0db center, balance control". The default pan law in SONAR provides constant power, meaning there is no volume change as a track's pan is adjusted.]

The "-3db center" rule eliminates the L/R pan-boost, and dips the signal by 3db when centered. This still achieves a constant level when L and R are combined, but the overall level is lower.

The "-6db center" rule is the same as the -3db law, except that the center-panned signal is attenuated by 6db. Again, we still achieve the desired uniformity while panning.

So all the numbers above all make perfect sense. The pan laws do not appear to be broken.

[NOTE: There is no standard for pan law naming conventions. Different DAW vendors call the same algorithms by different names. In Cubase, for example, what they call the "0db pan law" is equivalent to what SONAR calls "0db, balance control". What Cubase calls the "-3db pan law" (its default) is equivalent to what SONAR calls "0db center, sin/cos taper, constant power" (SONAR's default). I mention this because the names given to these pan laws may lead to confusion about what they actually do.]

Maybe it's 64 bit thing. I have XP 32 bit here and not seeing this

Tom

One more reason why we should have separate 32 and 64 bit forums.

SONAR 8.5.1 x86 & x64 on VISTA x64 SP2

0db Sin/Cos         Left        3db         0db
                            Center    0db         0db
-3db Sin/Cos        Left        -3db       -3db
                            Center    -6db       -3db
0db Sqrt               Left          3db        0db
                            Center      0db        0db
-3db Sqrt             Left          -3db       -3db
                            Center     -6db        -3db
-6db Center         Left          -6db        -6db
                            Center      -12db      -6db
0db Center           Left            0db         0db
                            Center        0db         0db

SONAR 8.3.1 x86 & x64 onVISTA x64 SP2

0db Sin/Cos             Left        3db            0db
                            Center        0db            0db
-3db Sin/Cos         Left            0db            0db
                            Center        -3db            0db
0db Sqrt                 Left            3db            0db
                            Center          0db            0db
-3db Sqrt              Left              0db            0db
                            Center         -3db            0db
-6db Center         Left                0db           0db
                            Center           -6db          0db
0db Center           Left                0db           0db
                            Center            0db            0db
 
 
This damned software :It let me paste a table then when it saved it all the formatting was deleted arghhh!

Yeh! I get the diference between SONAR 8.3 and 8.5 not 32 or 64 bit.

I did it twice and set up a table so that I could enter results properly without error. Unfortunately I lost all formatting once saved into this post.

I didn't mention my file was at 0dbfs. I'll have to go back and add that in otherwise it'll be meaningless

This damned software :It let me paste a table then when it saved it all the formatting was deleted arghhh!

Just use the Courier font and format it with blanks, or use the [ code ] [ /code ] tags if it's just indenting you want to preserve.

bitflipper

I didn't mention my file was at 0dbfs

I wonder if using a 0dbFS file skews the results? I've been doing all my testing with a -6dbFS file and not getting the same results as everyone else. I mean, if a real track is at 0db then pan laws are the least of my worries...

.
It doesn't make any difference.
 
I tried with both a 0dB and a -6dB file and still got the same results.