R/E/P Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: [1] 2 3  All   Go Down

Author Topic: Sample Rate Conversion  (Read 19822 times)

Alan Meyerson

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 97
Sample Rate Conversion
« on: September 13, 2005, 08:45:53 AM »

Hey Folks-
A quick..(I'm sure it's been done a million times before) discussion about upsampling from 44.1. AM I BETTER OFF AT 88.2 BECAUSE OF THE MATH or does it really matter. Can I go to 96?
I've heard the arguments for both camps. I just have a decision to make in the next day and want to mull it over again.
Thanks,
Alan
Logged

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #1 on: September 13, 2005, 11:40:43 AM »

Alan Meyerson wrote on Tue, 13 September 2005 13:45

Hey Folks-
A quick..(I'm sure it's been done a million times before) discussion about upsampling from 44.1. AM I BETTER OFF AT 88.2 BECAUSE OF THE MATH or does it really matter. Can I go to 96?
I've heard the arguments for both camps. I just have a decision to make in the next day and want to mull it over again.
Thanks,
Alan


1. As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.

2. To take full advantage of the above, one should make sure that they have a SYNCHRONUS converter. There are few such devices o the market, and most devices are asynchronous (to be able to address any rate to any rate).

3. So what if you lack a SYNCHRONUS conversion, and have an ASYNCHRONUS one? That question is more subtle. I have not examined all the SRC's out there but a few implementations I saw for an ASYNCHRONUS SRC do yield better results when operated at 2:1.  That may not be the case for all devices at all rates.

3. Why up sample? Say one may (for example) wish to mix a 44.1KHz material with 88.2KHz or 96KHz. One could down sample the high rate, or up sample the low rate. The argument for up sampling the low rate is based on the fact that at least in theory (with perfect up sampling), one does not loose anything. The data contained by the fast rate is left alone. Down sampling the fast rate data to 44.1KHz would remove the energy content above 22.05KHz (assuming it is there and that you need it).

But while up sampling from 44.1KHz  to higher may have practical or commercial reasons, one should keep in mind that the processes does not really improve the audio data at all. The starting point is 44.1KHz so the energy content is limited to 0-22.05KHz. You can not expect an up sampler (or any other processes) to create something from nothing, and the best of SRC’s can not insert what is not there. You can examine the audio under 22.050KHz all day long, and find no clue regarding what happens over 22.05KHz. Contrary to all sorts of hype, there is no processes that can recreate that energy.

Some people argue that an up sampled data sounds better, and I will be the last one to argue with or negate such observations. As a DA designer, I can see scenarios where an X2 up sampled data can be better processed by a particular DA than an X1.
I can also see scenarios where the X2 data will be inferior after up sampling by X2.
The bottom line is HRADWARE IMPLEMENTATION (or software implementation). But true to form, many in audio jump into drawing conclusions about what is good or bad, based on tests limited to specific hardware. In some cases such conclusions may be true for a couple of years, and when hardware architecture and approaches changes, the conclusions does not.

Those that believe that an X2 up sampling is a good thing need to answer one question:
The data is going to be up sampled anyway, by any DA in any playback system (unless we go back to the pre early 1990’s). Chances are that the playback DA will up sample by yet another X2, or X4 or X1...or 256....  Therefore, the argument about the benefits of up sampling become about quality of implementation. The studio person may have a better up sampler than a typical commercial DA, and indeed the first X2 up sampling stage is the most critical one, (of course up, up sampling in the studio requires a release format beyond red book CD).

Having said the above, I am not against up sampling for good reasons. I do have a problem with “notions” that up sampling adds some audio or recreates something. Upsampling is done to help remove the DA unwanted image energy, and to overcome the flatness response problems of a X1 44.1KHz DA (a non issue for the last 10-15 years).

For deeper technical explanations, feel free to go to my company web at:
www.lavryengineering.com
Under the support section, look at the paper:
“Sampling, Oversampling, Imaging, Aliasing”

Regards
Dan Lavry
www.lavryengineering.com
   
Logged

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #2 on: September 13, 2005, 05:32:37 PM »

danlavry wrote on Tue, 13 September 2005 11:40

Alan Meyerson wrote on Tue, 13 September 2005 13:45

Hey Folks-
A quick..(I'm sure it's been done a million times before) discussion about upsampling from 44.1. AM I BETTER OFF AT 88.2 BECAUSE OF THE MATH or does it really matter. Can I go to 96?
I've heard the arguments for both camps. I just have a decision to make in the next day and want to mull it over again.
Thanks,
Alan


1. As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.




Dan. I don't understand your attaching the word "asynchronous" with integer in the above sentence... Was that a misprint?

Anyway, the integer rule used to be the only acceptable rule, but within the last 5 years SRCs (mostly synchronous models) have appeared that can do EQUALLY as well between integer and non-integer rates.

I'm attaching an FFT of the Weiss SFC doing a 1 kHz tone from 96 ks/s to 44.1 ks/s.

One mastering engineer claims that a particular model does better in two steps, first 96 to 48 and then 48 to 44. I don't think the Weiss requires two steps, I'm happy with its performance in one step.

Now instead of saying, "it's a rule", my advice would be, "exercise caution, because inferior SRCs may do very poorly on non-integer conversions", but excellent SRCs can do just fine with any standard rate.

BKindex.php/fa/1565/0/
Logged
There are two kinds of fools,
One says-this is old and therefore good.
The other says-this is new and therefore better."

No trees were killed in the sending of this message. However a large number of
electrons were terribly inconvenienced.

Alan Meyerson

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 97
Re: Sample Rate Conversion
« Reply #3 on: September 13, 2005, 07:36:22 PM »

I want to upsample my synths because I'm recording my orchestra at 96. I'm mixing on a Euphonix System 5 from 2 different pro-tools rigs, so my choice was to drop my orch to 48 of raise my synths to 96 and give up half my inputs. Euphonix made it easier by lending me another core.

BTW, Dan, I'm using your converters for the job.

Alan
Logged

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #4 on: September 14, 2005, 12:04:16 PM »

Alan Meyerson wrote on Wed, 14 September 2005 00:36

I want to upsample my synths because I'm recording my orchestra at 96. I'm mixing on a Euphonix System 5 from 2 different pro-tools rigs, so my choice was to drop my orch to 48 of raise my synths to 96 and give up half my inputs. Euphonix made it easier by lending me another core.

BTW, Dan, I'm using your converters for the job.

Alan


Your reason makes sense - mixing channels with different rates, when up sampling you get to keep the content of the high sample rate channel.

Regards
Dan Lavry
www.lavryengineering.com  
Logged

Daniel Weiss

  • Newbie
  • *
  • Offline Offline
  • Posts: 29
Re: Sample Rate Conversion
« Reply #5 on: September 14, 2005, 12:52:16 PM »

danlavry wrote on Tue, 13 September 2005 17:40



1. As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.



Can't agree on the last paragraph. With a polyphase filter approach the number of computations to be done in real time are about the same for both cases (44.1 to 88.2 vs 44.1 to 96). The 44.1 to 96 case requires a much longer digital filter which means more coefficient storage. But because with polyphase filters there is only a subset of the coefficients required per sampling period, the computational load is about the same as with the 44.1 to 88.2 case, where the filter order is much lower. So both cases can be done with the same precision at the same DSP power requirements.

Daniel
www.weiss.ch
Logged
Weiss Engineering Ltd.
www.weiss.ch

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #6 on: September 14, 2005, 01:29:30 PM »

Quote:

Dan. I don't understand your attaching the word "asynchronous" with integer in the above sentence... Was that a misprint?...
Dan. I don't understand your attaching the word "asynchronous" with integer in the above sentence... Was that a misprint?

Anyway, the integer rule used to be the only acceptable rule, but within the last 5 years SRCs (mostly synchronous models) have appeared that can do EQUALLY as well between integer and non-integer rates....
BK


I don't have time to look up previous statements right now but will take your word that I mistyped. Clearly, synchronus is for integer ratio, asynchronus is for non-integer ratio.

Your comment about having only integer ratio until the last 5 years very inaccurate. For example,I have been making and selling a non-integer ratio device since 1993. The first model was the optimizer Model 3000, and it has been upgraded to model 3000S. It is well known and used at very high end facilities such as Bob Ludwig's Gateway Mastering and all the mastering rooms at Sony/BMG in NY among other places.

I also have a plugin card for the LavryBlue, that is strictly a synchronous 2:1 or 1:2, for highest purity.

Both the 3000S and the LavryBlue M.BY2 are made from the ground up. I do not use an SRC part. I make my own. When one designs an SRC from a ground up, one learns about SRC's.

Most manufacturers buy an IC from Analog or TI, “glue it to a couple of transformers” and show the FFT's which is really what you see in the data sheet of the the IC maker. That approach does work, but it does not make the designer or user into an SRC expert. In fact, neither needs to even know the ABC of how things work, and, the FFT's in product A are the same as in product B when using the same IC. The FFT's are all about digital data crunching, no analog circuits to alter the sound...  

Don't get me wrong, FFT's are very importent, and both Analog Devices and TI have great FFT's. In fact the old AD1890 already had FFT's that exceeded the performance of most AD converters, yet it was not as good sounding as some newer devices. The old AD1890 noise floor has been much improved on by AD1891, AD1895 and now AD1896. But do you think that the main difference is in how low the noise floor is? I do not.

Dan Lavry
Lavry Engineering, Inc.
www.lavryengineering.com
Logged

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #7 on: September 14, 2005, 01:36:59 PM »

Daniel Weiss wrote on Wed, 14 September 2005 17:52

danlavry wrote on Tue, 13 September 2005 17:40



1. As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.



Can't agree on the last paragraph. With a polyphase filter approach the number of computations to be done in real time are about the same for both cases (44.1 to 88.2 vs 44.1 to 96). The 44.1 to 96 case requires a much longer digital filter which means more coefficient storage. But because with polyphase filters there is only a subset of the coefficients required per sampling period, the computational load is about the same as with the 44.1 to 88.2 case, where the filter order is much lower. So both cases can be done with the same precision at the same DSP power requirements.

Daniel
www.weiss.ch



Daniel,
It is good have you here however I was not comparing a polyphase at 2:1 to a polyphase operating at a non integer ratio. I was comparing polyphase to a non- polyphase.

My point is: with synchronous 2:1 or 1:2 one does not have to deal with timing issues of 2 data trains running at unrelated rate. One either inserts an output sample in exactly the mid point, or deletes every other sample.
With Polyphase, one has the added task of figuring out to great precision where the output sample is on a sample by sample basis. That process is an added requirnment and the solutions are not as clean as an truly synchronous SRC. For example, one such common solution is to add hysterhysis to the time detection, which can bite you in terms of phase problems in multi track applications.

Dan Lavry
Lavry Engineering, Inc.
www.lavryengineering.com

Logged

Daniel Weiss

  • Newbie
  • *
  • Offline Offline
  • Posts: 29
Re: Sample Rate Conversion
« Reply #8 on: September 14, 2005, 02:09:26 PM »

danlavry wrote on Wed, 14 September 2005 19:36

Daniel Weiss wrote on Wed, 14 September 2005 17:52

danlavry wrote on Tue, 13 September 2005 17:40



1. As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.



Can't agree on the last paragraph. With a polyphase filter approach the number of computations to be done in real time are about the same for both cases (44.1 to 88.2 vs 44.1 to 96). The 44.1 to 96 case requires a much longer digital filter which means more coefficient storage. But because with polyphase filters there is only a subset of the coefficients required per sampling period, the computational load is about the same as with the 44.1 to 88.2 case, where the filter order is much lower. So both cases can be done with the same precision at the same DSP power requirements.

Daniel
www.weiss.ch



Daniel,
It is good have you here however I was not comparing a polyphase at 2:1 to a polyphase operating at a non integer ratio. I was comparing polyphase to a non- polyphase.

My point is: with synchronous 2:1 or 1:2 one does not have to deal with timing issues of 2 data trains running at unrelated rate. One either inserts an output sample in exactly the mid point, or deletes every other sample.
With Polyphase, one has the added task of figuring out to great precision where the output sample is on a sample by sample basis. That process is an added requirnment and the solutions are not as clean as an truly synchronous SRC. For example, one such common solution is to add hysterhysis to the time detection, which can bite you in terms of phase problems in multi track applications.

Dan Lavry
Lavry Engineering, Inc.
www.lavryengineering.com




I think we are mixing terms / definitions here. Polyphase has nothing to do with synchronous / asynchronous. Both models can employ polyphase filters. Also non-integer ratios do not necessarily require async designs - I don't know whether you imply that in your postings, somehow it seems to me as you would. A 44.1 to 96 converter can be made a sync design, easily. Well, actually any rational ratios (n/m, n and m being integers) can be done with sync designs. 44.1/96 is equal to 147/320 so no big deal to do it synchronously. (1/pi would be a different issue).

So again, synchronous designs with about the same ratio between input and output sampling rates (like 44.1 to 88.2 vs 44.1 to 96) pose about the same computational load.
Async designs are a different issue, you are right. Async designs make only sense when a source can't be locked to a housesync or when varispeed is employed. All other scenarios can use synchronous designs. I would expect the SRC chip makers to come out with a chip which can be switched to sync or async mode. That would be something.

Daniel
www.weiss.ch
Logged
Weiss Engineering Ltd.
www.weiss.ch

C-J

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 80
Re: Sample Rate Conversion
« Reply #9 on: September 14, 2005, 03:11:24 PM »

danlavry wrote on Tue, 13 September 2005 17:40

With Polyphase, one has the added task of figuring out to great precision where the output sample is on a sample by sample basis.

'Scuse moi, Sirs,  Embarassed

Could you (easily) explain what a Polyphase Filter means?
If the "where" from above, has to do with reconstructing the waveform with a new SR, does it refer to a vertical or horizontal position, (or maybe both)?

Thanks,
C.J.
Logged

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #10 on: September 14, 2005, 03:22:31 PM »

Daniel Weiss wrote on Wed, 14 September 2005 19:09

danlavry wrote on Wed, 14 September 2005 19:36

Daniel Weiss wrote on Wed, 14 September 2005 17:52

danlavry wrote on Tue, 13 September 2005 17:40



1. As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.



Can't agree on the last paragraph. With a polyphase filter approach the number of computations to be done in real time are about the same for both cases (44.1 to 88.2 vs 44.1 to 96). The 44.1 to 96 case requires a much longer digital filter which means more coefficient storage. But because with polyphase filters there is only a subset of the coefficients required per sampling period, the computational load is about the same as with the 44.1 to 88.2 case, where the filter order is much lower. So both cases can be done with the same precision at the same DSP power requirements.

Daniel
www.weiss.ch



Daniel,
It is good have you here however I was not comparing a polyphase at 2:1 to a polyphase operating at a non integer ratio. I was comparing polyphase to a non- polyphase.

My point is: with synchronous 2:1 or 1:2 one does not have to deal with timing issues of 2 data trains running at unrelated rate. One either inserts an output sample in exactly the mid point, or deletes every other sample.
With Polyphase, one has the added task of figuring out to great precision where the output sample is on a sample by sample basis. That process is an added requirnment and the solutions are not as clean as an truly synchronous SRC. For example, one such common solution is to add hysterhysis to the time detection, which can bite you in terms of phase problems in multi track applications.

Dan Lavry
Lavry Engineering, Inc.
www.lavryengineering.com




I think we are mixing terms / definitions here. Polyphase has nothing to do with synchronous / asynchronous. Both models can employ polyphase filters. Also non-integer ratios do not necessarily require async designs - I don't know whether you imply that in your postings, somehow it seems to me as you would. A 44.1 to 96 converter can be made a sync design, easily. Well, actually any rational ratios (n/m, n and m being integers) can be done with sync designs. 44.1/96 is equal to 147/320 so no big deal to do it synchronously. (1/pi would be a different issue).

So again, synchronous designs with about the same ratio between input and output sampling rates (like 44.1 to 88.2 vs 44.1 to 96) pose about the same computational load.
Async designs are a different issue, you are right. Async designs make only sense when a source can't be locked to a housesync or when varispeed is employed. All other scenarios can use synchronous designs. I would expect the SRC chip makers to come out with a chip which can be switched to sync or async mode. That would be something.

Daniel
www.weiss.ch



Daniel,

I will check my terminology. One way or the other, your last paragraph (starting with Async designs) expresses very well the point that I am trying to make.

I am very well aware of the difference between rational and real numbers, thus up and down sampling by integers, vs. having to do something else. I normally refrain from using words such as rational numbers or real numbers, because few here would follow it, but here we go (for those that want to follow it):

Rational number is a number that can be expressed as a ratio of two integers. For example 3/4 which is 0.75  
From rate conversion standpoint, you go up by 3 and down by 4.

Real number includes the complete set of the numbers along a single axis. Some of the real numbers are rational, but others are not. If I recall my modern algebra, there are more non real numbers. Example for a real and non rational number is pi which is 3.141592654..... it goes on forever. the number 1/3 is 0.333333... and it also goes for ever, but 1/3 is obviously rational, while pi is not. Therefore you can not find numbers n/m to up sample by m and down sample by n, which calls for a conceptually different solution.  

I agree that having an IC that can be switched between the 2 modes will be "something".

Regards
Dan Lavry
www.lavryengineering.com  
Logged

Daniel Weiss

  • Newbie
  • *
  • Offline Offline
  • Posts: 29
Re: Sample Rate Conversion
« Reply #11 on: September 14, 2005, 03:57:09 PM »

C-J wrote on Wed, 14 September 2005 21:11

danlavry wrote on Tue, 13 September 2005 17:40

With Polyphase, one has the added task of figuring out to great precision where the output sample is on a sample by sample basis.

'Scuse moi, Sirs,  Embarassed

Could you (easily) explain what a Polyphase Filter means?
If the "where" from above, has to do with reconstructing the waveform with a new SR, does it refer to a vertical or horizontal position, (or maybe both)?

Thanks,
C.J.


In a nutshell: As an example of a polyphase filter used in an SRC - it is a large FIR filter. A symmetrical FIR filter has a constant delay (linear phase response). The polyphase filter now takes only a subset of all coefficients of that long FIR for any given output sample, i.e. output sample # 1 is calculated using subset # 1, output sample # 2 uses subset # 2 and so forth. Now, the subset #1 takes every Nth coefficient of the FIR starting with coefficient # 1. The subset # 2 takes every Nth coefficient starting with coefficient # 2. So the resulting FIR for any given output sample has still the same amplitude response as the "complete" FIR (the full set of coefficients), but the delay through the FIR varies for each subset. Hence the term polyphase.
So this polyphase filter lets you calculate values between any two sample points. Example: For a 44.1 to 88.2 conversion you need to calculate a new value exactly midway (on the time axis) between two sample values of the original 44.1, so in that case you would have two subsets in the polyphase filter, one with delay 0 (so to speak) and one with delay half a sampling period of 44.1. Other examples: For a 44.1 to 3 times 44.1 conversion you need three subsets, each 1/3rd of a sampling period apart in their delays. For a 44.1 to 48 conversion you need 160 subsets, because you first go up to 160 times 44.1kHz (=7.056MHz), i.e. this gives you a fine grid of samples, 160 samples per 44.1k sampling period. Out of that fine grid you take every 147th sample and this is your 48kHz output.
I hope that helps a little - google gives more than 27000 hits for "polyphase filter", so the concept is not that exotic...

Daniel
www.weiss.ch
Logged
Weiss Engineering Ltd.
www.weiss.ch

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #12 on: September 14, 2005, 06:08:43 PM »

Daniel Weiss wrote on Wed, 14 September 2005 20:57

C-J wrote on Wed, 14 September 2005 21:11

danlavry wrote on Tue, 13 September 2005 17:40

With Polyphase, one has the added task of figuring out to great precision where the output sample is on a sample by sample basis.

'Scuse moi, Sirs,  Embarassed

Could you (easily) explain what a Polyphase Filter means?
If the "where" from above, has to do with reconstructing the waveform with a new SR, does it refer to a vertical or horizontal position, (or maybe both)?

Thanks,
C.J.


In a nutshell: As an example of a polyphase filter used in an SRC...I hope that helps a little - google gives more than 27000 hits for "polyphase filter", so the concept is not that exotic...

Daniel
www.weiss.ch



Deniel,

I was writing an explanation, and when I came to post it, I see you already posted a nice explanation.

Regards
Dan Lavry
www.lavryengineering.com



Logged

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #13 on: September 15, 2005, 11:33:25 AM »

danlavry wrote on Wed, 14 September 2005 13:29

Quote:


Dan. I don't understand your attaching the word "asynchronous" with integer in the above sentence... Was that a misprint?...

Anyway, the integer rule used to be the only acceptable rule, but within the last 5 years SRCs (mostly synchronous models) have appeared that can do EQUALLY as well between integer and non-integer rates....
BK


I don't have time to look up previous statements right now but will take your word that I mistyped. Clearly, synchronus is for integer ratio, asynchronus is for non-integer ratio.




I respect Dan tremendously. He is one of the good guys. I am not an authority and I'm sorry to be differing with Dan on this one. I believe you are using the terms SYNCHRONOUS AND ASYNCHRONOUS WRONG. This is because a SYNCHRONOUS converter can do non-integer ratios. It is NOT necessary to use an asynchronous converter to do non-integer ratios. HOWEVER, IT IS necessary to use an asynchronous converter when varispeeding the source rate. An asynchronous converter uses a set of variable filters as it estimates the incoming sample rate. But to repeat, you do not have to use this architecture to do non-integer rates.

For example, the Weiss SFC-2 is SYNCHRONOUS sample rate converter that does non-integer ratios and uses polyphase filters to accomplish this. As a synchronous converter it has one set of filters and uses a complex, but fixed ratio conversion to arrive at the result, and it is NOT subject to jitter problems. I call that a SYNCHRONOUS converter, and so either there's something wrong with your definition or you're using the definition in a non-standard manner.

Asynchronous SRCs CAN deal with non-integer ratios, but they do not have to, they can also deal with integer ratios. The prime difference in performance between synchronous and asynchronous is that asynchronous SRCs can deal with varispeeded rates. The next differences are of course distortion and noise floor and jitter.

Quote:



Your comment about having only integer ratio until the last 5 years very inaccurate. For example,I have been making and selling a non-integer ratio device since 1993. The first model was the optimizer Model 3000, and it has been upgraded to model 3000S. It is well known and used at very high end facilities such as Bob Ludwig's Gateway Mastering and all the mastering rooms at Sony/BMG in NY among other places.




Please excuse me. I misspoke. I was very aware of your Model 3000, I simply forgot to include it as one of the EXCEPTIONS that goes back much further than 5 years. But I am aware of many of the SRCs on the market, both built into DAWs and external devices, and I was simply trying to point out that on the average, sometime in the past 5 years, the battle has begun to be won. That on the average, more and more current SRCs (both SYNCHRONOUS and ASYNCHRONOUS) are performing equally well doing both integer and non-integer conversions. That's all I was trying to say.

Quote:



I also have a plugin card for the LavryBlue, that is strictly a synchronous 2:1 or 1:2, for highest purity.




I'm certain that would give the highest purity given the design of your filters. But as Mr. Weiss just pointed out, a well-designed polyphase-filter-based SRC can do as good a job going from 96 to 44 as from 88 to 44. So it can be done, as described in Andy Moorer's historic wake-up paper. That was why, in a previous thread on this topic, I cited that "more computational power" will result in as good a result non-integer as integer. And you poo pooed that statement, but in essence, that is the simple summary of the conclusions from the historic Moorer white paper. And Moorer is a world authority on the subject of SRC precision.

Quote:



Both the 3000S and the LavryBlue M.BY2 are made from the ground up. I do not use an SRC part. I make my own. When one designs an SRC from a ground up, one learns about SRC's.




Which is why it sounds so good!

Quote:



Most manufacturers buy an IC from Analog or TI, ?glue it to a couple of transformers? and show the FFT's which is really what you see in the data sheet of the the IC maker. That approach does work, but it does not make the designer or user into an SRC expert. In fact, neither needs to even know the ABC of how things work, and, the FFT's in product A are the same as in product B when using the same IC. The FFT's are all about digital data crunching, no analog circuits to alter the sound...  




I am not the expert on how to interpret the FFT or whether the FFT is the bees knees. I know there are other important measurements and of course listening that determine the difference.

But by using an FFT and the right test signals and methods we can surely see the errrors of an SRC that does poorly with non-integer sample rate ratios.

Obviously, when the distortion products are no longer detectable and the noise floors are as low as in the Weiss measurements, then if there are sonic differences we have to look to other reasons why one SRC sounds better than another, for example, the slope of the low pass filter and the phase response, the precision of the computation and the dither used to reduce the output to 24 bits. And maybe the voodoo we cannot yet quantify!

The Moorer paper shows the theoretical (and real) results that can occur when insufficient power is applied to a non-integer conversion. But the paper also points out how a SYNCHRONOUS converter can be constructed which will give EQUALLY low distortion at non-integer ratios.

This paper led to the Sonic Solutions HD sample rate converter which Vickie Melchior implemented for Sonic. I'm sorry I cannot locate the paper today. It's not filed at Andy Moorer's site nor is it in the paper list at Sonic Solutions anymore.
Logged
There are two kinds of fools,
One says-this is old and therefore good.
The other says-this is new and therefore better."

No trees were killed in the sending of this message. However a large number of
electrons were terribly inconvenienced.

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #14 on: September 15, 2005, 04:15:36 PM »

Bob Katz said:

"I respect Dan tremendously. He is one of the good guys. I am not an authority and I'm sorry to be differing with Dan on this one. I believe you are using the terms SYNCHRONOUS AND ASYNCHRONOUS WRONG. This is because a SYNCHRONOUS converter can do non-integer ratios. It is NOT necessary to use an asynchronous converter to do non-integer ratios. HOWEVER, IT IS necessary to use an asynchronous converter when varispeeding the source rate. An asynchronous converter uses a set of variable filters as it estimates the incoming sample rate. But to repeat, you do not have to use this architecture to do non-integer rates".

Hello Bob,

As an engineer, I pay more attention to technical and less to language, so it is possible I am not using the language properly. As I stated before, I will look into the proper usages of synchronous vs. asynchronous. But for now, let me explain why I called a 44.1 to 88.2 conversion synchronous and 44.1 to 96KHz asynchronous.

In the first case (44.1 to 88.2KHz), the 2 data streams are synchronous. We agree here. Typicaly, there is one physical clock at a high integer multiple of both 44.1 and 48KHz. For example, a typical crystal oscillator at 11.2896MHz is divided by 128 to yield 88.2KHz and by 256 to yield 44.1KHz. Those clock trains run together synchronously, and if the original 11.2896MHz clock drifts up by 10 ppm (oarts per million), both 88.2 and 44.1KH drift up by 10ppm. The result is synchronous operation. The timing (frequency) relationship between the 2 clock trains is set “iron clad” to 2:1.

But when we work in a real world audio studio, with one clock is set to 44.1KHz, and the other to 96KHz, we are talking about 2 physically different crystal clocks. Now say the 44.1KHz drifts up by say 7 ppm and the 96KHz drifts down by say 4ppm. The total relative drift is 11ppm. The frequency ratio changes with temperature, with component aging…

Try the following: Say you set (tweak) one clock to be exactly the same as the other. We are talking about 2 separate clocks. Your dual channel scope triggers on the firs  44.1KHz and if the other is exactly at the same rate, the scope will show 1 cycles of clock A for each cycle of clock B, at some given phase (fixed time delay). Now give it a few minutes and come back – the wave you trigger on is steady, the other wave is moving left or right… The ratio drifted away from 2:1…

I call that asynchronous. The relationship between the input data rate and the output rate is determined by 2 separate clocks, and while they may be very accurate, they are not locked to each other in the “iron clad manner” that I view as synchronous.

Perhaps you can explain what it is about my explanation that you disagree with. I am truly open to have my definition corrected. But so far, I believe that my understanding of asynchronous is generally correct – when you can not have 2 clock trains relates in a predictable way, they are no longer synchronous.

Regards
Dan Lavry
www.lavryengineering.com
Logged
Pages: [1] 2 3  All   Go Up
 

Site Hosted By Ashdown Technologies, Inc.

Page created in 0.045 seconds with 18 queries.