thunderkyss
Max Output Level: -66 dBFS
- Total Posts : 1207
- Joined: 2003/11/12 12:10:59
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 15:53:12
(permalink)
ORIGINAL: Rednroll
Rednroll - you're the one making the bone head soup. Why don't you just cave in and get Sonar - you know you want it! We're talking about overshoots in the digital realm prior to getting sent out to a 24bit sound card. Adobe Audition does this also - when I do a clip repair the peaks can be way past 0dbfs until I lower the gain or normalize it back to below 0dbfs. Sound Forge probably does this too. You manage your 0dbfs however you like - they're ain't nothing distorting over here!
So you're saying 0dbFS isn't exactly full scale?? that your meters are actually calibrated to +3dbFS, but scaled to show 0dbFS as Full Scale?? Did they teach this stuff in High School??
post edited by thunderkyss - 2005/09/20 21:48:51
|
kylen
Max Output Level: -79 dBFS
- Total Posts : 578
- Joined: 2003/11/25 19:30:06
- Location: Southern WV, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 18:30:44
(permalink)
ORIGINAL: thunderkyss
So you're saying 0dbFS isn't exactly full scale?? that your meters are actually calibrated to +3dbFS, but scaled to show 0dbFS as Full Scale??
Did they teach this stuff in High School??
Very funny, you don;t want to know what they taught me in high school...  We're just saying that you get extra headroom in the FX buss - yes it can be past 0dbfs while it's inside a plug or FX buss. Try it yourself in Audition or in Sonar4. Put an instance of GlissEQ followed by rmsbuddy followed by another GlissEQ. Pump the 1st GlissEQ output past +8dbfs for example, note that rms buddy shows this, decrease the gain on the 2nd GlissEQ to -8db (before it hits your soundcard). No distortion or clipping because of the headroom in the FX buss - that's what we're talking about. Now report back here when you've finished your homework!
|
DonM
Max Output Level: -34 dBFS
- Total Posts : 4129
- Joined: 2004/04/26 12:23:12
- Location: Pittsburgh
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 18:52:00
(permalink)
Correct me if I am wrong here - but headroom is not about how loud you can go but how my usable dynamic range is available from soft to loud - and - higher wordlenghts allow for more bits to represent lower amplitudes - and therefore quantization noise is dramatically reduced in softer sections - soft to loud representing dynamic range - more meaningul than 'headroom' isn't it? In another way of looking at it - if you had an alterntive band that played full bore on 'eleven' with no dynamics at all - you could probably capture that performance in 8 bits since there is no dynamic range at all needed to represent that very narrow (albeit LOUD) performance. Dynamic Range - rather than headroom is best reflected in the softest passages being represented by enough bits to eliminiate quantization noise - eh? -D
post edited by DonM - 2005/09/20 18:59:15
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 19:55:53
(permalink)
Good point, Tarsier. The sign bit counts -- it is carrying totally valid/needed data. Whew, what a relief! I'd shudder to think that we only had 53 bits of mantissa resolution and not 54! <grin>
Good data about the 32-bit float -- I hadn't looked that up. So with S4 we basically have 25 bits of quantization over the dynamic range in the mix bus, with over double that for the 64-bit engine in S5.
I don't know how much of a difference it will really make, but it sure seems cool. As others have pointed out, the 32-bit float has a pretty wide range already - the big gain will be the added precision of intermediate mantissas.
-lee-
|
prog_head
Max Output Level: -82 dBFS
- Total Posts : 411
- Joined: 2003/11/07 01:36:14
- Location: Colorado
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 20:04:12
(permalink)
Dynamic Range - rather than headroom is best reflected in the softest passages being represented by enough bits to eliminiate quantization noise - eh? Not really. A dynamic range of 120db says that there will be a 120db difference between the noise and the loudest passage. Anything above 120db is totally ridiculous since 0db is unattainable for most people and 120db is unbearable by most people so, theoretically for human beings, 120db is more than enough. If dividing 120db into 64bits you will get much finer resolution 'between' each db but this is not dynamic range. Wikipedia has some good explanations: The following is a quote, "Audio engineers often use dynamic range to describe the ratio of the loudest possible relatively-undistorted sound to the quietest or to the noise level".
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 20:11:14
(permalink)
ORIGINAL: DonM
Correct me if I am wrong here - but headroom is not about how loud you can go but how my usable dynamic range is available from soft to loud - and - higher wordlenghts allow for more bits to represent lower amplitudes - and therefore quantization noise is dramatically reduced in softer sections - soft to loud representing dynamic range - more meaningul than 'headroom' isn't it?
In another way of looking at it - if you had an alterntive band that played full bore on 'eleven' with no dynamics at all - you could probably capture that performance in 8 bits since there is no dynamic range at all needed to represent that very narrow (albeit LOUD) performance.
Dynamic Range - rather than headroom is best reflected in the softest passages being represented by enough bits to eliminiate quantization noise - eh?
-D
Close, Don, but I'd say it a different way. Headroom, dynamic range, loudness and quantization are all important, related and different. Headroom refers to the ability to have intermediate values during processing that are not distorted. Because of the Sonar architecture, you can go louder while processing than you can when you output the signal without distortion, as long as you bring it back down into the right range before you output it to the sound device. Dynamic range refers to the ability to represent a set of volume levels, and is also used to discuss the range of levels used in a particular piece. This is why it is confusing. People talk about a device having a certain "dynamic range" because it can produce a range from one level to another. People also talk about music having a dynamic range, referring to the amplitude variations of different digital samples. Quantization refers to the size of the chunks you split the signal into. For example, you can represent a 1 volt signal using 256 discrete levels (8-bit), or you can split the exact same signal up finer using 65536 levels (16-bit). Loudness refers to how you scale the output. You can turn the amplifier after the output sound device up very loud or keep it turned way down. This is seperate from the raw output magnitude. Perceived loudness can be a whole 'nother can of worms -- we hear things more loudly when there is a smaller dynamic range in music and the average level of the music has been increased (typically through compression). -lee-
|
DonM
Max Output Level: -34 dBFS
- Total Posts : 4129
- Joined: 2004/04/26 12:23:12
- Location: Pittsburgh
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 20:22:07
(permalink)
Lee: Again - precise as a #11 X-acto blade. I do get confused with the term headroom in digital audio - because full scale is still really just full scale regardless of the wordlength right? If that's the case. Is digital headroom 32bit levels represented in 24 bit or 16 bit meters? -D
post edited by DonM - 2005/09/20 20:29:05
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 20:35:58
(permalink)
ORIGINAL: DonM
I do get confused with the term headroom in digital audio - because full scale is still really just full scale regardless of the wordlength right? Ahhhh - Now I may see the dilemma. No, not exactly. Let me walk through some hypothetical steps to see if I can make it clear as mud <grin>. Lets say you record some music using 24-bit samples. Because music is "signed" (goes above and below zero, where zero is a critical point for making good clean edits), the possible values go from about -8 million to +8 million. As you record it, you set your levels with amazing perfection, so that the loudest sample fills the entire available number space. Now lets do some processing. But before you process it, you transfer the data into a 32-bit integer format *without scaling it*. The new format can handle numbers from about - 2 billion to + 2 billion. It is able to completely represent the original numbers without any loss. You have added 8 bits of "headroom". If you add two of such signals together, the max value is 16 million, which is still well within the range of the 32-bit number. You can now do a bunch of processing and adding, etc., without every running into the limits of your number range. In musical terms, the extra range is headroom. After processing, lets say that you want this music to play on a 16-bit CD. You now need to rescale the 32-bit number range down to what can be represented in 16-bit. This is basically done by dividing. It gets more complicated than that, in that it turns out that adding special spectral shaping noise or "dither" helps it sound better, but basically you are just taking this bigger number space and shrinking it down to what the CD player can handle. Always remember, you are not recording music, you are simply recording a LONG BIG string of numbers! <grin> -lee-
post edited by LaptopPop - 2005/09/20 20:43:34
|
VariousArtist
Max Output Level: -63 dBFS
- Total Posts : 1397
- Joined: 2003/11/07 15:03:09
- Location: London, UK & California, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 20:57:14
(permalink)
prog_head
<snip>
Most of the best eqs already use 64bit processing because the accuracy of the calculations is so much better. Imagine I take a sample that is currently the equivalent of 1000 (this would be 1000/2^24) coming from your soundcard. When doing eqs and panning this number could be modified over time with many fractional numbers. Imagine, divide 1000 by 2.735 and then multply by 7.6 and then divide by 3.123 and so on. This is the type of calculation going over and over and over and... anyhow... The number would end up something like 889.78335531449451231969447649421. Okay, that is a ridiculous mantissa but you get the idea.
As more calculations happen (eq's, efx, panning, faders, summing, etc) The accuracy will come into play more and more. In the end it all gets converted back to a 24bit integer for output by your soundcard but all of this could have a major
effect on which integer value will get output.
<snip>
If anyone wants to get a feel for the real numbers behind the mathematics of this subject, try something seemingly unrelated on your pocket calculator: Enter the number 2 and hit the "square root" button over and over, say about 20 times. Now hit the "square" button over and over an equal number of times (in this case 20 times). (if you don't have a "square" button, then simply hit the multiplication button followed by "=" over and over) On paper you would expect to end up with the number you started with, i.e. the number 2. But your pocket calculator has limited precision and most likely you'll end up with a number less than 2. So each successive calculation can result in lost information, and you can imagine what this does in the audio world since the same issue concerning "limited precision" applies to computers and all of our digital audio tools. Having a larger number of bits helps preserve more of that data so we don't lose much precision and, at some point, the loss is so small as to be imperceptible to many/most/all. Another positive outcome of "more bits" can be viewed in the folowing way. Let's say your calculator can only display an 8-digit number. Now suppose you're summing a bunch of numbers where the total is less than 8-digits -- then you'd expect to see that total number in the display. But what if the intermediate running total exceeded those 8 digits? You'd not get the right result .... unless the calculator was capable of working internally with a larger intermediate number. And in fact, this is indeed the case with many calculators. Sometimes it's easier to conceptualize these things outside of the realms of digital audio, since the same principals apply. I hope this helps someone who is having difficulty with the idea of having a greater number of bits for some internal calculations in our digital audio software than can be usefully used at the final output stage. The extra bits helps with those inner calculations such that we don't realize the limitations that would occur if we restricted the number of bits to match our outboard gear, etc.
|
DonM
Max Output Level: -34 dBFS
- Total Posts : 4129
- Joined: 2004/04/26 12:23:12
- Location: Pittsburgh
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 21:03:41
(permalink)
Lee: With everyone of your posts I get another clearer view of what's actually happening. - Great example BTW of the signed -8m and +8m moving into a 32bit floating space - I suspect the *without scaling * part means don't represent the coverage of the amplitude in the 32 bit space the same as the 24 bit space - or 'perfectly adjusting the levels to fill the bits' right. So here are some of my concerns based on the increase in my understanding. #1 Plug-ins must behave very very well to prevent damaging the audio (math) is this correct? #2 In-the-Box and Out-of-the-Box Summing debate may end if: A. Playback gear for consumers exceeds current redbook limits B. Rescaling audio becomes unnecessary Lee: one last question - what do go scaring me further with this: (Aside: There's not really any such thing as a 24-bit converter. The best converters out there produce about 20 bits of actual data, formatted into a 24-bit word). What's that about? -D
post edited by DonM - 2005/09/20 21:16:30
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 21:31:08
(permalink)
ORIGINAL: DonM
With everyone of your posts I get another clearer view of what's actually happening. - Great example BTW of the signed -8m and +8m moving into a 32bit floating space - I suspect the *without scaling * part means don't represent the coverage of the amplitude in the 32 bit space the same as the 24 bit space - or 'perfectly adjusting the levels to fill the bits' right.
Right! You get the ability to deal with a wider range because you've moved into a bigger space without scaling the numbers so that you have filled all the bits. Because you've moved from a smaller space into a bigger one, you don't lose any resolution. At the end of the project, when you go to CD quality/16-bit you lose some resolution. This is why you should do this only once, at the very end of the project.
So here are some of my concerns based on the increase in my understanding.
#1 Plug-ins must behave very very well to prevent damaging the audio (math) is this correct?
ABSOLUTELY!!! This is why good plugins sound good and are hard to make.
#2 In-the-Box and Out-of-the-Box Summing debate may end if:
A. Playback gear for consumers exceeds current redbook limits
B. Rescaling audio becomes unnecessary
Actually, that's a whole different topic. Summing in the digital world is just multiplying and adding. Summing in the "real" world (analog) requires other techniques, such as resistor networks or op amps or..... Analog hardware produces a sound that is very pleasing to the ear. Some folks say that it is actually because it is distorting the signal (adding an even harmonic), but it is different for different pieces of gear, and the debate is not likely to go away for a looooooong time.
Lee: one last question - what do go scaring me further with this:
(Aside: There's not really any such thing as a 24-bit converter. The best converters out there produce about 20 bits of actual data, formatted into a 24-bit word).
What's that about?
Sorry, I probably should not have put that in. Theoretically, every "bit" gives you 6dB of dynamic range. 24 bits should give you 144 dB of dynamic range. However, we live in the real world, and we are working with small voltages and real-world equipment. Such equipment has things like thermal noise in the resistors, etc. Yes, they are at teeeeeeeny little levels, but that's what we are dealing with. For example, look at some of the world's best converters - the Benchmark ADC1. This conversion box will set you back $1775. for a TWO channel conversion box at Sweetwater.com. It is among the best in the world. The honest specs on this box describe its dynamic range as "greater than 120dB". That would be about 20 bits worth. Yes, the converters put out a 24-bit digital string of numbers after conversion, but because of real-world issues, the true accuracy is a bit over 20-bits. BUT!!! Bottom line - don't worry about it. There's nothing anyone can do about it, and it doesn't make a big difference. -lee-
post edited by LaptopPop - 2005/09/20 21:46:21
|
kylen
Max Output Level: -79 dBFS
- Total Posts : 578
- Joined: 2003/11/25 19:30:06
- Location: Southern WV, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 21:47:45
(permalink)
Yeah - It's like when you go to the hardware store and they sell you a 2x4 - only when you get home and measure it...
|
thunderkyss
Max Output Level: -66 dBFS
- Total Posts : 1207
- Joined: 2003/11/12 12:10:59
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 22:11:56
(permalink)
ORIGINAL: kylen
ORIGINAL: thunderkyss
So you're saying 0dbFS isn't exactly full scale?? that your meters are actually calibrated to +3dbFS, but scaled to show 0dbFS as Full Scale??
Did they teach this stuff in High School??
Very funny, you don;t want to know what they taught me in high school...
We're just saying that you get extra headroom in the FX buss - yes it can be past 0dbfs while it's inside a plug or FX buss. Try it yourself in Audition or in Sonar4. Put an instance of GlissEQ followed by rmsbuddy followed by another GlissEQ. Pump the 1st GlissEQ output past +8dbfs for example, note that rms buddy shows this, decrease the gain on the 2nd GlissEQ to -8db (before it hits your soundcard). No distortion or clipping because of the headroom in the FX buss - that's what we're talking about. Now report back here when you've finished your homework!
Definitely not trying to be funny. Just not understanding the conversation...... I didn't get any of this in HighSchool, and I feel like it's a little beyond the 12th grade level. Again, not trying to be funny, just asking you to keep the words small. 
|
kylen
Max Output Level: -79 dBFS
- Total Posts : 578
- Joined: 2003/11/25 19:30:06
- Location: Southern WV, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 22:51:13
(permalink)
ORIGINAL: thunderkyss
Definitely not trying to be funny. Just not understanding the conversation......
I didn't get any of this in HighSchool, and I feel like it's a little beyond the 12th grade level.
Again, not trying to be funny, just asking you to keep the words small.
hehe - I was getting a pretty cool visual about DSP High and all the little bits & bytes running around playing bitball and the cheerleaders...well!  I don't do the math - I'm just trying out different experiments and trying to hear stuff and reading ahead a chapter or 2 in my Bob Katz book. Besides all the internals though life is no good without understanding gain management whether it's during recording or during mixdown regardless of bit depth, resolution, float, fixed, integer otherwise. Many of us that work in the garage or otherwise do home recording are more likeley to hear a misplaced eq setting in our project studios more than we'll hear what 64bit float will do. But all the interfaces still have to play nicely so we'll learn over time... I'm in that camp fer sure! I imagine after we get 32bit float native exports happening we'll be seeing a few "my audio is distorted, what happened?" threads. So I'll watch and learn - mostly to pay attention to the red metering lights I think! 
|
tarsier
Max Output Level: -45 dBFS
- Total Posts : 3029
- Joined: 2003/11/07 11:51:35
- Location: 6 feet under
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 23:02:15
(permalink)
ORIGINAL: prog_head
Not really. A dynamic range of 120db says that there will be a 120db difference between the noise and the loudest passage. Anything above 120db is totally ridiculous since 0db is unattainable for most people and 120db is unbearable by most people so, theoretically for human beings, 120db is more than enough.
Yep, it really is. Something like 90 dB is more reasonable. That way we'd only need 16 bits to get perfect sound forever.
|
Rednroll
Max Output Level: -80 dBFS
- Total Posts : 537
- Joined: 2004/09/17 13:31:13
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 23:12:50
(permalink)
Pump the 1st GlissEQ output past +8dbfs for example, note that rms buddy shows this, decrease the gain on the 2nd GlissEQ to -8db (before it hits your soundcard). No distortion or clipping because of the headroom in the FX buss - that's what we're talking about. Now report back here when you've finished your homework! I'ld have to say you need to do your homework. What you're explaining is how things would work when using fixed point math. In floating point math it is common for DAW developers to use the total gain stages in doing the calculation feeding the stage right before the master bus that then feeds your D/A converter. So in your example they take [+8dBFS -8dBFS]=0dBFS, thus this is why you don't hear distortion. The entire gain stage path is looked at as 1 complete equation instead of several individual equations. I'll put you on your way how it really works. Here's a link to a discussion in the Sony forums that myself and one of the developers had regarding this exact same thing that you outlined. http://www.sonymediasoftware.com/forums/ShowMessage.asp?ForumID=19&MessageID=368667
|
kylen
Max Output Level: -79 dBFS
- Total Posts : 578
- Joined: 2003/11/25 19:30:06
- Location: Southern WV, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 23:25:48
(permalink)
You didn't try it - that's ok. When are you going to buy Sonar?
|
Rednroll
Max Output Level: -80 dBFS
- Total Posts : 537
- Joined: 2004/09/17 13:31:13
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 23:43:33
(permalink)
I've tried it....I've tried it in Vegas, Sonar 4 and Sound Forge. If you read the link I just posted it shows that I've tried it in Vegas and explained how it really works. SonyPCH is the lead audio developer on Vegas and Acid, he also adds to the conversation and tells where it makes a difference. Sonar 5 doesn't go to "11+" because as I previously mentioned you still have to deal with the outside world of D/A converters and file formats when saving to your HD. As you see SonyPCH mentions if you have a floating point math D/A converter, then you have a chance of going over 0dBFS....So do you have a D/A converter that also goes to 11? Tell me where to buy one, I'm interested in getting one too. When are you going to buy Sonar? Got Sonar 4 PE a couple weeks ago at a local music store clearing off their shelves. Got it for a great deal since S5 was announced.
post edited by Rednroll - 2005/09/21 00:02:30
|
Rednroll
Max Output Level: -80 dBFS
- Total Posts : 537
- Joined: 2004/09/17 13:31:13
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 23:53:37
(permalink)
In the digital world, one dirty little secret is that there is no standard for converting signals. If you take the exact same input signal and apply it to two different interfaces, they will be similar, but not exactly the same. For example, if I run the same signal through my MOTU 24i/o interface and the firewire interface on my 1640 mixer, I get two different outputs, because the engineers have scaled the analog signal differently to fit it into the 24-bit space. This isn't correct either. A major part of why you get 2 different things is due to different "interpolation" algorithms used in D/A converters. Do some research on "D/A Interpolation" and get back to me. Why does one 24 bit D/A converter sound better than another? A big part of that is due to the "interpolation" algorithm used in that D/A converter. Interpolation can be summarized this way. Let's say you have 2 consecutive samples. They are spaced apart from each other, because it is not a continous signal like analog is. So let's say you have Sample A, and Sample B. What happens inbetween these samples? Well that's what "interpolation" does, it fills in those gaps between the samples when converting from D to A. The only dirty little secrets is one developers Interpolation method compared to anothers.
post edited by Rednroll - 2005/09/21 00:04:50
|
kylen
Max Output Level: -79 dBFS
- Total Posts : 578
- Joined: 2003/11/25 19:30:06
- Location: Southern WV, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/20 23:58:18
(permalink)
ORIGINAL: Rednroll
Sonar 5 doesn't go to "11+" because as I previously mentioned you still have to deal with the outside world of D/A converters and file formats when saving to your HD.
I read your post - you're quite the angry distortion demon, haha. I'm the opposite - I don't clip the busses for effect but I've had mixes where other folks have done it - both on purpose and not. As far as the 11+ thing - I'm not talking about the outside world - I'm talking about internal to the FX buss where Sonar and Audition goes well past 11.
Got Sonar 4 PE a couple weeks ago at a local music store clearing off their shelves. Got it for a great deal since S5 was announced.
Well good then, you've been on the fence for a while - enjoy!
post edited by kylen - 2005/09/21 00:05:50
|
kylen
Max Output Level: -79 dBFS
- Total Posts : 578
- Joined: 2003/11/25 19:30:06
- Location: Southern WV, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 01:12:48
(permalink)
Just a minor detail concerning the internal FX and summing busses test using GlissEQ I mentioned...recently GlissEQ came out with an overs indicator and clipper so you can see when you're clipping past 0dbfs while in the FX buss - it will also clip the audio for you - which isn't what [some of us] want! haha, I haven't done this in a while so to run my test now I had to switch over to Sonitus EQ and boost it up to +18db or so. Neither the FX buss or the summing buss clip even though they glow very red...you do have to attenuate the level (using another instance of Sonitus EQ as a master insert set to -18db) before entering the outside world as RednRoll and others have mentioned.
I was just appreciating the advantages of the extra headroom on the internal busses - that's all!
|
DonM
Max Output Level: -34 dBFS
- Total Posts : 4129
- Joined: 2004/04/26 12:23:12
- Location: Pittsburgh
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 08:15:02
(permalink)
Lee et al: During a total re-read of the post (in the context of my original question "returning 64 bit processing to a non-64 bit project) - I first quote Lee: Headroom refers to the ability to have intermediate values during processing that are not distorted. Because of the Sonar architecture, you can go louder while processing than you can when you output the signal without distortion, as long as you bring it back down into the right range before you output it to the sound device. So I think I might be able to understant the (any) answer now - but will my bounces/freezes/sums be redhot from the headroom in the processing side, and will my projects suffer from dithering death? thanks in advance -D
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 08:26:58
(permalink)
Rednroll,
I think we may be agreeing more than disagreeing in some ways. I'm not saying that the new architecture will change the physical characteristics of the output converters, or any file format. Certainly the signal must be appropriately scaled as a last step before sending it to a smaller bit depth.
What the new mix engine will do is two things. First it will allow greater internal overhead during calculations. Yes, if you have a chain of amplitude variations, such as a channel gain, then channel fader, then bus fader, then master fader, these calculations can be folded into a single multiply. Things quickly get messy if you insert plugin effects into the chain that the DAW does not directly control. In such instances the new engine will allow much higher intermediate values before any internal clipping.
Second, the new mix engine will provide much better accuracy. When you do digital divides, for example, on a small signal, you are reducing the number of bits of the signal. If you then multiply the signal, you have issues of increased granularity. The new mix engine will help to alleviate much of this.
Its all about the intermediate values -- not the final output values. If you clip in the middle of the chain, you're just as hosed as if you clip on the end.
I understand about interpolation algorithms, but that's not what I was referring to in terms of analog to digital conversion. There is no objective standard for how a converter "should" translate the analog domain into the digital domain. For the same voltage, you can have significantly different digital outputs. For example, my MOTU converters run digital full scale such that about +3dB is full scale (fills all the bits). My Mackie converters run full scale such that about +12dB is digital full scale. Its no big thing, and easy to adjust for, but each converter is different. The Mackie is much more conservative because its built into a mixer and I guess Mackie is expecting live performances/mixing to have greater chances of major dynamics causing clipping.
-lee-
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 08:34:11
(permalink)
ORIGINAL: DonM
So I think I might be able to understant the (any) answer now - but will my bounces/freezes/sums be redhot from the headroom in the processing side, and will my projects suffer from dithering death? Ahhhhh, there's a couple of other issues (as always <grin>). First, it is not clear what the program will be doing in terms of freezes. I don't know what format they will be stored in. I would hope full 64-bit dpfp, but I don't know. Second, bounces are likely to be limited to 32-bit FP at max. However, as long as your signal is scaled with any level of reasonable care at all, it should fit into 32-bit FP without any significant changes or degradation at all. As always, you will need to make sure your final gain stage scales/compresses the signal appropriately for the output media, for example poor ol' 16-bit CD format. As long as you fit into that range, the final conversion, including dithering, should be fine. The thing you want to avoid is trips from 64 to 16 to 64 to 16 to 64.... One trip, at the end, 64 to 16 and life should be great. Save your work such that if you need to make future changes you go back and work on the 64-bit version. -lee-
|
tarsier
Max Output Level: -45 dBFS
- Total Posts : 3029
- Joined: 2003/11/07 11:51:35
- Location: 6 feet under
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 09:54:20
(permalink)
ORIGINAL: DonM
So I think I might be able to understant the (any) answer now - but will my bounces/freezes/sums be redhot from the headroom in the processing side, and will my projects suffer from dithering death?
Going by the rule that you should dither whenever reducing the bit depth, there should probably be dither applied when going from 64 float to 32 float. I've only done testing when going from 32 float to 24 integer that shows that you should dither when doing that, but unfortunately I don't have any 64 float tools yet to run proper tests. Sonar (as of version 4.0 anyway) doesn't apply dither when going to 24 bit integer format. I'm curious to see if that's changed in v5. Now, even if you don't dither when going from 64 float to 32 float (or even 32 float to 24 int) the distortion you get by not dithering is way down in the inaudible range. That's why some people say you don't need to dither at those levels. My take is that at those low levels, you choose from either inaudible dither noise, or inaudible distortion noise. Take your pick. As far as redhot bounces etc. I daresay you won't notice any difference at all. Just use v5 like you used v4, only with greater joy and satisfaction due to all the neat new features in it. And don't bemoan too much all the features you need that they left out.
|
Rednroll
Max Output Level: -80 dBFS
- Total Posts : 537
- Joined: 2004/09/17 13:31:13
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 10:05:16
(permalink)
Second, the new mix engine will provide much better accuracy. When you do digital divides, for example, on a small signal, you are reducing the number of bits of the signal. If you then multiply the signal, you have issues of increased granularity. The new mix engine will help to alleviate much of this. Why is that? You've already have gained this using floating point math in Sonar 4. I even made light of this in my example from the Sony post. With fixed point math when you reduce gain of your audio signal anywhere within the signal processing, it would reduce the bit debt that you where working with at the next processing stage. I even gave an example of where I wanted to achieve this type of bit reduction sound, but I am unable to because of the floating point math maintained the bit resolution throughout the signal path. So what you are saying is untrue, in S4 if it uses 32bit floating point math, it was using a 32bit bit debt throughout the processing stages, regardless if you lowered the gain at one stage and then raised it at another. Use my examples that I posted that I did in Sound Forge. If you have Sound Forge then I recommend you try my steps for yourself, since there is a way to disable the floating point math that I also outlined and then you can do the same steps to the signal and hear the differences. Basically, what I did in Sound Forge is that I took a 0dB 16 bit Sinewave. I reduced the gain -58dB. From this point what you're saying is that I lost bit debt...that's NOT what happened....that's actually what I was trying to achieve. So then in the next step I normalized that now reduced signal to 0dB peak. So what you're saying is that now it increased granularity......that's NOT what happened. What happened is that I got back exactly what I started with. That is because Sound Forge uses a 32bit floating point temp file. To get what you described I had to disable "Use 32 float temp file" in the Sound Forge preferences. So now after I did the -58 dB gain reduction it was forced to save that process into a fixed point temporary file....and NOW I got bit reduction. Again, what you're describing is what happens in 'Fixed point' math calculations. What you gain in Sonar 5 with 64 bit float processing over Sonar 4's 32 bit float processing is that you reduced the amount of "imaging". "Imaging" is a form of distortion.
post edited by Rednroll - 2005/09/21 10:21:38
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 11:34:06
(permalink)
ORIGINAL: Rednroll
Again, what you're describing is what happens in 'Fixed point' math calculations. Very good point -- you're absolutely right. With floating point calculations, you do not get the same bit depth reduction. It will be interesting to hear just what kind of differences there are between 32-bit fp versus 64-bit fp. I suspect for mixes staged with reasonable gains, etc., the differences will be darn slight. The 64-bit may well be more "forgiving" allowing "sloppier" mixing. It has about 10X the available range, and over 2x the mantissa resolution -- but what will we hear? I do expect there to be some advantages to the new format -- but I am VERY curious to see how much it affects the sound. Of course, one must never underestimate the placebo effect. If someone has paid $ for an "upgrade" they have a predisposition to say it sounds better/works better. I expect the same will happen with Sonar V5. I haven't looked at the CPU cycles of the most modern CPUs, but I suspect this hasn't changed. In the earlier Pentiums it could actually take longer to do a 32-bit FP multiply than a 64-bit one. The hardware always did 64-bit multiplies, so for 32-bit multiplies it actually converted to 64-bit, did the multiply, then converted back. This may be part of why Cakewalk seems to be feeling fine about the performance of the new mix engine. They have to move more bits, but they may actually use the CPU more efficiently. -lee-
|
DonM
Max Output Level: -34 dBFS
- Total Posts : 4129
- Joined: 2004/04/26 12:23:12
- Location: Pittsburgh
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 11:47:55
(permalink)
Lee:
Very interesting about the efficiency of 64 vs 32 in the Intel architecture. How can we confirm that do you think?
-D
|
LaptopPop
Max Output Level: -73 dBFS
- Total Posts : 853
- Joined: 2003/11/05 19:37:17
- Location: Long Beach, CA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/21 12:14:32
(permalink)
ORIGINAL: DonM
Very interesting about the efficiency of 64 vs 32 in the Intel architecture. How can we confirm that do you think?
OK, I just went to the Intel website and spent some time spelunking through various technical docs regarding the Pentium instruction set and optimization. What it looks like the processors are doing these days is loading ALL floating point calculations into 80-bit registers, and doing the processing there. I don't see any references about a difference in conversion times for 32-bit to 80-bit versus 64-bit to 80-bit. However, what is interesting is that because of this, there is no difference in time required for multiplying a floating point number, regardless of bit depth. In other words, there is no penalty for using 64-bit numbers, except it requires more data to flow to and from memory through the caches. -lee-
|
VariousArtist
Max Output Level: -63 dBFS
- Total Posts : 1397
- Joined: 2003/11/07 15:03:09
- Location: London, UK & California, USA
- Status: offline
RE: RonK: 64 bit Plug-ins and Summing
2005/09/22 13:54:20
(permalink)
VariousArtist:
If anyone wants to get a feel for the real numbers behind the mathematics of this subject, try something seemingly unrelated on your pocket calculator:
Enter the number 2 and hit the "square root" button over and over, say about 20 times.
Now hit the "square" button over and over an equal number of times (in this case 20 times).
(if you don't have a "square" button, then simply hit the multiplication button followed by "=" over and over)
On paper you would expect to end up with the number you started with, i.e. the number 2.
But your pocket calculator has limited precision and most likely you'll end up with a number less than 2.
So each successive calculation can result in lost information, and you can imagine what this does in the audio world since the same issue concerning "limited precision" applies to computers and all of our digital audio tools. Having a larger number of bits helps preserve more of that data so we don't lose much precision and, at some point, the loss is so small as to be imperceptible to many/most/all.
Another positive outcome of "more bits" can be viewed in the folowing way. Let's say your calculator can only display an 8-digit number. Now suppose you're summing a bunch of numbers where the total is less than 8-digits -- then you'd expect to see that total number in the display. But what if the intermediate running total exceeded those 8 digits? You'd not get the right result .... unless the calculator was capable of working internally with a larger intermediate number. And in fact, this is indeed the case with many calculators.
Sometimes it's easier to conceptualize these things outside of the realms of digital audio, since the same principals apply. I hope this helps someone who is having difficulty with the idea of having a greater number of bits for some internal calculations in our digital audio software than can be usefully used at the final output stage. The extra bits helps with those inner calculations such that we don't realize the limitations that would occur if we restricted the number of bits to match our outboard gear, etc. Just a follow-up.... There's an interesting, technically-oriented paper on this topic ( click here) The following quote from this also refers to using a calculator: "One motivation for extended precision comes from calculators, which will often display 10 digits, but use 13 digits internally. By displaying only 10 of the 13 digits, the calculator appears to the user as a "black box" that computes exponentials, cosines, etc. to 10 digits of accuracy. For the calculator to compute functions like exp, log and cos to within 10 digits with reasonable efficiency, it needs a few extra digits to work with. It is not hard to find a simple rational expression that approximates log with an error of 500 units in the last place. Thus computing with 13 digits gives an answer correct to 10 digits. By keeping these extra 3 digits hidden, the calculator presents a simple model to the operator. "
|