A compendium on SR and bit depth - Ableton's sound quality

[supamonsta]

Yes is is what I mean.

But I'm totally unable to really explain why it is so in real scientific or clue-full manner

I have passed lots of times last days reading about Live's audio quality in different places (most here and gearslutz), and the most interesting thing I found was this point.

I have read that live's realtime processing engine, as it is programmed to realtime handling of all stuff (audio, sync, routings, plugs, ...), does in fact "color" the sound a bit (not saying that was a bad sound ), and that's with this "colored" sound that you are dealing when composing and "mixdowning", that you actually listen to on your monitors.
So if you can work on a great mixdown within live, it would be better accurate to RECORD it than to RENDER it because the render engine is free from the realtime live stuff and so may render a different sounding audio at the end, that the one you were actually hearing while computed realtime...

But another time : I can't PROVE this, I just find this really interesting, and I feel it may be an intelligent way of thinking it : RECORD what you HEAR, not what you "WROTE" (in the sequences, automations, plugs, etc.),

I have no clue if this is really accurate, maybe Robert could state on this

Cheers



EDIT:

Vitamin, I listened to your files in the beyerdynamics DT770pro, and I'm totally UNABLE to hear a single difference between them

so

1) My ears are inaccurate, so I could pass on and keep on working without worrying about that stuff (in fact I really could, even with "accurate" ears, because at my level all this is not really important, but like you I'm perfectionnist )
2) My headphones are inaccurate
3) all files are MP3s 320K (thought you'd do 128?) and that may erase/minimise any difference?
4) The differences that such different workflows and file formats induce may be so minimal that it would not make any difference at the auditioning level, but rather maybe important for the pro mastering level...

I'm not at all an engineer, nor am I really wise in terms of audio technique. But I'm still interested in how to avoid manipulations that could degrade the final sound of my compositions.

Cheers

[tw1nstates]

Andrejs[/quote]


haven't looked at it precisely, but i know that export does it with a single core, while realtime does use multiple cores. there are differences between those two modes (documented in the .. documentation).

but i don't know if this is actually hearable.[/quote]


that's why rendering and freezing are so bloody slow in live. . .

I hope they change that in the next version

[locojohn]

haven't looked at it precisely, but i know that export does it with a single core, while realtime does use multiple cores. there are differences between those two modes (documented in the .. documentation).

but i don't know if this is actually hearable.

that's why rendering and freezing are so bloody slow in live. . .

I hope they change that in the next version

I created a test Ableton live set (24-bit/96khz) where I loaded three 24-bit/96khz audio samples generated with Amadeus Pro audio editor on 3 Live channels:

1 Audio: whitenoise-24-96.wav (whitenoise sample)
2 Audio: sine-24-96.wav (sinewave modulation sample)
3 Audio: complex-24-96.wav (complex modulation sample)

I created two more audio channels and called them "recorded" and "rendered". I grouped them into a single "Group".
Then I set outputs for channels containing samples to "recorded" channel so I could record them all on a single channel. I recorded them within the arrangement with no fades and then copied the resulting clip to the "recorded" channel. Then I rendered all three channels on the Master to 24-bit/96khz WAV file with no dither and no normalize, and loaded it to "rendered" channel (first clip). Then I set up Utility with "Invert Phase" preset on the "recorded" channel and played the group. Rendered and Recorded channels perfectly cancel each other out.

However, when rendering at 32-bit/96khz, they do not cancel each other out so I was wondering if the gearslut people or whoever did the test compared 32-bit rendered file with 24-bit recorded file?

Note that Warp mode is off for all tracks.

Summary: it seems to me that playback/recording summing is at project's bit rate, while rendering is at bit rate that you intentionally specify when exporting/rendering audio to disk.

Comments are welcome and sorry about my clumsy English.

Andrejs

[davepermen]

now do some summing in different apps and do the comparison ^^

great work btw.


one thing to consider: do more than one track, and some effects on each to create actual processor load so that it does multiprocessing. and then test if it still cancels each other out.

[locojohn]

now do some summing in different apps and do the comparison ^^

great work btw.


one thing to consider: do more than one track, and some effects on each to create actual processor load so that it does multiprocessing. and then test if it still cancels each other out.

I really don't think there will be a difference. As long as Project's sample rate/bit depth and rendering/export audio sample rate/bit depth are the same, there is no difference no matter how many effects you use and no matter number of channels, as long as the result isn't clipping. I really do not think the number of cores involved in mixing audio affects sound quality. If you have time at your disposal, you can take my test live set and play around with it by yourself however you like to verify whether my conclusion stays valid for more complex sets. Note, however, that some effects can be programmed to affect audio signal in a random way each time you run it through them. Otherwise, recording and rendering must be done at the same time, which isn't possible.

And my conclusion is:

R = 96000 (sample rate)
B = 24 (bit rate)

Rendering (R/B) = Recording (R/B)

Best regards,

Andrejs

[anybody human]

I just have to say this. Finally there are some constructive, technical points being discussed here. Please don't muddy the waters with the same old crap. How about this? Just a thought, maybe it won't work or isn't appropriate but here goes; THIS IS AN ISSUE FOR A TON OF PEOPLE. IF YOU THINK LIVE SOUNDS PERFECT THEN DON'T REPLY TO THE THREAD BECAUSE IT DOESN'T AFFECT YOU.

These are usually threads wondering about or pointing out criticism of Live's sound quality. Not invitations to rip someone a new one. I get it, the forum regulars are offended. Now let people who are concerned about this issue discuss it in peace. I don't know enough to say either way. I will be bouncing tracks out to mix down for one simple reason; because every professional, professor, and friend I've ever met mixes down outside of Live. If that offends you, don't worry about it. Keep doing what you're doing. Whatever works for you is cool. GIVE UP THIS JIHAD against people who wonder about a widespread concern, you've made your point again and again. If you just want to flail away at the injustice of it all, please don't. If you can add constructively to someone's understanding or offer information then by all means contribute, otherwise move along.

[supamonsta]

I just have to say this. Finally there are some constructive, technical points being discussed here

agree, but wanna say this present topic has been interesting and troll-free from the first post (just 1 or 2 misreadings, quickly wiped out).

it IS really interesting.

but:

Please don't muddy the waters with the same old crap. How about this? Just a thought, maybe it won't work or isn't appropriate but here goes; THIS IS AN ISSUE FOR A TON OF PEOPLE. IF YOU THINK LIVE SOUNDS PERFECT THEN DON'T REPLY TO THE THREAD BECAUSE IT DOESN'T AFFECT YOU.

These are usually threads wondering about or pointing out criticism of Live's sound quality. Not invitations to rip someone a new one. I get it, the forum regulars are offended. Now let people who are concerned about this issue discuss it in peace. I don't know enough to say either way. I will be bouncing tracks out to mix down for one simple reason; because every professional, professor, and friend I've ever met mixes down outside of Live. If that offends you, don't worry about it. Keep doing what you're doing. Whatever works for you is cool. GIVE UP THIS JIHAD against people who wonder about a widespread concern, you've made your point again and again. If you just want to flail away at the injustice of it all, please don't. If you can add constructively to someone's understanding or offer information then by all means contribute, otherwise move along.

Who are you arguing against? Everybody here, at least in this present topic, is interested by those questions.
Don't bring back the war you are saying you don't want to happen here again, please

[oblique strategies]

haven't looked at it precisely, but i know that export does it with a single core, while realtime does use multiple cores. there are differences between those two modes (documented in the .. documentation).

Where in the documentation is this info regarding single/multicore in relation to exporting & realtime playback?

I'm not finding it.

[kb420]

Great work locojohn. I would think that Live in that respect is working exactly how you would want it to work. The recording/playback summing should be at the projects bit rate, while export is what ever you want. Sonar has more export options than Live in that you can export mp3's, but both programs let you choose you sample rate, bit depth, and dithering options (which really do make a difference) on export and that's the way it should be.


Once again, well done!!!!

[davepermen]

haven't looked at it precisely, but i know that export does it with a single core, while realtime does use multiple cores. there are differences between those two modes (documented in the .. documentation).

Where in the documentation is this info regarding single/multicore in relation to exporting & realtime playback?

I'm not finding it.

don't find it myself. i guess it got discussed then during the live 8 beta or so, somewhere in the forum? unsure right now.. i really thought it's in the docu.. but it isn't.

[davepermen]

one topic found here:

Hi,

you're right, exporting currently uses one core only. We hope to improve this in the future but it is out of scope for Live 8.

I will discuss with our documentation writer how we can best include more information about the whole topic.

Best, Friedemann

http://forum.ableton.com/viewtopic.php? ... 0&start=15

[supamonsta]

Thanks Locojohn

don't apologize your english is well written and perfectly listenable to (mine may be much much worse )

So I understand that my statement was perfectly wrong, if rendering at the same B/R as the liveset's, then there is NO difference in the resulting audio?

so this has nothing to do with Live's realtime vs rendering.

Thanks again

cheers

[locojohn]

So I understand that my statement was perfectly wrong, if rendering at the same B/R as the liveset's, then there is NO difference in the resulting audio?

so this has nothing to do with Live's realtime vs rendering.

Seems like it, my friend.

Andrejs

[ze2be]

Great Andrejs. We should get this confirmed by the abes and sticky it. Would save a lot of confusion.

[oblique strategies]

haven't looked at it precisely, but i know that export does it with a single core, while realtime does use multiple cores. there are differences between those two modes (documented in the .. documentation).

Where in the documentation is this info regarding single/multicore in relation to exporting & realtime playback?

I'm not finding it.

don't find it myself. i guess it got discussed then during the live 8 beta or so, somewhere in the forum? unsure right now.. i really thought it's in the docu.. but it isn't.

Thanks for the follow up.