T2 doesn't sound as good as Nuendo?

[valley]

Is Tracktion really sample-accurate?

Tests I did seemed to suggest that it was.

I'll like to see your results if you found otherwise.

I had some experiences with T1 when trying to cancel out sines. Results would lean towards the completely random.

Are you sure you weren't measuring floating point noise? Adding and subtracting a nuch of sines in FP is not gauranteed to give you silence as rounding errors inherent in FP will give fractionally inaccurate results. The noise should be typically way below the threshold of human hearing, but you probably wont get pure silence.

In SAW studio it would all work as expected though.

SAW is 64bit isn't it? That'll reduce a great deal of FP quantisation noise. Try it in Tracktion with the 64bit mdoe active.

[nuffink]

Valley,
When Robert Randolph did those summing tests many many months ago when he was all over this forum, didn't you also confirm that his tests showed that audio summing in tracktion was 'muddy', or problematic, or clearly audibly different, or some such thing, from other hosts?

Where is he these days anyway, I liked his posts and his...enthusiasm.

Little bobby boy didn't do those tests. He participated, screwed up the samplitude test (despite being a pro ), got laughed at and flounced off.
Sadly missed.

[valley]

Valley,
When Robert Randolph did those summing tests many many months ago when he was all over this forum, didn't you also confirm that his tests showed that audio summing in tracktion was 'muddy', or problematic, or clearly audibly different, or some such thing, from other hosts?

Actually, you can refer to my post above, but to directly answer this:

what his tests showed is that Tracktion and all other 32bit hosts are subject to a degree of floating point innaccuracy (as is anything that uses FP math). Increasing the bit depth of the floating point number helps, which is why with very high track counts, 64bit *will* make a measurable difference.

Robert was arguing that using integers instead of floats would give a cleaner sound, which is argaubly true - however the tradeoff is that you need to pay a great deal of attention to the risk of digital clipping at all points on your signal chain. That's why most hosts use the +1/-1 floating point convetion. It allows you to overload internal busses without worrying about distortion.

[valley]

Little bobby boy didn't do those tests.

I dunno about outside of the T forum, but he did some tests inside of the Tracktion forum, that his described test methods seemed valid.

[semiquaver]

" Each time the cancellation was in the order of -150dB. "

wonder what accounted for that remainder? - dither or error... was it noise or just a bright "ghost" of the mix?

Anyhow what ever it was, it was well below the 16 bit noise floor for CD!

[Tracktion-Drey]

I own Adobe Audition, Sony Vegas, and Tracktion. I tested the summing of all 3 apps and found them identical. Vegas mixes did have a higher noise floor but I soon discovered it was how the program interacted with my audio card drivers. When I switched to ASIO the noisefloor dropped and all 3 mixes were identical and all nulled against each other.

No eq, effects, gain changes, or dither was applied to the tracks. As I posted before, I have dumped Audition and Vegas and now only use Tracktion because the sound quality is superb, and I prefer the user interface.

My take on the 32-bit and 64-bit summing is that it won't "sound" different if you're tracking to digital properly (i.e., record with peaks anywhere between -20dBfs and -12dBfs). 32-bit summing will handle lots of tracks recorded this way without sonic penalty. However, if you're the type that likes to record peaks just shy of full scale -- which many people do -- the 64-bit summing may produce better results. Test for yourself and form your own opinion.

[valley]

wonder what accounted for that remainder?

See my posts above.

In integer math if you add 2 to 2 you will always end up with 4. In FP, adding n to n may produce a number that is +/- x of 2n - where x is a very small number indeed.

[semiquaver]

I would guess that the floating point issue has some merit. I read an article that showed that filters in particular can work wierdly in fp, particularly if they sweep. The author advocated a 48 fixed integer scheme for greatest fidelity.

But that article was written before 64 bit fp...

If you want ultimate fidelity the next step is DSD which T5 will support I am sure...

[headquest]

"In this business, we don't care what a program says it does, we care about how it sounds - and let me tell you, Sonar 4 sounds great. One example that I'm absolutely floored woth is the MPEX Time Scaling for correcting vocal tracks. It's as if the vocalist just nailed the take, you can't hear the processing and I couldn't find any artefacts."

See, that I'll take on face value as an opinion. Time scaling *can* be done in many different ways, and different algorithms give different results. I dunno whether MPEX sounds better or worse than any other half-decent time stretch code, and I'm sure depending on the type of material in question your mileage will vary with all of them. At least in this case though, this isn't a straight claim that adding 24 FPs together and diving by 24 will give you different answers depending on how much you spent on the software.

Yep, I agree with you entirely valley. (I've not used Sonar myself, except a little playing with the demo). The point I was thinking of by adding the quote (in a Nuendo/Cubase vs. Tracktion thread) is that most people will defend their choice of software... it's not just folk here, but even top record producers act that way!

I agree with you about his MPEX example too - that is something concrete that is distinct from summing... but which obviously affects the overal sound quality (probably much more than summing, in fact!).

Interesting that a pro producer singles out the timestretch/pitchshifting, of course... but that's another story, well told elsewhere

[nuffink]

I would guess that the floating point issue has some merit. I read an article that showed that filters in particular can work wierdly in fp, particularly if they sweep. The author advocated a 48 fixed integer scheme for greatest fidelity.

But that article was written before 64 bit fp...

That would be this somewhat notorious white paper...
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf

It gets quoted every time this argument comes up. Lets have a look at the author's own conclusions...

Conclusions:
The first observation is that digital filtering when we allow the user to select high-Q, very low-frequency
filters is difficult at the best of times. Even 64-bit floating point can produce significant error energy if the
best filter forms are not used. Even for floating point, it is important to use forms that have normalized state
variables so that imbalances in the state values do not lead to further degradation of the precision of the
result. Clearly, the performance of 32-bit floating point and 24-bit integer will be considerably inferior to
that of 64-bit floating point, so we might conclude that it is not possible to achieve high-quality results for
these extreme filter settings. Furthermore it is shown that sweeping the settings of a filter with time excites
some aberrant behavior when the state variables are not normalized, even with 64-bit floating-point
arithmetic. 48-bit integer is proposed as a compromise between economic realizability and ultimate
precision. The increased headroom and guard bits allowed by the format provide enough precision to allow
some extreme filter settings and still preserve a 24-bit result after several stages of processing.

For those of you who don't speak dsp let me paraphrase.

Optimised 48bit fixed algo's are superior to badly constructed 32bit float algo's in this very specific application.

I've never managed to find any corroboration for fixed points superiority yet, somehow, the myth lives on.

[voidar]

Is Tracktion really sample-accurate?

Tests I did seemed to suggest that it was.

I'll like to see your results if you found otherwise.

I had some experiences with T1 when trying to cancel out sines. Results would lean towards the completely random.

Are you sure you weren't measuring floating point noise? Adding and subtracting a nuch of sines in FP is not gauranteed to give you silence as rounding errors inherent in FP will give fractionally inaccurate results. The noise should be typically way below the threshold of human hearing, but you probably wont get pure silence.

In SAW studio it would all work as expected though.

SAW is 64bit isn't it? That'll reduce a great deal of FP quantisation noise. Try it in Tracktion with the 64bit mdoe active.

SAW is double-precision 24 bit integer/fixed. Which means it is 24 bit integer, but each number is stored twice and compared for precision, I believe.

You might have given a clue to the cause of this behavour when taking into count the inaccuracies of float numbers.
Anyway, in my test I would actually hear the sines not cancelling each-other out. Volume was perhaps droped to half. I don't remember each detail, so it would be great if someone would do a project with a test showing it works.

What I did:

1. created some repetitions of a 1000Hz sine in WaveLab.

2. created multiple copies of the original file, paired.

3. loaded the files into Tracktion.

4. destructively reversed each-other file in Tracktion using it's primitive editing capabilities -This could have been an error by my side, but I also tried using non-reversed files with the phase-inverter of the ToolsOne plugin.

5. enabled clip-looping and lined the clips up so that each one would be loaded progressively - I wanted to first hear the sine, then have it cancelled out by its "enemy", then a new sine would come into the summing etc. I took some time making sure the clip-seams lined up correctly, but I could have gotten this wrong.

Well, things wasn't exactly perfect.

In SAW I basically did the same thing, only I used the built in mixers phase-inv.

[semiquaver]

double precision does not mean stored twice - it means stored in two adjacent memory locations ie twice as many bytes.

[voidar]

I own Adobe Audition, Sony Vegas, and Tracktion. I tested the summing of all 3 apps and found them identical. Vegas mixes did have a higher noise floor but I soon discovered it was how the program interacted with my audio card drivers. When I switched to ASIO the noisefloor dropped and all 3 mixes were identical and all nulled against each other.

No eq, effects, gain changes, or dither was applied to the tracks. As I posted before, I have dumped Audition and Vegas and now only use Tracktion because the sound quality is superb, and I prefer the user interface.

My take on the 32-bit and 64-bit summing is that it won't "sound" different if you're tracking to digital properly (i.e., record with peaks anywhere between -20dBfs and -12dBfs). 32-bit summing will handle lots of tracks recorded this way without sonic penalty. However, if you're the type that likes to record peaks just shy of full scale -- which many people do -- the 64-bit summing may produce better results. Test for yourself and form your own opinion.

32/64-bit mixing has nothing to do with tracking, but summing. 64-bit summing should translate to clearer mixes when summing many tracks.

[voidar]

double precision does not mean stored twice - it means stored in two adjacent memory locations ie twice as many bytes.

Which results in a accumulated 48-bit word lenght?

[semiquaver]

Hi Voldar - could you post you edit? I just tried loading an arbitrary audio clip in T - shift dragging it to the next track and used Ts eq flat with the phase invert button and presto it nulled perfectly so *something* must have gone wrong in your edit!

What Tracktion-Drey was saying was that samples that peak out at lower levels can be summed more succesfully in a 32 bit buss which may well be right (I need to think about it!)

a detail to remember is that, if I'm not mistaken the VST standard maxes out at 32 bits....