Premium Membership - All Voxengo Plugins at a Fixed One-Time Fee - Click Here For More Info
Forums     Plugins     CurveEQ OT: Sample rate conversion question

This topic was created before release of the latest product version, and it may contain details irrelevant to this version.  Replying is disabled for this topic.

Last

Next

Previous

First



sorry didnt know where else to put it.

Anyways is there any truth to the statement that it is better

to record at 88.2k if you plan on sample rate converting

down to 44.1k, instead of recording at 96k?

A lot of people seem to think that since its an even multiple

that the math is easier and therefore its going to produce

a better quality.

Others say that sample rate conversion is not about simple

division and therefore it doesnt matter.  In fact some suggest

that its better to record at 96k since you will retain even more

high freqs.

Thanks

Jesse


It is definitely better to record at multiplies frequencies.  88.2k in your case.  Also bear in mind that 48k sample rate was chosen by DAT equipment manufacturers because of the technical difficulty to convert between 48kHz and 44.1kHz.

Thanks.  Yes I have heard about the DAT thing.

Is there really going to be a big difference if you

try to go from 96 to 44.1?

What about this explaination, seems to make it look

like its not such a big deal.

Sample rate conversion is performed in serveral steps and several

algorithms are used here:

* To convert 88.2 kHz to 44.1 kHz the samples must be lowpass filtered

such that no frequency higher than 22.05 kHz are contained.  After that

you simply take every other sample and copy that to the new file.

* To convert 96 kHz to 44.1 kHz you must first upsample to a frequency

that is an integer multiple of both 96 and 44.1.  Which is 147/640.

This is simply done by adding 146 zeros after each input sample.  Next,

low pass filtering to 44.1 kHz must be done.  Last step is to pick

every 640th sample and put it into the output file.

In both steps the quality of the low pass filter is essential.  A

deeper discussion can be found in http://www.analog.com searching for

"Engineer To Engineer Note" EE-183."


Problem lies exactly in 147/640 ratio.  It is highly inefficient to upsample original audio by the factor of 147.  This is VERY time-consuming.

Other than that, there is no difference in resampling from 88.2k or 96k, to 44.1k.


But you're saying in the end there is no penalty in the quality of the conversion?  Thanks very much for your info.

Problem lies exactly in 147/640 ratio.  It is highly inefficient to upsample > original audio by the factor of 147.  This is VERY time-consuming.
That's interesting Aleksey, would you consider releasing a product that can do perfect 96->44.1 downsampling -- even if it takes a very long time to process?  Or are we talking like weeks per minute or something?

It is highly possible, that with the current CPUs it's not that tragical.  Of course it needs some effort to create such program, while the outcome is not predefined.  Maybe it also looks like a decent future Voxengo project, if you add a noise-shaped dithering, a limiter (resampling tends to create new peaks most of the time), the ability to use minimum-phase filters and multi-channel file support to the equation.  What do you think?

Perfect downsampling from 96/192 to 44.1, a totally unique product at the usual Voxengo price -- I'd buy it ;-)

WRT to the peaks -- that's something I hadn't thought of -- if the file could be saved as 32 or even 64bit float and then in a second process of conversion to fixed-point an auto-gain is used to bring the file back below full scale, so that limiting isn't necessary, could be good.  That would be about as transparent as possible.


In fact I could design a totally transparent peak limiter, with transition time around 50 ms - such limiter cannot be heard given that peak values do not go too far (and they won't).

I would be very interested in such a product.

John

This topic was created before release of the latest product version, and it may contain details irrelevant to this version.  Replying is disabled for this topic.

Last

Next

Previous

First