| gatino wrote on Sat, 10 February 2007 02:17 |
can you elaborate on this or point me to info on the advantage of having my projects set to 32/64 bit floating point?
my daw has the option of working in 32/64 bit floating point.
|
the archetecture of a modern cpu is floating point, so it is most efficient for a native cpu to do float calculations and return a float result. thus the internal maths of all native daws is float at this time.
if you can imagine doing the calculation "one divided by three" on a float system... you end up filling the ram with .3333... to infinity... a float system has to stop somewhere; so we cannot say the math is ever "perfect". now i've raised an issue which was significant to early dsp designers... memory... fixed point math co-processors were common in computers 20 years ago because ram was so much more expensive and native cpu was not yet fast enough to play 8 tracks at 16 bit/44.1khz. fixed-point co-processing made the first daws possible. tdm was invented to bring horsepower to systems where a native daw was an impossible proposition.
but nowadays our computers do not bother with math co-processors. so the option to run your session at 32 or 64 bits is about how you will write files.. and of course you want to write the whole signal to a file, not truncate the value and lose data (and this is why i think itb mixes generally sound like itb, not analog...).
so on your system, the only fixed point processes are a/d/a conversion. therefore if you wanted to keep the signal preserved within your system and throughout the chain (which in practice is likely to include bouncing) you would keep it floating from the moment it leaves the converter until it is ready to pass through a converter again.
64 bit float .wav would, in theory be the "safest" bounce/export/freeze formatting option for anyone who's signal is processed on native (floating point) cpu, but i haven't experimented with that file format yet.
| Ashermusic wrote on Sat, 10 February 2007 11:41 |
Well that is what I would have thought also but some pretty high priced talent here, like Terry, seem to feel otherwise.
|
terry is mixing on a fixed point system. regardless of any tdm mixer's internal bit depth, the signal gets squeezed back into 24 bit fixed point format at both the entry and exit points of every plug-in on all tdm systems. red lights anywhere on the mixer mean ugly digital clipping to terry, but not to all of us.
let's say you have 100 tracks and 100 plug-ins. do you have 100 eyes to watch for clipping??!! can you afford to do 100 audiosuite gain reduction processes before you even start mixing? so let me tell you a little secret way to actually get your work done on such a system... that's my opinion of what is going on here.
the light edition of protools, dp and logic all use floating point math but refuse to write float files. so one can't tolerate red lights in the path of anything that might need to be bounced on those systems.
terry, like many daw users, needs to heed the red lights at all times. one way to handle this could be to attenuate the input to each mixer channel.. that would give the same result but not affect tracking, nor the correct practice of
archiving what actually passed the converter.
but terry's daw doesn't have an input trimmer on every channel like cubase and nuendo do; so it wouldn't be so convenient for terry on his
mixing system as it would be for some other engineers to drop the gain after recording as it would be to do it when tracking: before the information is stored to a file. <to toss away recoverable signal data without ever listening to it is imo, so very very wrong!>
i think we need to establish cause and effect here.
i trust that when terry is able to apply scientific method to prove his fascinating but questionable theory, he will.
jeff dinces
Author
Topic: Digital tracking with low levels = better...is this new??? (Read 189848 times)