Geoff there is something else going on there. Looks like some sort of HF noise.

Behold...
Have we beaten the 64 bit precision engine post record?

How do we find out if a dsp programmer has incorporated CPU saving short cuts and or round offs to their products' calculations? How do we find out what oversampling options are specifically doing with those calculations. For example; Is "2x" oversampling in a dsp residing in a 44.1kHz project actually using all the increments available in 88.2kHz or does that just bump it up to twice the detail of the actual calculations happening in the dsp?
 
For example; How do we know that a synthesizer isn't just grabbing every other sample from a stream and mashing stuff together into the "synthesis"? I guess we'd have to ask.
 
Is it possible that some programmers use the same strategies that audio compression codecs use? Is it possible that some dsp selectively omits the use of information that is thought to be pyscho acoustically masked by other info so as to optimize calculation efficiency? If something did that then scaling the sample rate might help with adding more detail.

 
Mike, I think this is something that Bitflipper would be eminently qualified to discuss. I hope I didn't scare him off because he caught me when I was dealing with some really difficult issues unrelated to Cakewalk or my gig...
 

Where it gets tricky is some things will only really require a higher rate with certain settings - i.e. a compressor may be absolutely fine unless you push it to really fast attack/release times and set the threshold so it's constantly crossing back and forth. So do you always oversample it and waste CPU for the 90% of uses where it will be fine, or never oversample and potentially get some unpleasant distortion with specific settings, or do you give the user a choice - knowing that most of them will have no idea when it needs to be turned on and when it will have no benefit?

 
Drew, I think this is another discussion that while a moving target (e.g., not relevant for 12-core monster, relevant for older laptop) is very important. There are definite economic tradeoffs involved which will ultimately influence how this all resolves.

I was going to sit this one out but.... you know.
 
I noticed several years ago that several of the virtual instruments I use regularly sounded better at 48khz than at 44.1khz. Most noticeable at the time was LoungeLizard but NI B4 also was noticeable.  I started recording at that resolution as soon as I discovered that.
 
My converters will not go any higher than 48Khz though my Raydat will.
 
This thread has me considering making a copy of my project before rendering the virtual instruments, removing all the audio from this copy, turning off my external converters and setting the raydat to 96khz, rendering the virtual instruments and then importing the audio back into the original project for mixing etc. 
 
 
I think I will have to make a test project to see if there is any benefit to be had from this.
 

Ok I did a quick test on a new project using TruePianos, NI B4II and LoungeLizard3. I have other Virtual instruments as well but I use these most often.
 
I recorded a simple midi track on all three and exported the audio output of the tracks at 96k with my converters turned off so they would not cause any problems with he export.
 
then I switched sonar back to 48khz (I did not use 44.1 since that is not the normal setting I use) Imported the resulting audio files into the project making sure they routed to the same bus that the virtual instruments went to.
 
Turned on exclusive solo and began seeing if there was any difference.
 
I can report that for both NI B4II and LoungeLizard3 there was no difference that I could hear. However Truepianos had a very noticeable difference. The 96khz file I imported had a smoothness and a pleasantly much more mellow tone to it. More rounded like a real acoustic piano would sound in a nice listening room.
 
I did not have time to test Jamstix and I don't know what sample rate its samples were recorded at. I also have Session Horns as well that I could test.
 
I may need to add this to my work flow for instruments that benefit from the higher sample rate.
 

.

mike_mccue
That's a lot of high frequency goodness. :-)
 

Thanks for looking, guys! Notice that the gain is cranked all the way up so that a soft Shhing sound clips the track. Even there, the noise when the mic is disconnected is at -60. So if you turned the gain down reasonably so you could sing into the mic, you would suppress this noise by a lot.
 
I thought the 60 cycle hum was interesting to note. Very quiet, but present. I'm not sure if this is proof of an electrical problem with the tangle of cables and power-strips I have for my gear.
 
When I compare the images with the mic unplugged to the images with the mic plugged in and the DBs, you can see the Mic is picking up lots of high frequency sound.
 
It's important to note the range of data in the images in the two posts are not the same. DigiCheck automatically shows you relevant data (if you set it to). In the image of the 'shh' recording, the range is -50 to 0 where in the images of the mic unplugged recording, the range is -100 to -50.
 
In the images with the mic disconnected, you can see that the average level is around -65 dB and in the one with the mic connected where I'm making a 'shhh' sound, the average level is louder than -20 dB and that the mic is clipping even at this setting. In all images the gain is at 65 (the loudest it goes to). 
 
So if I brought the gain down to 30 or less to make a recording of a singer, It would suppress the noise to -90 dB or something compared to the vocal which might average around -20.

.

.

Image with no mic cable plugged into the interface on that channel - gain all the way up 48v on.

 
This image is with gain all the way up, cable plugged in, no mic on the cable, but I held the cable so that the loose end of the cable didn't touch anything.

 
I think in the first images where the 60 cycle hum was more pronounced, that some of the energy might have been going through the cable looking for ground. While in this image I was holding the cable, it was substantially less.
 
I did try turning off the house wifi unit to see if there was an impact, but it was not detectable.
 
Do you think shielded cables would make any difference?