Sound quality in Cubase vs Sonar

Audio Plugin Hosts and other audio software applications discussion
RELATED
PRODUCTS

Post

momus wrote:can someone explain that better,
Yes, I can explain it 18-33% better.
100% agree
Ah! Nous sommes en d'accord. May I have the next dance? *bow*

Post

"That's Frank Zappa up there. People often mistake me for him"

So..... you're NOT dead. Right, thats a relief.

Post

Can someone e-mail me a crack copy of this explanation!!!!???PLEASE! HELP!!???!

Post

momus wrote:
S_A_P® wrote:10% of all files rendered in cubase are 20% better than 13% of files rendered in sonar. Luckily , you can normalize this ratio when you take in to account that 70% of all sonar users eat fish, and that 33% of the fish is tuna. Compare that to Cubase, where only 55% of the users eat fish, and that fish mostly comprises of flounder, cat fish and alligator gars. If you are lucky about 18.9 % of the protools users out there are clinicly insane and cannot even use a protools system. Also take into account that you can usually only understand about 37% of what xoxos rants about, with meffys propensity for playing with baby snakes, you can only draw one conclusion from it all-

Songs written for fish in both cubase and sonar sound exactly the same..
can someone explain that better,
100% agree
As a Cubase user, I can explain 20% of that 13% better, but the other 80% is going to be 27% more confusing.
P2 3.2GHz, XP Pro, M-Audio FW-1814, Cubase SX3

Post

The numbers dont lie sangha

Post

SJ_Digriz wrote:Steinberg for whatever reason is 3db below that lvl at 0db. Although the Cubase statistics tool measures RMS correctly. Wavelab also uses the Steinberg measuring system.

I have no idea why this is or what system the Steinberg method is based on.
Maybe the Cubase panning law settings?

Post

cptgone wrote:
SJ_Digriz wrote:Steinberg for whatever reason is 3db below that lvl at 0db. Although the Cubase statistics tool measures RMS correctly. Wavelab also uses the Steinberg measuring system.

I have no idea why this is or what system the Steinberg method is based on.
Maybe the Cubase panning law settings?
You should have kept reading. Steve linked a post from Katz explaining the difference.

But there is indeed a 3db calibration difference (which by the way is not linear, it flatens out as you approach 0db and expands past -6db) that has nothing to do with the pan law bug that they finally fixed.
If you have to ask, you can't afford the answer

Post

tony Smyth wrote:"That's Frank Zappa up there. People often mistake me for him"

So..... you're NOT dead. Right, thats a relief.
Not yet. And I do take considerable comfort in the fact, it's true. :-)

Post

SJ_Digriz wrote:that has nothing to do with the pan law bug that they finally fixed.
What bug was that? I missed that one.

Post

I took a fish head
out to see a movie
Didn't have to pay
to get it in
Buy my cd here (Prog rock/synth pop/classical/soundtrack-ish music):
http://cdbaby.com/cd/cyanogen
Newer songs/unreleased material:
https://soundcloud.com/cyanogenmusicpage

Post

bduffy wrote:
SJ_Digriz wrote:that has nothing to do with the pan law bug that they finally fixed.
What bug was that? I missed that one.
lol, this is one of the oldest Cubase bugs. But, if you, for example, linked two channels at different positions, the reletive gain applied to both would not be constant between the 2 in a gain or reduction. It had many other consequences and ways to produce the error. But is was fixed in SX-3.02 patch.
If you have to ask, you can't afford the answer

Post

Right. Sounds familiar; I'll check out that article. Another reason to bump up to SX 3!

Thanks for the info.

Post

SJ_Digriz wrote:
bduffy wrote:
SJ_Digriz wrote:that has nothing to do with the pan law bug that they finally fixed.
What bug was that? I missed that one.
lol, this is one of the oldest Cubase bugs. But, if you, for example, linked two channels at different positions, the reletive gain applied to both would not be constant between the 2 in a gain or reduction. It had many other consequences and ways to produce the error. But is was fixed in SX-3.02 patch.
huh?! you mean the dbLawFlaw ?? that is something else.. the panLaw is just differently adjusted than eg in logic. you can change that, though. if you adjust it, it think you should be able to conform to aes-17 (or whatever that one is called :? )?

Post

efluon wrote:
SJ_Digriz wrote:
bduffy wrote:
SJ_Digriz wrote:that has nothing to do with the pan law bug that they finally fixed.
What bug was that? I missed that one.
lol, this is one of the oldest Cubase bugs. But, if you, for example, linked two channels at different positions, the reletive gain applied to both would not be constant between the 2 in a gain or reduction. It had many other consequences and ways to produce the error. But is was fixed in SX-3.02 patch.
huh?! you mean the dbLawFlaw ?? that is something else.. the panLaw is just differently adjusted than eg in logic. you can change that, though. if you adjust it, it think you should be able to conform to aes-17 (or whatever that one is called :? )?
No, not panlaw but dblaw. It started in SX-1 and remained until SX-3.02.

Here is the exerpt.
Version History Cubase SX wrote: The following problems have been fixed in Cubase SX version 3.0.2
• dB Law: relative automation levels for multiple points or multiple event volumes do not retain their correct logarithmic dB relation
There are adjustments for pan law (0, -3, -4.5, -6) but that is entirely different issue.
If you have to ask, you can't afford the answer

Post

btw if you don't think that bug was huge, imagine if you are working a project and do a global trim (very common task). It would destroy your entire mix.
If you have to ask, you can't afford the answer

Post Reply

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”