ORIGINAL: steve austin

ass-tronaught

a man bearly alive..

we can rebild him.

we have the teknoligy.

we can bild the worlds 1st byonic man.



sorry fellow sonarites i couldnt resist.
this will be my only comments in the thread.
thx

thx to ron and cw for their hard work on this.

uh, oh. Is this true, Ashkar? Up to your old tricks again? It's a sad day, indeed, if that's the case.

Steve McCroskey: Looks like I picked the wrong week to stop sniffing glue

ORIGINAL: Mr. Ease

In response to no-one in particular...

Come on guys, do we really want Ron to reconsider this thread yet again???

At least I tried (right or wrong) to respond to Steve's post objectively and point out his errors. I also tried to put up some other possible causes for this entire thread. What about considering the points I made and shooting me down with some solid reasoning or just maybe you might think I have a point? I'd just like to help a little to get to the bottom of this whole thing - although I am sure Ron is a long way past needing my help. :<)

No-one was directing anything towards you. The nefarious steve austin has many questionable posts that you may want to review (look at my post after yours) before you take him too seriously.

I did state at the start of my post that "i would HAZARD a GUESS". when does that constitute trolling.well i don't think it does. As soon as some one has their own view,or contradicts the sheep, apparently their trolling??? i'm not with you or against you,neither do i wish to be,i just have an opinion like anyone else,and i don't believe(within reason) that i should submit to your idea of predictable don't rock the boat replie's! so get over yourselves and we'll all be free to say our bit and speak our mind. OK!? Good now on we go!
Ok Ron(and i have no intention of a tit for tat with you,believe me!) but i'll rephrase my hazard guess for everyone concerned.
I would say the algorythms used to handle the data to the nulling point is where the difference lie's,and in ADDITION to that,the conversion process to a wav file could quite possibly have a TONNE to do with it.some times it's the obvious and simple things that are quite often overlooked but can be the cause for such problems.
Because the facts are that you yourself would be of GURU status(or we would rightly expect so,cosidering your payed position)concerning such things,and assuming for a minute that people are hearing genuine difference's, then why have you not been able to pin it down(you've covered all major point's and have effectively negated them from the potential cause)that must mean that what i'm saying is a high likleyhood considering that the language of binary code allows programmers to express themselves in UNLIMITED ways(EVEN WITHIN THE CONFINES OF ESTABLISHED TECHNIQUES AND CODING PROCESS) and they certainly wouldn't share their secrets with much anyone else would they.Or as the situation stands (again assuming that all these others are geuinely hearing differences in the audio signal,which i believe to be the truth) then you obviously don;t know everything about the subject and i may just be correct!) Right or wrong i don't give a stuff but logic to this point gives my case weight!
And hey EASE i was refering to the dither comparisson because we have many types of dither available,but although they do the same thing they achieve the outcome in different ways,i was not inferring that dither could have been the problem here in this case,and also you can't tell me that truncation and rounding errors are achieved in exactly the same way in every case all of the time,i just can't swallow that.
here's my philosophical take on the matter. "All other things being equal,then if you hear a difference,you heard a difference(much like confusious and rajneesh saying "where you are! then there you are!).One person might be wrong,but it is unlikely that 50 or so are wrong(we are not dumb enough for that fancy word sythesesia to overcome all of us),even minus the incongruent
setups, that would still leave multiple cases of hearing a difference. The process of elimination up till now demands that you give greater heed to my case.
"Just remember this!" BINARY CODE is synonymous with UNLIMITED.
Remember, Ron keeps telling us about nulling out etc but he's never actually stated that he didn't hear a difference when doing definitive tests,of which after all this time and effort he would have or most certainly could have. So i would like to suggest that Ron would set up all the different Daws that he has,do a project or two or three consisting of entirely one different type of soft synth in each project(meaning only one softsynth per project)and available in the same format(use the vst wrapper for Sonar,and include the same 12 presets per mix and then record to disk without dither and then tell us honestly point blank(he doesn't have to state whether he think's it's worse or better,just if it sounded different or not,and all running out of the same sound card of course! on the same computer,just incase the cpu's are messing with things in their own way,however minor he might think!) and i'm sure we would all love to get the feed back.Iwould say three different softsynths for three different projects would settle it for me. ahem everyone? OK amen! and actually while your there,would you be willing to do the twelve simultaneuos presets and then after recording down try up to three more sounds added one at a time and recorded down after each one is added to see if the imprinting to disk process as i put it ,may be the cause.
"and all for the love of modern music" what a boomer hey!

Steve,

First please note that I am making no personal reference here. If you are making a serious attempt at a point, please accept this as a serious response.

i was not inferring that dither could have been the problem here in this case

Then why mention it at all? In this case, as no dither is involved it is a complete red herring and is only likely to add confusion to the situation.

and also you can't tell me that truncation and rounding errors are achieved in exactly the same way in every case all of the time,i just can't swallow that.

"Just remember this!" BINARY CODE is synonymous with UNLIMITED.

Please read my post again. I agree with your statement. Particularly if machine code is used then the algorithms may vary as they may when different higher level compilers are used. What I said is that, however the function of either rounding or truncation is achieved, the result is very well defined (it is a trivial mathematical process). Whatever algorithm is used the answer will be either right or wrong and is easily tested. The only variation with a correct answer may be the speed of execution. The base of the mathematics be it 10 (decimal) or 2 (binary) is irrelevant to these processes. Binary code neither adds nor subtracts any mystery.

Right or wrong i don't give a stuff but logic to this point gives my case weight!

If you don't give a stuff why bother posting at all? If you read my post again you will see that I agree that there must be something in all of this debate. That does not mean that I agree with the clear errors you have made in various statements. Also as your logic is clearly flawed unfortunately no weight is added at all. This has nothing to do with whether I am pro Sonar or not, nor have I cast any light on whether I have any loyalty or not as I do not believe that constitutes any objective part to the debate.

Although I can see the flaws in your points to Ron Kuper, I will leave it to Ron to respond to them himself in his very capable way.

Finally, as either rounding or truncation will ONLY affect the LSB of the result, have you considered why the timing issues I suggested, causing phase variations in a mix would very easily completely knock truncation into insignificance?

Yes, but I came here for an argument!!
OH! Oh! I'm sorry! This is abuse!
Oh! Oh I see!
Aha! No, you want room 12A, next door.


Damn those Pythons - they have a sketch for everything...

Ron.-

Is it possible that the errors are in Nuendo? - I guess you can't really open the same project in samplitude for instance?

Kind regards

Dave Rich.

ORIGINAL: LixiSoft

(sarcasim on)...You really think Steiney would ship a product with bugs ??

oh yeah,-

of course it'd be ridiculous.

I'm off to play with my crossfades ;)

Kind regards

Dave Rich.

I would say the algorythms used to handle the data to the nulling point is where the difference lie's,and in ADDITION to that,the conversion process to a wav file could quite possibly have a TONNE to do with it.

Ron Replie's/ So you are saying that the 2 mixes could sound different when played back, but then when rendered to a wave, the rendering process could somehow make them sonically equal again? IOW the "better sounding" app produces a better sound when playing back, but then "worsens" the sound when producing a wave say to make a CD master? I don't think so...

Steve austin replie's-No Ron! i'm trying to say exactly the opposite,that when two(i would prefer three to be sure) Daws are playing back the same midi file ON THE SAME COMPUTER(so that idiosyncrocie's of different cpu's and driver hardware interaction etc can be ruled out) then the on the fly mix(meaning the mix hasn't been recorded to disk yet) should sound identical, but then when they are recorded to disk the process of "imprinting them to disk"as i put it, is where the difference's could show up.meaning the rendering process will not make them sonically equal but rather "unequal!"and also i suggested twelve or more presets so that we could get a good variation of sounds happening which will give a better chance of showing up the difference's (however subtle).
So three different Daws play back the same midi file of the same softsynth ON THE SAME COMPUTER,(remebering to repeat this same test for another A/B comparisson, with a different soft synth) again with say twelve different presets then record the mix to disk, add another preset playing back on the fly via midi and then record that to disk along with the main mix(more truncation and rounding errors) and then add another preset playing via midi and then record that one down as well(more truncation and rounding errors),and then repeat the process once more(more truncation and rounding errors) NOTE the word rounding ERRORS which could still be a point of difference between programmers ideas of how the audio should be handled.Then do your A B/ing with THE END RESULTS. Making sure all other things are equal first, of course!

then why have you not been able to pin it down(you've covered all major point's and have effectively negated them from the potential cause)

/ My investigations aren't done yet. I have been drilling down in detail into the exact files that shea was using, and there are differences both sonically and rendered. I think I know what's causing them, but out of respect to shea I am waiting to hear back from him before posting my findings.

-well this almost proves my case... as you just stated,there are differences sonically AND RENDERED(the bold type is for the one's in here who are accusing me of trolling).

Remember, Ron keeps telling us about nulling out etc but he's never actually stated that he didn't hear a difference when doing definitive tests,of which after all this time and effort he would have or most certainly could have.

/ For record: In the tests where the waves nulled out, I heard no difference.

-well i wish i was there to hear it for myself,but remember the nulling out as i've "already stated" in previous posts is obviously not the issue.

/ In the tests where the waves did not null out (the one I am currently working on), I heard no difference.
But I'll be the first to admit I don't have golden ears. That's why I would much rather do analytical comparisons than subjective listening tests.

-I believe analytical tests should go hand in hand with subjective tests,because we all generally know when something sounds better or worse: APART FROM PERSONAL TASTES,some things tend to be obviously better even if it's subtle.

So i would like to suggest that Ron would set up all the different Daws that he has,do a project or two or three consisting of entirely one different type of soft synth in each project(meaning only one softsynth per project)and available in the same format(use the vst wrapper for Sonar,and include the same 12 presets per mix and then record to disk without dither and then tell us honestly point blank

/ I've been doing that. Once I get some free time (pretty busy these days) I'll definitely do much much more.


-I sure you are busy,but from my point of view this test i've described should really only take a couple of hours at most(obviously work that should be done considering the accusations levelled at sonar,and seeing as you seem to have covered most everything else of subsatance then this should resolve it.I hope you do, because the issue of whichever sequencer sounds better(it seems that we need every edge we can get when it comes to the digital domain,even if it's just 10 or 15%,thats the one i'll jump over to.Simple as that,and please feel free to use our laymens terms like, Fat,warmish,too trebly,cold and clinical,thin as crap but natural sounding,deep solid bottom end but muddy midrange with clean nuetral highs blah blah Etc Etc...

The bottom line remains: does sonar sound different from nuendo?

They shouldn't, no matter how much the programmers were paid, regardless of what our intrepid troll Mr. Austin has to say about it. If they do sound different, then one of them is not processing the digital audio correctly, and should be fixed. If there is difference in rounding, it should be, at most, audible only at 141 dB or so below clipping which is at a level comperable to the difference between silence and a chainsaw. And even still, as has been stated before, it hardly requires specialized programming skills to make the numbers round off correctly.

I was, I must confess, one of those who thought Nuendo/Cubase sounded better than Sonar for awhile (in fact, I think my very first post on these forums might have been to exactly that point). Once I tried disabling TrueTape (a steinberg tape emulation effect that is enabled on all tracks by default), the difference disappeared, to my ears.

I hope this can finally be put to bed, one way or t'other.

Cheers.

Somebody in the k-v-r forum just made a negative crack about the Sonar audio engine, without anything to back it up. I hear it occasionally elswhere, too, as if it's some obvious reality that, for some reason, only the blind Sonar faithful fail to hear.

Regardless of the great success Sonar has seen with each successive version, there is still some stigma about the Sonar audio engine. I personally could give a damn, since I believe it comes from ignorance, but there's still some perceptual uphill terrain to cover.

That's why I think, for Cakewalk's sake, the work that Ron is doing is important.

is there still something seriously lacking in the audio engine?

<Obviuos Troll>

Hasn't it already been established that all audio applications running on Windows operating systems are infereior?

</Obviuos Troll>

ORIGINAL: wmountney
The one thing to be careful of before doing the binary comparison is that both waves are the same length, starting and ending at the same point. It may be possible that one program or the other would include a bit of silence at the beginning or end of the wave during mixdown. You may have to trim the beginning or end of one wave or the other to make sure you're comparing the same section of data.

You also have to make sure that the amplitudes of the two files are identical for the fc /b to work. But your idea is a good one, and will at least serve to satisfy those Engineers among us (taken in the broadest sense) who are oriented more from a straight Computer-Science perspective and less from a DSP and/or Analog perspective.

For those who are interested, "nulling" is an old technique. The term originates in things like THD measurements, where you have a critical subtraction of two signals, a reference signal and a response signal. For THD, the reference is a sinewave input to an amp, and the response is the output of the amp. The output will be a sinewave plus error, in this particular case called distortion. To find the relative power of just the distortion (to get at the final %THD figure), you subtract the input from the output. Of course, if it's an amp, the output will be much bigger than the input, so you have to run the output through an attenuator before you subtract them. Since you can't know exactly how much to attenuate due to experimental variance, you have to fine-trim the attenuation until the reference is perfectly cancelled, or "nulled", hence the term.

ORIGINAL: losguy
You also have to make sure that the amplitudes of the two files are identical for the fc /b to work.

True. However, I was thinking along the lines that if the amplitudes weren't the same, that would indicate some difference in the processing of the different DAWs anyway. Given the same input waves and identical level settings in the mix, it would at least indicate that one DAW or the other had innacurate db readings on the faders.