For ad/da converters ,around 60khz has been debated for a while, I think between 50-60khz so a smooth curve anti aliasing filter could be implemented cutting down on ringing while staying low enough to avoid unwanted distortions, Dan lavry popularised this theory , it can be found in his white papers. I think this is a generalization as in it's easier to design a converter that sounds good at that sample rate. Some converters may sound better at 44.1 than 96 or vice versa depending on design.
It's a usually a weigh up of the anti aliasing filter ringing down through the spectrum at low sample rates and distortions caused by high sample rate, both of those I believe have improved overtime.
On loop back tests I have had best results at 48khz and 88.2khz but this is personally what worked best for me....
I guess it's best to experiment to see what works for you best.
Things to consider are a way up of sound quality and work flow.
Last edited by Tim Petherick on Sun Dec 29, 2013 9:44 pm, edited 3 times in total.
There are two ways of thinking (none is better than the other one, people will say one thing and then the other): - Mix with the sampling rate of your intended end-samplerate (most of the time 44.1khz for audio) - Use the highest you can work with since you might never know later.
And sometimes you see the one in between: "I want to end up at 44.1khz, but I can go higher but I will use a multiple of it, so I end up using 88.2khz". Seeing that there are a lot of libraries on 44.1khz and a lot on 96khz, 88.2khz is not a popular choice .
Nebula will work (in theory) fine with whatever you give it. The library will be resampled by nebula to the samplerate you are working with. Making sure your project rate and the library-rate math will make sure nebula doesn't have to resample anything, and purists like that.
There is something a bit like oversampling (the QUALITY setting in the MAST page IIRC, which gets increased if it detects an offline render) but as far as I know in processing samples like this (the same as convolution-reverb) there is no oversampling. Since you're processing samples of your source with samples of a capture, making up samples in between is of no to little use.
Amp-sims, EQ's and stuff that do a calculation, then use the result to go into another calculation, then go into another, then into another, etc... There it gives extra precision to make up samples at the input, to get a more precise output. Here (Nebule), I believe not so much
.rf64 is the format to go if you plan some serious post-prod work. This format allows multichannels (up to 18), it stores useful metadata like Dolby or the new Loudness for normalisation when audio leveling (see link)
Think of .rf64 as a multichannel .bwf (and .bwf itself being an extended .wav)
Thanks you very much for your fast and complete answers! First things first:
Tim Petherick wrote:Hi Darkskar, If you want to experiment with oversampling I suggest (...) Some converters may sound better at 44.1 than 96 or vice versa (...) I guess it's best to experiment to see what works for you best.
Thanks Tim, This oversampling plugin makes my reaper crash, so I do not have much success in this regard, but thanks anyway it´s not your fault.
Searching about loop back tests I have found this comparison about a Scarlett 2i2 (in my case I have a F*******e Scarlett 6i6 but it must be something similar.)
jorismak wrote:Basically, use what you want. (...) Making sure your project rate and the library-rate math will make sure nebula doesn't have to resample anything, and purists like that. (...) There is something a bit like oversampling (the QUALITY setting in the MAST page IIRC, which gets increased if it detects an offline render) but as far as I know in processing samples like this (the same as convolution-reverb) there is no oversampling. Since you're processing samples of your source with samples of a capture, making up samples in between is of no to little use.
Maybe I am a kind of purist because I'm worried that my sound does not deteriorate.
Thanks for the Quality tip, reading the FAQ...
"E – QUALITY This is used by Nebula at rendering time, when the user exports audio tracks or bounces them. This feature only works if the host program (VST Host) provides notification of its internal status Increasing it Nebula will be more accurate. The actual program rate will be the result of the division between PROG RATE and QUALITY. Rendering process will be slower."
I supose this works in reaper or will I have to change something? anyway I will try it myself... thank you!
Production and post production files format BWAV (64 bits) 64 bits float with 96 kHz SR. Delivery files format FLAC 24 bits fixed with 96 kHz SR. For levels see r-128 for AV and K-meter v2 for music.
Thanks for the tip Enrique. As I am only a "onemanband" bedroom producer maybe 64 bits is too much quality for my computer, I have find that my reaper can record at 32fp and 64fp, I will make some tests.
I have studied this K-meter v2, maybe k-14 (v2) works for the metal music I do. I will try it. Thanks!
darkskar wrote:This looks interesting, thank you very much. Anyway I afraid I'm just an amateur user that make and produce my own music as a hobbie, so I don't need this by now. But thank you anyway.
In that case don't worry too much about it. Look at my post if I'm honest: If your interface supports it, there is little reason to not work at 96khz these days, unless you have an older PC who can't handle it (but 44.1 will be tricky then too ) or you don't have the disk space.
But since it's hobby-work you won't have 128+ track projects filling up your drive so fast I guess .
And what Enrique ment with his post (I guess) if that's the official standard in the pro-world these days to deliver and expect 96khz 64bit wave files. So 96khz is fine.
And it's not important enough to worry about it or to run out the door and get an interface who can do 96khz if yours can't .