Audio Engine Test - Live Versus Pro Tools Versus Logic

[3phase]

users reports logic and Pt are tighter and more accurate relating compensation. i cannot confirm as i don't own logic or pt, but i wouldn't be surprised most might prefer logic or pt sound cause of this.

After a first blind hearing I also tend to b (Logic) for a slightly pleasing sound in this test scenario (a little more "Glued" together - Hello 3phase - and thicker.)
Pro-Tools and live are sounding very similar in my ears (as invol stated, Live seems to be a very very little more transparent but therefore a very very little more colder - but this also might due to the wrong level of the crash in Live -see later this post).
Very interesting is the fact that the drums cancel out very good between Pro-Tools and Live (except the crash - one reason is that it is mixed 2 dB louder in Live - as we also can see in the screenshots). But if you try to cancel Pro-Tools or Live with Logic, then they are phasing in a modulated manner. Seems that machine did not run very tight inside Logic. Also in Logic the first basedrum is faded and (as dorsch has stated) the rhodes is late at the first time it comes in (or also faded). I think Logic tries to switch on the plug-ins only when they are needed to prevent consuming to much cpu power (unfortunately not very accurate).
Conclusion: If you want a "Logic Style" sound try to use Lives Groove Engine with random timing values above 0%.

edit: if you have time for a second test, i would love to see a PDC comparaison between the 3 daws.

Think about that (the very new) Pro-Tools LE version 9 is the first LE version which features plug-in delay compensation in general.

cheers, palmer

logic has indeed a problem with the internal clock distribution to the plug ins..there live is better..

In logic you need a tempo that is has an even numbered denominator with the samplerate to achive results live has over the entire tempo range.. so 125 bpm on 44,1 k would make the timing correct...

But as said earlier.. tests with plug ins as sound sources are not relevant here because there is no plug in yet that gives an as complex sound as a simple analog synth or even an acoustical instrument over an expensiv mic and pre..

thats total bullshit to use digital shredder signals ..and all on odbfs.. do all the test files on analog levels.. -18dbfs

that could be even good for live because it likes to clip internaly much earlier than the meters suggest


And regarding protools.. a real protools system should be the refference here.. especially to have a refference that uses 48 bit fix point arithmetic that is supposed to sound better ..and see how good the 32 bit float competition holds up to that.

I wouldnt expect digidesign to try to overpower their own hardware systems.. they rather have the in the box versions for mobile editing and tracking but not necessarily to make their hardware systems obsolete in the mixdown.. so i wouldnt expect them to want the best sounding 32 bit float software out there.. but who knows.

and regarding this

(a little more "Glued" together - Hello 3phase - and thicker.)

there is no normation for subjektive terms that describe differences in sound..

but you have to see that in a correct conducted test there shouldnt be any difference.. as soon there are some differences some participants must do it better or worse than the others...

[fx23]

it's interesting you speak about correlation of tempo to samplerate
ive noticed that few daws tend to drifts when tempi arent plain numbers of 'blocs'.

the smaller operation precision is often of buffersize rather than sample size wich ar intepoled, therefore there are some 'magic tempis' that fit an entire nb of blocs, otherwise rounding occurs, and with big blocs such as 128 samples this can be fairly noticeable.

ive discovered that my drift ceased when i used those tempi i computed.
and only with those @ 128s 44k, the smaller buffer is, more choice
but with a bloc of 128, there is very few tempi:
323 bpm
161.5
107.67
80.75

@32 there are much much more
184.57 161.5 143.55 129.2 117.45 107.67 99.38 92.29 86.13 80.75 76.00 71.78 68.00 64.60 61.52 58.73 56.17 53.83 ..

then if searching only bar precision there are more inter-choices
but these are the only tempi that will never round in a bloc based daw

[3phase]

it's interesting you speak about correlation of tempo to samplerate
ive noticed that few daws tend to drifts when tempi arent plain numbers of 'blocs'.

the smaller operation precision is often of buffersize rather than sample size wich ar intepoled, therefore there are some 'magic tempis' that fit an entire nb of blocs, otherwise rounding occurs, and with big blocs such as 128 samples this can be fairly noticeable.

ive discovered that my drift ceased when i used those tempi i computed.
and only with those @ 128s 44k, the smaller buffer is, more choice
but with a bloc of 128, there is very few tempi:
323 bpm
161.5
107.67
80.75

@32 there are much much more
184.57 161.5 143.55 129.2 117.45 107.67 99.38 92.29 86.13 80.75 76.00 71.78 68.00 64.60 61.52 58.73 56.17 53.83 ..

then if searching only bar precision there are more inter-choices
but these are the only tempi that will never round in a bloc based daw

depends how much precission you need.. internal midiclocking of plug ins in ableton is within a +/- one sample window..that is as good as it can get.. when you experiance a drift it must be related to the 3rd party plugs.. possible that the buffer plays a role here but i guess its rather something for a bug report than trying to get around it with calculations...

[fx23]

all i know is internal midi clocking of plugin in ableton don't report latency, so even if it had a samplerate
presicison (wich i highly doubt) it's anyway not accurate in a predicable manner.

as soon as you drop a latency plug infront of another vst, it's midi timing clock is out of reference grid.

it's not a bug, it's a flaw, they are aware of that

[Palmer Eldritch]

that could be even good for live because it likes to clip internaly much earlier than the meters suggest

Could not confirm
Internal bus overhead in live (8) is about 70dB (about 12bit)
Please describe a test scenario where you examine this behavior.

cheers palmer

[3phase]

that could be even good for live because it likes to clip internaly much earlier than the meters suggest

Could not confirm
Internal bus overhead in live (8) is about 70dB (about 12bit)
Please describe a test scenario where you examine this behavior.

cheers palmer

there is no indication of intersample peaks..when you connect a meter that shows them you will realize that an all green bargraph dont means absolutly no clippings.. you need to have at least 2 db´s saftey

[Khazul]

And regarding protools.. a real protools system should be the refference here.. especially to have a refference that uses 48 bit fix point arithmetic that is supposed to sound better ..and see how good the 32 bit float competition holds up to that.

IIRC Pro tools is 24 bit data paths, but plugins operate at 48 bit, but outputs are dithered back down to 24 bit between each. Mixer section is entirely 48 bit fixed point however. Only full scale signals will ever use the full 24/48 bits, most considerably less.

[henke]

that could be even good for live because it likes to clip internaly much earlier than the meters suggest

Could not confirm
Internal bus overhead in live (8) is about 70dB (about 12bit)
Please describe a test scenario where you examine this behavior.

cheers palmer

thanx palmer, it's good to hear a rational voice here.
there is indeed no internal clipping in Live; it's all floating point. Only the sends clip deliberately at +18dB when feedback to themselves.

Robert

[henke]

And regarding protools.. a real protools system should be the refference here.. especially to have a refference that uses 48 bit fix point arithmetic that is supposed to sound better ..and see how good the 32 bit float competition holds up to that.

IIRC Pro tools is 24 bit data paths, but plugins operate at 48 bit, but outputs are dithered back down to 24 bit between each. Mixer section is entirely 48 bit fixed point however. Only full scale signals will ever use the full 24/48 bits, most considerably less.

thanx for clarifying.
Robert

[henke]

that could be even good for live because it likes to clip internaly much earlier than the meters suggest

Could not confirm
Internal bus overhead in live (8) is about 70dB (about 12bit)
Please describe a test scenario where you examine this behavior.

cheers palmer

there is no indication of intersample peaks..when you connect a meter that shows them you will realize that an all green bargraph dont means absolutly no clippings.. you need to have at least 2 db´s saftey

nonsense.

[Khazul]

there is no indication of intersample peaks..when you connect a meter that shows them you will realize that an all green bargraph dont means absolutly no clippings.. you need to have at least 2 db´s saftey

Do any of them do this?

If you want to be sure, then only way is an oversampling limiter and/or oversampling meters that specifically attempt analog reconstruction.

As for 2dB - whats the hell are you feeding it that means you have to leave 2dB? Even when driving a good limiter (that doesnt feature ISP detection) hard I find -0.3dB is sufficient to be absolutely sure an MP3 wont distort on anything I can check it on.

Anyway - not entirely sure that Logic or PT are the best overall processing quality reference to aim for (ie everything including all aspects of timing) - Cubase/Nuendo?

[3phase]

there is no indication of intersample peaks..when you connect a meter that shows them you will realize that an all green bargraph dont means absolutly no clippings.. you need to have at least 2 db´s saftey

Do any of them do this?

If you want to be sure, then only way is an oversampling limiter and/or oversampling meters that specifically attempt analog reconstruction.

As for 2dB - whats the hell are you feeding it that means you have to leave 2dB? Even when driving a good limiter (that doesnt feature ISP detection) hard I find -0.3dB is sufficient to be absolutely sure an MP3 wont distort on anything I can check it on.

Anyway - not entirely sure that Logic or PT are the best overall processing quality reference to aim for (ie everything including all aspects of timing) - Cubase/Nuendo?

after getting with the level down arund 1,5 db the intersample peak readings were gone.. a friend pointed me to this intersample peak phenomen after i had clippigs in recordings i hve send to him..
Of cause this intersample peaks are program related.. however,, other daw´s meter dont read this intersample peaks aswell..i just booked them for live because in earlier years i never came along the problem. In any case it shouldnt hurt to leave some headroom.
www.tcelectronic.com/.../lund_2004_distortion_tmt20.pdf -


regarding the protools 48 bit.. of cause its just the internal bit width and the output gets dithred down to 24 bits..

and with live we have 32 bit float without any dithering... right? so what happens when we listen to this output with 24 bid DA converters?

[3phase]

there is no indication of intersample peaks..when you connect a meter that shows them you will realize that an all green bargraph dont means absolutly no clippings.. you need to have at least 2 db´s saftey

nonsense.

as long this is the only nonsense...

[Palmer Eldritch]

And no renderings are allowed to take place.. we dont want to know how good a daw renders.. we want to know how good it sounds.

Luckily I have a Jazz (Big Band) recording with 20 tracks on my harddisk. I rendered a part of it as A 32 bit file (44.1k). After that I loaded that rendered track in Quicktime and checked the rendered track against Lives summed output.
Result: I could not hear any difference but I could cancel them out completely (- infinit dB).

Conclusion: What you here is what you get -> Absolutely no difference between rendered files and the summed output of Live.

[3phase]

And no renderings are allowed to take place.. we dont want to know how good a daw renders.. we want to know how good it sounds.

Luckily I have a Jazz (Big Band) recording with 20 tracks on my harddisk. I rendered a part of it as A 32 bit file (44.1k). After that I loaded that rendered track in Quicktime and checked the rendered track against Lives summed output.
Result: I could not hear any difference but I could cancel them out completely (- infinit dB).

Conclusion: What you here is what you get -> Absolutely no difference between rendered files and the summed output of Live.

thats good to know... thats the way it should be... but i guess you know that a null test dont says too much because the artefacts the can effekt the sound badly might be unaudible on normal listenig levels..

however the main problem with lives sound is the unpredictable samplerate conversion that seems to kick in when it wants..not only when its supposed to be on..At least that is the best explanation for the degenerated sound quality you get with live ..usually after longer workruns in finalizing states of projekts..


is it possible that samplrate converson kicks in once you have changed track delay? that there is no consitant quality in lives output is defently not promissing.. as it seems restarting the whole computer can help once the so called brown henke dither appeard.. but when are you supposed to do that..only when you realize that the sound got degenerated?.or after any take? or after any change to the speed or offset delays? after importing external files?

what is the supposed mode of operation here to avoid brown henke dither apearances?