Questions RE default 32 bit rendering bit depth

Can't you just always render / export projects to 32 bit . . . then, afterwards dither down to 16 bit for CD, or 24 bit for online streaming, depending on where you are planning on having them played ?

Thank you Noynekker and Bitflipper.
 
There is obviously a lot I don't understand about bit rate. Bitflipper, you said that it makes no difference if I render at 32 bit, that I am just adding zeros. So why don't I just render in 24 bit and keep my files smaller? (I assume 32 bit files are larger than 24?)

Thanks BenMMus
 
So, as my audio interface (RME Fireface 800) is only officially 24 bit it makes no sense to record anything going through it at 32 bit, because it will still be a 24 bit recording. But for processing effects, 32 bit or higher will achieve a better result?
 
Here’s the grey area for me: it seems that the place for changing the default bit rate of your projects is in the ‘Record Bit Depth’ box (Preferences > Audio Data > Record Bit Depth). But doesn’t this setting only affect the recording of an audio clip – and doesn’t apply to MIDI recording, or to the bit depth of anything you render, or to the final mixdown/export process?
 
Question: does the ‘Render Bit Depth’ setting (Preferences > Audio Data > Render Bit Depth) also affect the final ‘Export Audio’ process? (In other words, does the Export Audio process come under the heading of Rendering, affected by the Render Bit Depth setting?) Or is it only the settings in the Export Audio window that apply in this process? For example, if I have a project with a bunch of plugins that have not been rendered yet on audio tracks, and a bunch of virtual instrument MIDI tracks that have not been bounced to audio yet, and I have my Render Bit Depth at 64 bit and I export the project, am I effectively getting a 64 bit rendered file as a result? Or do the settings in the Export Audio window take over at this point?

gswitz
I don't agree that the least significant bit doesn't matter. When i make a file with only the least significant bit from a 24 bit wave and normalize, i can identify the song.

There are good reasons for using 32-bit data, having to do with sinking rounding errors down into the noise floor and not letting them accumulate to the point of audibility. But I'm not talking about signal processing, but rather rendering, in response to the original question. Once exported as a final product, human ears are incapable of differentiating between 24- and 32-bit data.
 
Not that I doubt your hearing acuity, Geoff. You're younger than me, so there's no question you hear better than I do. However, I think I can make the case that no human can hear the difference between rendered files at 24 vs. 32 bits.
 
Look at it this way...whatever differences exist between a 24-bit file and its 32-bit equivalent lie below -144 decibels. The full range of human hearing is only ~120 dB. Now, if you were a barn owl, you actually could hear something 14 dB below the threshold of (human) hearing, e.g. a mouse walking half a mile away. But you couldn't record that even with the best microphone on the planet, and even if you could you wouldn't be able to hear it.
 
The lowest known sound level ever achieved is -14 dBSPL (in an anechoic chamber at Microsoft). You'd have to install a jet engine in that chamber to realize a 144 dB range. If you were then able to pick out a mosquito buzzing 10 ft away - while the engine was running - then I'd believe you can hear what's happening at -144 dB and below.

Yes. "Render" just means to save a fully-processed track or mix, whether by bouncing, freezing or exporting.

What Bit, and many of his era (sorry Bit) don't understand is, you're trying to keep the audio at the highest quality throughout the process. And in this day and era, there is no reason not to switch the 64bitfp on and leave it. And furthermore, there isn't any reason not to bounce out a 64bitfp master file that can be used to create 24bit masters - I wouldn't use 16 bit and don't - to create Mp3s that could be considered hi resolution because no dither and because the 64bitfp file hasn't gone through one reduction before being reduced again via Mp3. And Soundcloud accepts 64bit96k files. Mp3 has no bit depth limit. Yes we all listen with 16 but converters, most these days would listen with 24 bit because most new phones have 24bit, but it's all about resolution and not losing resolution. I think what happens is, if again you process audio files heavily or rely on the analogue emulation aesthetic - if say you bounced down to a 16 bit master file and then created an Mp3 or uploaded to SoundCloud - rather than hear the subtle nuances of emulated 2nd and 3rd harmonic distortion...it just becomes distortion. And it's the same at 24bit and whilst not as bad at 32 bit...you still hear distortion. All I can describe it as is, if you listen very carefully and headphones is there's a grainy mid frequency sound that you can't get rid of.

Look. The oldies around this forum, and I'm sorry Bit because I know you're a good guy who had helped many on this forum since I've been around on this forum, but the oldies are living in the past and worse holding western art music back. There is no need for a studio, a band or 1000s of dollars of equipment. And here is where the proof is, in regards to 64 bit fp...everything. I use Notion 6, which is a score editor and orchestral instrument. I used to stick with Bit's rules...or if you like the general rules of 24bit audio. I would bounce out the files as 24bit and then a few years ago 32 bit. I would then sit and add console emulation and some tape sat as well. It's one of the steps you take to make a wooden robotic sampled violin and smooth it over to add back some realism. The issue was, for the life of me I couldn't understand where the mid range tinny distortion was coming from. It ruined my mixed. Last year, and I can't remember why...I started recording those same Notion instruments into Sonar as 64bitfp via rewire. Gone was the distortion. Enough said.

Now yep, we're talking about master files, but think about it? All your processing is done at either 32bitfp or 64bitfp, depending on what switch you've pressed. What happens to all that processing at 64bitfp, when you bounce down to 24bit or 16bit...it gets squashed into the noise floor and dither is added. Now granted, 24 bit wave files should be the defacto format today, but if you're only using this file as your listening master file...then it will be fine. You lose some very subtle nuances of the 64bit file, but until fp DA converters come on line...its the best we can do. Now the problem is, and I said it above, but the problem is if you what to turn that 24bit file into an MP3 or a Soundcloud or indeed the master is going to be used in an MP4 for YouFool. Because you're squashing a file that has already been squashed. I can't remember if it's on Soundclouds do's and don'ts list but I read and only again recently - its recomend when you create a file for Soundcloud that's it's not heavily processed. Why? Because all the verbs, delays and emulation effects sound distorted. I always wondered why my mixes sounded so horrible after I uploaded to Soundcloud. Yes, in the past I might have been a crap mixer, not anymore...but it's because we're only just starting to work out the digital medium and format, and a lot of the ideas Bit and others on this forum are from the bad old days of digital. Where Bit was 100 percent on the money.

For proof, my website is 1331.space. I'm about to put my last AV sonata I completed last week up.

Ben

Bitflipper, thanks so much for answering my question.

bitflipper

...in this day and era, there is no reason not to switch the 64bitfp on and leave it...

There are 10 kinds of people in the world...

lol

I think the rules are different for what happens outside the box compared to what happens inside the box. If you record an acoustic guitar at 44.1 kHz with 24 bits of resolution and play it back, then it will be 24 bits no matter what. And, the sample rate won't matter because nothing can interfere with the clock frequency. But when you start processing, or creating sounds inside the box, that's when sample rates and resolution can become significant factors. 
 
 

drewfx1
What people who don't understand technical details don't understand is that you can't increase resolution by changing something that isn't limiting resolution in the first place.
 

I can read the technical stuff Drew - I had to to pass my first degree, and what you're missing is the notion of rounding errors. It's so boring the technical stuff, and I already do everything - from writing to creating 3d animation - but the issue is pretty simple...as Craig has stated it's about processing audio within the box. To create the same sounds as analog - you have to process the audio heavily. Think of it this way: analogue on the way into the storage medium i.e. tape adds all the things we like in regards to classic recordings, but analog tape is a poor storage medium and prone to being very expensive. Digital on the other hand, when we can perfect things like storing data in synthetic DNA and also synthetic diamonds (off the top of my head), is the perfect storage medium because it adds nothing to the data. The issue is, it's taken if we go back to the original 70s digital recordings almost 45 years to get to the point where we go ah ha and we can fix it - this is the analogue emulation aesthetic, but as we all know it doesn't work if you use only 24bit processing and hence 32bit and finally 64bitfp processing. This is because, I think rounding errors that eventually become sharp mid distortion.
 
I mentioned this in my last post in regards to Notion audio files and processing - I could not fix the mid-distortion until I went to 64bitfp. I'm not saying you can listen to a 64bit file, that would be ridiculous - what I am saying is you need to keep the master at 64bitfp and from there you create a whatever master file. The OP question was about rendering to 32bitfp, and here is where all of you are doing everyone on this board, who doesn't use a studio and expensive museum pieces to create - because I can tell you there is a huge difference in audio quality if you create an MP3 from a 16 bit file instead of a 64bit file, which includes most sites like Soundcloud. Don't ask me why, but I can tell you my ears can hear the difference. It's the same if you create MP4s or AVis or whatever visual standard too...you need to create the final visual product with a 64bit file. Itunes also uses a 32bitfp process to create Ifools files. Now, I only have one piece of evidence in regards to this matter, but why risk any kind of distortion by giving Crapple a 16 bit file for conversion or indeed a 24 bit one, if Crapple are only going to re-wrap the 24bit file in a 32bit container file?...and that's what you're also missing! You, and others keep rattling on about you can't hear a higher bit depth file...you can't! But you can protect the processed file from rounding errors which turn into distortion by sticking with 64bitfp until distribution. By all means, create 24bit audio wave files for audio masters, which is what I do, but make a 64bitfp master too, which is undithered for future proofing. I can tell you that the 24 bit file doesn't sound as good as the MP4 AV file I create from the 64bit master, because for one dither. And think about it, when you're squashing your track into a smaller format - when squashing the file it should be pretty obvious which file should be used. Mp3 encoders and the like aren't that good at picking which date to remove...so why squash a file that has already been squashed?
 
Finally, to say that if you can't hear something means it doesn't exist - and I'm sorry but I'm going to metaphorically kick you here - is stupid. It's like saying that I can't see sound waves or light waves or the ****ing sun - so the sun or sound and light waves don't exist. You might as well join the loony flat earthers. 
 
For anyone wanting proof to my crazy ideas on sound, just go to my website 1331.space and to the music AV page. I can't get that 'pro' sound without my crazy theories, ones that I've taken 18 years to perfect.
 
Peace and Love :)          

BenMMusTech

drewfx1
What people who don't understand technical details don't understand is that you can't increase resolution by changing something that isn't limiting resolution in the first place.
 

I can read the technical stuff Drew - I had to to pass my first degree, and what you're missing is the notion of rounding errors.

No Ben.
 
What you're missing is the notion of how errors do and don't accumulate. And how errors buried tens of dB under the noise floor can't just magically rise above it.
 
What bit depth is needed for a given process is based on the noise floor and the number of calculations being done on the same data. Simple as that.
 
Except it's not simple because most people tend not to know either of those things for the perfectly understandable reason that they aren't readily available. One can get the noise floor from not entirely trivial measurements, but the only way to understand the calculations is unfortunately to have some knowledge of DSP programming.

drewfx1

Anderton
I think the rules are different for what happens outside the box compared to what happens inside the box. If you record an acoustic guitar at 44.1 kHz with 24 bits of resolution and play it back, then it will be 24 bits no matter what. 

 
Technically speaking, though the recording itself will be 24 bits, the actual resolution will depend on the playback level and the noise from all sources present - including the noise in the signal picked up by the mic when the recording was made. The limits of hearing could also apply if they weren't buried under the noise floor from everything else. IOW 24 bit is the theoretical limit of that particular digital format, not the real world resolution (which is always far less than 24 bits).

 
I know that, but those 24 bits still contain information, even if it's just noise or zeroes. I think the world has standardized on saying converters have 24-bit resolution if technically, they're capable of it because there's no way of knowing the extent to which that resolution will be compromised in a final product. So I would differentiate between useable and theoretical resolution.
 

The problem for us here is that one needs to know some complicated DSP stuff to know when a given bit depth/sample rate might be really significant, completely irrelevant or somewhere in between.

 
I find the really significant ones are audible and obvious. For example, rendering a non-oversampling virtual instrument pulse wave at 44.1 or 192 kHz is such a huge difference you might as well be listening to a different patch altogether. I did a test file and sent it around to some people with whom I'd discussed high sample rates at some recent conferences. They were truly blown away at the difference, it's not even remotely subtle. However most of the time it doesn't matter. With one amp sim, rendering at 96 kHz didn't change the tone because the amps were oversampled, but the reverb's imaging was different compared to 44.1 kHz. Go figure.
 
I think there's still a lot we don't know about digital audio and human perception. I don't play the "golden ears" thing much but I will say that back in the early days, when my converters went from 16 bits to 20 bits with the Ensoniq PARIS system, the difference was obvious and I could really hear the difference between 16 bits of real resolution (courtesy of 20-bit operation) and the 12-14 bits of real-world resolution the 16-bit converters delivered.
 
My basic guideline is if I can hear a difference, I do it and if I don't hear a difference, I don't. That's why even though I'm convinced beyond a shadow of a doubt that rendering at 192 kHz can deliver superior virtual instrument sound quality, I still record at 44.1 kHz. Why? Because there are very few times that rendering at 192 kHz does make a difference, and I can always export the file, render at 192 kHz, then bring it back into the 44.1 kHz project to obtain the benefits of 192 kHz rendering in a 44.1 kHz project. And of course, CbB's upsampling is all you need in most cases anyway.

Anderton

drewfx1

Anderton
I think the rules are different for what happens outside the box compared to what happens inside the box. If you record an acoustic guitar at 44.1 kHz with 24 bits of resolution and play it back, then it will be 24 bits no matter what. 

 
Technically speaking, though the recording itself will be 24 bits, the actual resolution will depend on the playback level and the noise from all sources present - including the noise in the signal picked up by the mic when the recording was made. The limits of hearing could also apply if they weren't buried under the noise floor from everything else. IOW 24 bit is the theoretical limit of that particular digital format, not the real world resolution (which is always far less than 24 bits).

 
I know that, but those 24 bits still contain information, even if it's just noise or zeroes. I think the world has standardized on saying converters have 24-bit resolution if technically, they're capable of it because there's no way of knowing the extent to which that resolution will be compromised in a final product. So I would differentiate between useable and theoretical resolution.
 

 
Yeah, I was more just trying to clarify something to make sure people didn't misconstrue what you were saying.
 

 

The problem for us here is that one needs to know some complicated DSP stuff to know when a given bit depth/sample rate might be really significant, completely irrelevant or somewhere in between.

 
I find the really significant ones are audible and obvious. For example, rendering a non-oversampling virtual instrument pulse wave at 44.1 or 192 kHz is such a huge difference you might as well be listening to a different patch altogether.

 
And that's a good example of something that can be unambiguously audible to the point that you don't have to bother with careful blind testing. And I'm betting that if I ask, what you'll describe hearing fits pretty much exactly with what we would expect you to hear. I'll just say that for some things what people describe "hearing" doesn't always match the artifact they claim to be hearing. Hmmm....
 
I should also add that even in this very good example of the benefits of oversampling, if the virtual instrument had been coded to use what's known as "band limited waveforms" then the oversampling might not have been of any value.
 
The point being that it's hard to come up with simple guidelines.
 
Having said that....
 

My basic guideline is if I can hear a difference, I do it and if I don't hear a difference, I don't.

That's a pretty good guideline. 
 
But I would suggest we just have to be careful when we start getting to the point where differences are harder to hear and/or can only be described with vague subjective language that even people of your level wouldn't be quite sure how to measure if we wanted to. Or one can do a careful double blind listening test, because unfortunately we are all basically programmed to sometimes imagine we hear stuff that isn't there. And as the saying goes, this applies to everyone, including the people who don't think it applies to them.

rabeach
Nyquist-Shannon sampling theorem does not provide a simple, straight forward way to determine the correct minimum sample rate for a system because it requires that the signal be perfectly bandlimited and we cannot do that

We don't live in a perfect world so we don't need a perfect filter.
 
I would say you can determine it by starting with the following questions and then using a good filter design algorithm:
 
1. What frequency range are we interested in (i.e. what is the pass band)?
 
2. How much stop band attenuation do we need?
 
3. How flat does the pass band need to be?
 
4. How much latency/CPU can we afford?
 
Doesn't that, and maybe a few other details pretty much spell it out?

bitflipper
 
Fortunately, interpolation doesn't enter into it. As long as any missing frequencies are outside the range of human hearing, they're not going to be missed.
 

I think he meant the interpolation done by the reconstruction filter. Or perhaps by the, um, interpolation filter in an upsampled DAC.