Recording at 24/96 ... are there any issues ?

Yes truncation to 44.1 when going to CD. 24 bit is fine and can be dealt with with ease. Though there are some good sample rate converters out there R8brain is one from Voxengo.

There are tons of threads on this so I wont repeat what has already been said too many times already.

ORIGINAL: TomG

Hi all

I am thinking of trying a few new projects, from scratch at 24/96 - normally I record at 24/44.1.

The final mixed-down project will need to come down to 16/44.1 for CD

Apart from increased hard-disk space, are there any pitfalls I should watch out for ?


Thanks,
Tom

Pitfalls:

#1 Failing do identify clearly why you want to record at 24/96
#2 2 1/2 times more storage requirements per clip (did I do this math right guys?)
#3 Increased I/O load on all aspects of your software and computer

Just some thoughts....

-D

Hi Tom,

I'm an advocate of 24/96 and look forward to the day when that is the standard. However, there are a number of problems that exist in addition to those discussed, especially if you do anything more than record/mix/downsample.

First, downsampling from 24/96 to 24/44.1 in SONAR is done with sinc resampling. That's not the best way to do constant-rate downsampling, so you should downsample using a better method. (Sinc resampling is localized in the time domain so is best suited, and in fact developed for, arbitrary and variable resampling such as pitch-shifting. Too many folks assume that it is a general-purpose method; it's not. Implementations also vary quite a bit.)

Second, and related, is the fact that if you use other material than that which you recorded, it will often be recorded at, targeted at, or optimized for 44.1 or perhaps 48, not 96. So here you face a decision as to not only how to optimize resampling, but whether or not the material you are integrating should be resampled, or if your recorded and/or submixed material should be resampled. That is, when and where to resample what material constantly arises. This issue doesn't come up if you do all your own material at 24/96.

Third, very closely related, is that a number of synthesizers are not target at nor optimized for 96,000 samples/second. For example, the Cakewalk synths Dimension Pro and Rapture do not work properly at 96,000 samples/sec --- distortion and/or pitch-bend screeching. The samples used in most synths are not recorded at 24/96 to begin with, so the second problem mentioned above comes up in dealing with most synths --- when and where to resample what material.

Fourth, much of the filter design inside plugins and other audio processors is aimed at 44.1 or 48, not 96. This means that some of the advantages of going to 24/96 are lost. The authors of these plugins and processors are causing you to throw away your carefully recorded material beyond say 11 kHz (e.g. the higher harmonics which I find give clarity). So unless you're careful about which plugins you use (and make sure you understand their internals quite well) or unless you write your own audio programs, you may end up losing much of the advantage if you're not careful. Many folks are not even aware that this is an issue and feed their audio to one plugin or program after another, each one of which does filtering. At each successive stage, one may not notice much at all. But from beginning to end, it adds up to change the result substantially. A lot of time is then spent EQ'ing, multiband compressing, and so on to try and bring things back to life.

There is more, but I'll stop for now --- just wanted to point out that there are a lot of issues one could consider, many of which arise from the fact that the standard is 44.1 and that this unfortunately has a negative effect beyond that which is commonly appreciated. It is my impression that most folks have not really spent much time working at 24/96. If you decide to go for 24/96, you'll have to do some work to preserve it, and the optimum approach varies from project to project.

There are more pitfalls to swimming upstream than the mere fact that it takes a little longer....

Regards,
Dave Clark

First, downsampling from 24/96 to 24/44.1 in SONAR is done with sinc resampling. That's not the best way to do constant-rate downsampling, so you should downsample using a better method. (Sinc resampling is localized in the time domain so is best suited, and in fact developed for, arbitrary and variable resampling such as pitch-shifting. Too many folks assume that it is a general-purpose method; it's not. Implementations also vary quite a bit.)

Good post, Dave. Can you cite a reference for the above statement? My understanding has been that SONAR's SRC was among the best.

"the signal is first resampled to a least common multiple sample rate which makes conversion perfect."

That's the standard method: upsample to the least common multiple, then downsample to the target rate. For example, 44.1 to 48 is the awkward ratio of 147:160. I am not an expert on this subject, but I believe R8Brain and SONAR use exactly the same interpolation algorithm.

ORIGINAL: bitflipper

First, downsampling from 24/96 to 24/44.1 in SONAR is done with sinc resampling.

Good post, Dave. Can you cite a reference for the above statement? My understanding has been that SONAR's SRC was among the best.

Yeah, I was going to ask the same thing. Where's the reference for Sonar's method of resampling? (seriously, I'd just like to know where/how DaveClark found this out)

Voxengo

ORIGINAL: mike_mccue

I agree... great post.

Dave Clark, may I ask, what's your take on the Voxengo R8Brain feature:

"the signal is first resampled to a least common multiple sample rate which makes conversion perfect."

At first I thought... oh that's cool... and then I thought... doesn't it still end up being the same number? I guess it matters how course the rounding is but it seems to me there s rounding either way. Do you have any insights or opionions?

That sounds like marketing speak. It still needs to be filtered...

UnderTow

Hi Bit,
I simply deduced that multiplying 44.1 x 3-1/3 = 147 and 48 x 3-1/3 = 160

It seems to me that there is still rounding of the last numeral... maybe this method simply drives it out a few more places?

I'm thinking there is a clear explanation... I'm just not seeing it.

best regards,
mike

ORIGINAL: mike_mccue

Hi Bit,
I simply deduced that multiplying 44.1 x 3-1/3 = 147 and 48 x 3-1/3 = 160

It seems to me that there is still rounding of the last numeral... maybe this method simply drives it out a few more places?

I'm thinking there is a clear explanation... I'm just not seeing it.

best regards,
mike

Multiply by 147 and divide by 160: 48 * 147 / 160 = 44.1

UnderTow

ORIGINAL: bitflipper

Thanks, John. But I was looking for something that explains the R8Brain algorithm, and hopefully makes a case for why it is superior to other sample rate converters. There is this oft-cited reference, which shows nearly identical results for R8Brain and SONAR.

I was going to write some comments but something seems to be wrong with Dave's site. When I refresh I get a new graph and I don't always get the same graph when I select a new converter.

What do you see when you look at Sonar's Sweep graph? Do you see the high-end cut-off (slightly) and a bit of imaging?

(Trying to find out if it is my browser or the site).

UnderTow

ORIGINAL: UnderTow

ORIGINAL: John
dither is also a kind of fudge that is not a real solution for bit depth reduction.

Where do you get this idea from?

UnderTow

I am not sure what you are asking. But the way I am answering is that with understanding what dither is and how it works its a necessary evil. To me its a thing that in another context I would do everything in my power to avoid.

What do you see when you look at Sonar's Sweep graph? Do you see the high-end cut-off (slightly) and a bit of imaging?

It works fine for me. I'm using Firefox, if that makes a difference.

The SONAR sweep shows a barely-visible alias. R8Brain shows none. But have a look at Cubase 4 for a chuckle. It's a psychedelic light show of aliased frequencies. Adobe Audition fares well in the sweep test, but Sound Forge looks pretty awful.

ORIGINAL: UnderTow

ORIGINAL: mike_mccue

Hi Bit,
I simply deduced that multiplying 44.1 x 3-1/3 = 147 and 48 x 3-1/3 = 160

It seems to me that there is still rounding of the last numeral... maybe this method simply drives it out a few more places?

I'm thinking there is a clear explanation... I'm just not seeing it.

best regards,
mike

Multiply by 147 and divide by 160: 48 * 147 / 160 = 44.1

UnderTow

Yes, that part is obvious. But in the context of extrapolating or filtering data during a sample rate conversion I fail to see how it's more accurate.

I guess I starting to visualize the timeline and the idea that in for example 44.1kHZ sampling the absolute times are arbitrary and the idea of rounding in either direction isn't really an option without calling it a clock distortion of some sort.

at 44.1kHz, 2000 samples covers exactly 0.04535147392290249433106575963718_ seconds and any rounding other than the accepted figure for that exact sample length is not accurate.

I think I'm getting it know.

best,
mike