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 19821 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

Alan Meyerson

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 97
Re: Sample Rate Conversion
« Reply #15 on: September 15, 2005, 04:59:45 PM »

My head is spinning.
Thanks to you all (I think).

So, just to bring it back to the basics,
- I'm recording my orch at 96.
- I am then mixing that at 96 and real time SRC'ing my pre-records from 44.1 to 96 using a Euphonix 727 on a Euphonix System5.
- I am then, unfortunately, DOWNSAMPLING my mixed stems to 48 (my delivery requirement) in real time using a 727.
- At the same time, I'm doing a 96 version of it into a seperate system.

Everyone okay with this?

It's an honor to be part of a discussion with all of you,
Alan

Logged

Daniel Weiss

  • Newbie
  • *
  • Offline Offline
  • Posts: 29
Re: Sample Rate Conversion
« Reply #16 on: September 15, 2005, 11:59:47 PM »

danlavry wrote on Thu, 15 September 2005 22:15



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…



Ok, but Bob (I figure) and I haven't talked about such a scenario, we talked about one where the two rates (e.g. 44.1 and 96) are generated from the same "superclock" source and hence are synchronous. As in your example with 44.1kHz and 88.2kHz where the least common multiple is 88.2kHz, the least common multiple for 44.1kHz and 96kHz is 14.112MHz.

You wrote:
Quote:


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.



You assume here that the 44.1 and 96 rates are asynchronous. That can be in a general case, but isn't necessarily so.

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

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #17 on: September 16, 2005, 02:45:35 PM »

Daniel Weiss wrote on Fri, 16 September 2005 04:59

danlavry wrote on Thu, 15 September 2005 22:15



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…



Ok, but Bob (I figure) and I haven't talked about such a scenario, we talked about one where the two rates (e.g. 44.1 and 96) are generated from the same "superclock" source and hence are synchronous. As in your example with 44.1kHz and 88.2kHz where the least common multiple is 88.2kHz, the least common multiple for 44.1kHz and 96kHz is 14.112MHz.

You wrote:
Quote:


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.



You assume here that the 44.1 and 96 rates are asynchronous. That can be in a general case, but isn't necessarily so.

Daniel
www.weiss.ch


One could, for example have a high frequency source, a 14.112MHz clock can be divided by 320 to yield 44.1KHz and the same 14.112MHz clock can be divided by 147 to yield 96KHz. That would indeed produce synchronous clock trains, and if one forces their SRC to receive those clocks, it is possible to have synchronous operation.

But A TYPICAL APPLICATION of SRC is NOT based on such a case.
You and Bob assumed one case, and I assumed the other but
THE VAST MAJORITY of studios I know have an independent clock such as a house sync, for the output clock, while the data comes in to the SRC is based on another physical clock rate. Such applications are NOT synchronous, and they call for an asynchronous SRC conversion.

I would certainly accept an argument that states clearly that one can force the 44.1 to 96 to be synchronus, by having a common high frequency clock and dividers. But as you agreed "the general case" of such conversion calls for an asynchronus.

It is correct to say that one can use synchronous techniques to accomplish asynchronous results, by imposing a quantizing time grid on the conversion. This is similar voltage in digital audio, quantized to say 16 bits (65384 grid lines) and so on...
When quantizing the voltage, we want the grid to be as fine as the noise floor. When quantizing the time, we want the grid to be as fine as jitter (time domain noise).

So how many "grid lines" of say 10psec fit between say 44.1KHz samples? With time between samples at about 22.7usec, you need a grid of about 2.27 million! Is it a big deal? Yes it is. So lets go for a time grid of 100psec (pretty crude from sampling time standpoint) and we still need 227000 grid lines. Why is it a big deal? Because in an ideal case, each grid line represents a complete and unique set of FIR set of coefficients. The “quantized” SRC, where we use a synchronous SRC to approximate an asynchronous SRC by “bouncing” between fine time grid lines, just takes too much coefficient storage.

Well, there are solutions, and the common one is to have a rather coarse grid (coefficient table), as large a table as we can reasonably fit into the silicon, and the fine grid will be computed by interpolation. Now this is an approximation! Some implementations work better then others, and in fact the various solutions have serious tradeoffs.

In other words, SRC is more than a magic box with data in/data out. The question was “what works best” and for what case.

1. In a studio environment, most 44.1 to 96 (or 96 to 44.1) are asynchronous, the clocks are independent and knowing where one clock transition is does not tell you where the other clock transitions are.

2. If one can stay within the bounds of 2:1, one can get better results (greatly simplified calculations).

3. Alternativly, one can get the better results if they operate the SRC from a single clock source with dividers. That calls for aditional hardware generating (and distributing) all the clocks in a studio from one high frequency source divisable to all the desired rates.

3. When operating with asynchronus clocks, my understanding of Bob and Daniel’s remarks is that “one can use a synchronous process” to do a job in an asynchronous case. That is how polyphase SRC works. But is it a synchronous SRC? Or is it an asynchronous SRC? The process is a synchronous one (bouncing between time positions on a synchronous grid). The application is asynchronous one, moving data from one clock to another clock that is not in sync.

I called it asynchronous conversion, because it reflects the user’s point of view.

Bob, do you still disagree with what I say?

Regards
Dan Lavry
www.lavryengineering.com
Logged

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #18 on: September 17, 2005, 09:47:01 AM »

danlavry wrote on Thu, 15 September 2005 16:15




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.




Ahhh, yes, well in that case it would be asynchronous! That is intutively obvious. But let's take the 44.1 to 96K case with a synchronous SRC.  The SRC that I use  takes the 44.1 and multiplies it internally by a large rational number and then divides down to produce a 96K result that is synchronous with the input! This is done with a PLL, I believe.

You will get EXACTLY the correct number of samples out that you would expect and timed EXACTLY to the framing of the incoming signal.

I can swear to that because I run a timecode generator in jamsync that is locked to the output of the sample rate converter. Over one hour's time there is not one sample of drift.

Quote:




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.




I do not disagree with your definition as you applied it. I am simply saying that there is another way to do it, a SYNCHRONOUS way to derive an output clock at 44.1 kHz that is locked to a 96K input (and vice versa). The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used.
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.

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #19 on: September 17, 2005, 09:50:53 AM »

Alan Meyerson wrote on Thu, 15 September 2005 16:59

My head is spinning.
Thanks to you all (I think).

So, just to bring it back to the basics,
- I'm recording my orch at 96.
- I am then mixing that at 96 and real time SRC'ing my pre-records from 44.1 to 96 using a Euphonix 727 on a Euphonix System5.
- I am then, unfortunately, DOWNSAMPLING my mixed stems to 48 (my delivery requirement) in real time using a 727.
- At the same time, I'm doing a 96 version of it into a seperate system.

Everyone okay with this?

It's an honor to be part of a discussion with all of you,
Alan




It's an honor to hear someone working with such good gear! I didn't quite follow why you are doing what you are doing, but I imagine that is the only way you can do it.

Ask Euphonix for the specs on their SRC. Is it a polyphase unit? What precision does it have? Do they have any FFT measurements? And finally: What does it sound like? To my ears, an inferior 96 to 44 conversion sounds grainy and less "cohesive".

BK
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.

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #20 on: September 17, 2005, 10:13:37 AM »

danlavry wrote on Fri, 16 September 2005 14:45



But A TYPICAL APPLICATION of SRC is NOT based on such a case.





Really? I can't tell you what is typical, but I can tell you what you can buy for your money. A mastering engineer buys an SRC box, he plugs it in, and captures its output. Both synchronous and asynchronous models are available. So, what's "typical" in the end?  The ones who can afford or wish to spend their budgets on the expensive models will never be typical. We all know that. So I guess the async models outnumber the sync models, that situation will never change due to the economics of the matter.

But most of the asynchronous models have external sync inputs so you can run them "synchronously" clock-wise, just not get as good sounding results, in the case of the cheap IC-based units.

Quote:



It is correct to say that one can use synchronous techniques to accomplish asynchronous results, by imposing a quantizing time grid on the conversion. This is similar voltage in digital audio, quantized to say 16 bits (65384 grid lines) and so on...
When quantizing the voltage, we want the grid to be as fine as the noise floor. When quantizing the time, we want the grid to be as fine as jitter (time domain noise).




If I understand you correctly, I believe that is NOT the principle of the best synchronous SRCs. They use a PLL to multiply the input up to the least common multiple and then divide down. Since the DSP used to do the calculations does not depend on jitter, it works on a sample by sample basis with a polyphase filter, then the limits of the results are the noise floor and distortion of the DSP, NOT the jitter of the PLL.

Quote:



In other words, SRC is more than a magic box with data in/data out. The question was ?what works best? and for what case.

1. In a studio environment, most 44.1 to 96 (or 96 to 44.1) are asynchronous, the clocks are independent and knowing where one clock transition is does not tell you where the other clock transitions are.




I would only say "most" because of the economics of the affair, because if you buy a (more expensive, better sounding) synchronous SRC you will get a synchronous output clock from it. I take advantage of that clock and use it synchronously in my studio, though in most cases most people would just record the output of the SRC on an independent recorder or DAW so they wouldn't care if it was synchronous or not.

Quote:



2. If one can stay within the bounds of 2:1, one can get better results (greatly simplified calculations).




Well, no one can argue with a greatly simplified explanation. My greatly simplified response Smile is that there are exceptions. Those exceptions include the Weiss, Prism, and DCS SRCs, which are synchronous, and deal with all the standard rates with no prejudice, either measured or audible, or if audible, shall we say, "barely", certainly not on the order of what you would get from an inferior synchronous conversion.

Quote:



3. When operating with asynchronus clocks, my understanding of Bob and Daniel?s remarks is that ?one can use a synchronous process? to do a job in an asynchronous case. That is how polyphase SRC works. But is it a synchronous SRC? Or is it an asynchronous SRC? The process is a synchronous one (bouncing between time positions on a synchronous grid). The application is asynchronous one, moving data from one clock to another clock that is not in sync.





In the case of the Weiss, DCS, and Prism units (there may be more but I am not aware), it is a fully-synchronous clock and a fully-synchronous SRC.

Quote:



I called it asynchronous conversion, because it reflects the user?s point of view.




I respect your point of view. Let's just say that if the output clock is framed to the input clock, then the two clocks are synchronous. I think it would be a bad idea to generalize and say that "everytime" you have a non-integer clock they  must be asynchronous.

Hell, we deal with non-integer locked and framed clocks in video all the time. That's what pullup and pulldown PLLs do in the video realm.

Quote:



Bob, do you still disagree with what I say?




Of course not! I analogize our discussion to one where people have to write 6 pages of semantic definition before they can realize that they agree on everything  Smile

Bob
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 #21 on: September 17, 2005, 12:14:12 PM »


bobkatz wrote on Sat, 17 September 2005 14:47

danlavry wrote on Thu, 15 September 2005 16:15




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.




Ahhh, yes, well in that case it would be asynchronous!...

You will get EXACTLY the correct number of samples out that you would expect and timed EXACTLY to the framing of the incoming signal.

Quote:



Perhaps you can explain what it is about my explanation that you disagree with....




I do not disagree with your definition as you applied it. I am simply saying that there is another way to do it, a SYNCHRONOUS way to derive an output clock at 44.1 kHz that is locked to a 96K input (and vice versa). The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used.


I can not take too much time because I am getting ready for the AES. But I do have to point out that your comment stating that:

"The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used "
is confusing, to say the least. Again, 44.1KHz and 96KHz ARE integer related, both can be divided directly from a single common clock such as 14.112MHz. As you pointed out in a later post, one can also do it with PLL's, such as multiply the 44.1KHz by 320 and divide it by 147. So they ARE INTEGER RELATED which is the reason you can force a synchronus conversion between 44.1 and 96KHz.

Once you realize the above fact, you also realize that you can not have a synchronous SRC at any ratio, such as 44.1KHz +/-10ppm or any drift or deviation, against a 96KHz with any drift or deviation. Even the smallest of mismatch builds up and you can compute the time it takes to skip a whole sample. That demand the use of an asynchronus conversion.

The first SRC I made in 1993 did not have the capability to between arbitrary frequencies. The input frequency range was wide, but the output was restricted to a choice of 3 crystal frequencies. I did not find many users! The product needed redesign to include a connector for receiving an external clock rate (such as house sync or audio workstation).

Say you have a source of 44.1KHz and you wish to convert it to 96KHz in a synchronous way. It does force the output to exactly track the input (tolerance, temperature drift, aging...).  Now, the only way I know to have the newly generated 96KHz "integer match" the source rate of 44.1KHz. Say you have a 96KHz house sync (or a DAW 96KHz clock). The source material (at 44.1KHz) must be driven by the 96KHz house sync. In other words, the machine clock destination should generate a clock for the source.

Say you have an independent stand alone 44.1KHz source, and you force a synchronous conversion to 96KHz. Say the house sync is at (96KHz + 10ppm), and the source is (44.1KHz -10ppm) (meaning the converted 96KHz is 96KHz -10ppm). Now you have a mismatch between a 96KHz house sync (or DAW clock) and the newly converted 96KHz audio.
You can not just send the audio in - it calls for a new SRC task, from (96KHz -10ppm) to (96KHz -10ppm). This time, your SRC is Asynchronous. At this point, you may have considered a one step Asynchronous 44.1KHz to 96KHz....

You said that you do not know what a typical application is. I believe that if you think about it, you really do know. We are both in the audio business, and it is our business to know. To my knowledge, the vast majority of users do not derive their 44.1KHz source from a clock made from the 96KHz destination.
The source can be a CDR, a tape, a disk, and they most often run on some internal clock. The user want to plug a clock for some output rate of the SRC, and that is an asynchronous process. A good example is the question that started this thread. The task is to up sample the synth, and if you wish precise matching of phase and clock edges between exsiting tracks to the SRC data, both SRC input clock and output clock should be driven by the DAW clock. Forcing the conversation to be synchronous requires an ADDITIONAL clock - a 44.1KHz derived from the house sync. Most people do not do it that way, not to mention that much of the gear (for playing of the original data) is not even capable of of syncing to an external clock.

I do not have solutions to all the answers. I think it is important that we state things accurately. Again, your post may create the wrong impression when you stated that:

"The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used".

The numbers 44100 and 96000 ARE integer related (and the numbers I stated - 14.200Mhz and 320 and 147 dividers will work). When they drift together by the exact same amount, they are still integer related, but in practice it requires a single common clock source.

When you can (and do) use such a single common source, you SRC is operating in a synchronous mode, and in fact it makes your polyphase work in a synchrounus mode.

But when you do not force such clocking, and most often you can not (lack of sync capability of the source, or need to match timing of other tracks) the conversion becomes asynchronous.
 
Regards
Dan Lavry
www.lavryengineering.com


Logged

Alan Meyerson

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 97
Re: Sample Rate Conversion
« Reply #22 on: September 17, 2005, 12:42:21 PM »

bobkatz wrote on Sat, 17 September 2005 14:50

Alan Meyerson wrote on Thu, 15 September 2005 16:59

My head is spinning.
Thanks to you all (I think).

So, just to bring it back to the basics,
- I'm recording my orch at 96.
- I am then mixing that at 96 and real time SRC'ing my pre-records from 44.1 to 96 using a Euphonix 727 on a Euphonix System5.
- I am then, unfortunately, DOWNSAMPLING my mixed stems to 48 (my delivery requirement) in real time using a 727.
- At the same time, I'm doing a 96 version of it into a seperate system.

Everyone okay with this?

It's an honor to be part of a discussion with all of you,
Alan




It's an honor to hear someone working with such good gear! I didn't quite follow why you are doing what you are doing, but I imagine that is the only way you can do it.

Ask Euphonix for the specs on their SRC. Is it a polyphase unit? What precision does it have? Do they have any FFT measurements? And finally: What does it sound like? To my ears, an inferior 96 to 44 conversion sounds grainy and less "cohesive".

BK


I'm doing it this way to be able to record my orchestra tracks at a high sample rate. Alot of times, I'm limited to recording orch at 44.1 or 48 depending on the project.
This is one of those times I have an option. My pre-records are at 44.1.

So, my choices are
- record orch at 44.1
- record orch at 96k (or 88.2) and real time downsample my orch at the mix to my pre-records sample rate
- record at 96k and real time UPSAMPLE my pre-records at the mix ..my choice.

Logged

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #23 on: September 17, 2005, 06:28:28 PM »

Excuse me for not expressing the least common multiple language exactly enough. I  was too lazy to say it exactly (multiply up to the LCM, then divide down to the new rate).  But you knew what I meant, didn't you?

danlavry wrote on Sat, 17 September 2005 12:14



Say you have a source of 44.1KHz and you wish to convert it to 96KHz in a synchronous way. It does force the output to exactly track the input (tolerance, temperature drift, aging...).




If you mean that the PLL will go out of lock at a certain temperature, I think that is academic. The output will follow the input for a very wide range of sample rates. If you mean that the PLL in the SRC has a certain sample rate (frequency) acceptance window, it is made pretty wide since jitter of the PLL does not affect the DSP of the synchronous SRC. Fortunately this is not a D/A converter and the distortion of the DSP is completely independent of sample rate or jitter.

Quote:



Now, the only way I know to have the newly generated 96KHz "integer match" the source rate of 44.1KHz. Say you have a 96KHz house sync (or a DAW 96KHz clock). The source material (at 44.1KHz) must be driven by the 96KHz house sync. In other words, the machine clock destination should generate a clock for the source.




But if your DAW is the source, it feeds the synchonrous SRC a 44.1 K, out pops 96K synchronous to the 44.1 and that has to be stored on a different device regardless. No need for house sync or worry.  If the source is a CD player, a synchronous SRC works just fine as long as you are willing to lock the recorder to the source.  If you wish to upsample the CD player to 96K and use a synchronous converter, the DAW can slave to the end of that chain.

It's just a matter of orientation. So synchronous converters work fine if you feed them from the clock source that you wish to use.  If the source is a device that cannot be externally synched, the problem is only slightly more difficult than if you are using an asynchronous converter.

But if you have to keep everything on house sync then BY definition you have to use an asynchronous converter to record the output of a non-lockable CD player. Same as in video you have to use a frame synchronizer (or whatever they're called). No one genlocks to the world anymore.

As for varispeed, already cited, if you want to preserve the pitch shift then you cannot use a synchronous SRC.

So we keep some asychronous converters around when we encounter those situations.

In 99.9% of the cases around here the sources we have can be locked externally. We solve the house sync problem by using both an upsampling and downsampling synchronous converter. Say we want to upsample a LOCKABLE CD player to 96K. I feed house sync (96K) to a synchronous downsampler to 44.1, lock the CD player to that, and then capture the output of the CD player through the synchronous upsampler. Works fine.

In fact, I upsample and downsample synchronously in mastering almost every day. Source is a DAW at 44.1K, upsampled to 96K, through a bunch of processors, and then downsampled to 44.1 to capture in the DAW. Everything is synchronous.

BK
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.

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #24 on: September 17, 2005, 06:32:11 PM »

Alan Meyerson wrote on Sat, 17 September 2005 12:42



I'm doing it this way to be able to record my orchestra tracks at a high sample rate. Alot of times, I'm limited to recording orch at 44.1 or 48 depending on the project.
This is one of those times I have an option. My pre-records are at 44.1.

So, my choices are
- record orch at 44.1
- record orch at 96k (or 88.2) and real time downsample my orch at the mix to my pre-records sample rate
- record at 96k and real time UPSAMPLE my pre-records at the mix ..my choice.





I would think of the 96K as your "house sync" and upsample the prerecords to 96K in real time. If you had time, you could upsample them another day, when the clock is not ticking with conductor and orchestra. I'd feel more comfortable about it than doing it on a live session with orch, myself.

I suspect you need to downsample the 96K to 44 in order to lock the prerecords. If you have ANY doubts about the integrity of the SRC then definitely record to 88.2 K instead.
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 #25 on: September 19, 2005, 01:26:25 PM »

Bob, You said:

"If you mean that the PLL will go out of lock at a certain temperature, I think that is academic. The output will follow the input for a very wide range of sample rates. If you mean that the PLL in the SRC has a certain sample rate (frequency) acceptance window, it is made pretty wide since jitter of the PLL does not affect the DSP of the synchronous SRC. Fortunately this is not a D/A converter and the distortion of the DSP is completely independent of sample rate or jitter."
[quote title=Quote:]

I say:

No I do not mean that at all. In order to operate synchronously, you need the frequencies to be related by integer related. It forces one to generate 2 sets of clocks that are integer related. If you have two external clocks (one at 44.1 and the other at 96KHz) that are derived from the SAME CLOCK SOURCE, that it is fine for synchronous SRC. Any drift will effect BOTH clocks so the ratio is maintained.

If you have 2 clock sources (one at 44.1 and the other at 96KHz) where each one is generated from its own SEPARATE CLOCK SOURCE, than it forces asynchronous conversion. You simply can not lock them together, and any drift in one clock, the other clock or both clocks will effect the ratio.

If you have both clocks derived EXTERNALY from one clock and,
If you can apply the 44.1KHz to lock the input to that rate and
If you can lock your SRC output to 96KHz, along with the DAW
Then you are in synchronous world.

But :
If you have both clocks derived INTERNALY inside the SRC, and you want to merge tracks with existing audio on a DAW, your output if not timed to match the DAW. You could try to correct it by having the SRC output act as a house sync. There are times when this is undesirable because it complicates other things. One way or the other, there are many scenarios, enough to confuse the vast majority of users. This is one of the issues that is not well understood by many users.

BTW, I did not know what you meant to say rerading the numbers being integer multiples. In fact, I thought you missed the point, and that is why I wrote the post.

But, I do agree with all the rest that you said.

Regards
Dan Lavry
www.lavryengineering.com  
Logged

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #26 on: September 20, 2005, 11:18:54 AM »

danlavry wrote on Mon, 19 September 2005 13:26




BTW, I did not know what you meant to say rerading the numbers being integer multiples. In fact, I thought you missed the point, and that is why I wrote the post.




Language is so slippery! There were times when I though you lost the point  Smile

BK
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 #27 on: September 21, 2005, 10:43:13 PM »

Thanks everyone.  Session sucessfully completed!
All the best.
Alan
Logged

Schallfeldnebel

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 816
Re: Sample Rate Conversion
« Reply #28 on: October 12, 2005, 02:41:47 PM »

Mr. Lavry wrote: " As an engineer, I pay more attention to technical and less to language, so it is possible I am not using the language properly."

This was about the use of the word a-sync or sync sample rate converters. So, reading this thread I was a bit curious and went up your site, and there I found you designed a samplerate converter, and on your site it is said to be sychronous. I was just wondering, if you meant here also a-synchron.

Erik Sikkema
Logged
Bill Mueller:"Only very recently, has the availability of cheap consumer based gear popularized the concept of a rank amateur as an audio engineer. Unfortunately, this has also degraded the reputation of the audio engineer to the lowest level in its history. A sad thing indeed for those of us professionals."

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Sample Rate Conversion
« Reply #29 on: October 12, 2005, 03:31:02 PM »

ErikS wrote on Wed, 12 October 2005 19:41

Mr. Lavry wrote: " As an engineer, I pay more attention to technical and less to language, so it is possible I am not using the language properly."

This was about the use of the word a-sync or sync sample rate converters. So, reading this thread I was a bit curious and went up your site, and there I found you designed a samplerate converter, and on your site it is said to be sychronous. I was just wondering, if you meant here also a-synchron.

Erik Sikkema


Hi Erik

The Model 3000S has both settings:

1. Synchronous SRC
2. Asynchronous SRC

I recommend using the Synchronous when possible, for the reasons already stated.

I also have a plug in for the LavryBlue, and that one is a Synchronous SRC (a X2 or :-2). On one hand it is a very special purpose device, only for doubling and halving sample rate. On the other hand, it does the cleanest job, and without any of the phase issues of Asynchronous SRC's.

Note how some of the posts about SRC phase in this forum changed from claims of phase match to "almost phase matched", due to having the same rest... The point is - a Synchronous SRC is phase coherent...

Regards
Dan Lavry
Logged

Schallfeldnebel

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 816
Re: Sample Rate Conversion
« Reply #30 on: October 12, 2005, 06:26:28 PM »

Hi Dan,

Can your SRC in sychronus mode be clocked from a second 3000 in sychronus mode?

Erik Sikkema
Logged
Bill Mueller:"Only very recently, has the availability of cheap consumer based gear popularized the concept of a rank amateur as an audio engineer. Unfortunately, this has also degraded the reputation of the audio engineer to the lowest level in its history. A sad thing indeed for those of us professionals."

C-J

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 80
Re: Sample Rate Conversion
« Reply #31 on: October 15, 2005, 03:57:15 PM »

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

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

Could you (easily) explain what a Polyphase Filter means?

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

Thanks Daniel,

Well, I have now read your answer 65535 times, and studied Polyphase filters for a few weeks, not ALL 27000 hits, though. Wink But, somehow, I cannot see the mathematical "beauty" of the polyphase function? I got the impression that ONE purpose, is to (re)use excisting hardware, by running "parallell" processes at higher calculating rates?

From reading Dan's and Nika's writings. I think I understand the basics of FIR filters. We take a chosen amount of coefficients (the sum of which =1, in an LPF), which we then multiply one by one, with the same amount of backward input taps, stored into shift registers. Finally, we add the products of each multiplication. If we want a Phase Linear FIR, we rotate the coefficients, (like CBABC), instead of going back and forth along the taps.

If  we do a 4x upsample, and call the original samples "a", and the new, interpolated samples "b,c,d,", we get a string of "abcdabcd...". If we then use an FIR LPF with 16 coefficients, named "A-P", the 1st subset uses "AEIM", the 2nd "BFJN", and so on... Now,,, some stupid questions. Is the coefficent's sum of each coefficient subset =1, or =1/4?

What taps do we use? The old "a" taps only, or, all "abcd" taps. If so, won't we have to multiply all original "a" tap values by 4, to compensate for the zero valued "bcd" taps? (p159/160 in Nika's book.)

Whichever we use, I can see two choices when we start to multiply the taps by the rotated four coefficient subsets. Either we use the very same four taps, and multiply them in turns by the rotated subsets. Or, we use a total of 16 backward taps:
"n, n(-4), n(-8), n(-12)" for the 1st subset, "n(-1), n(-5), n(-9), n(-13)" for the 2nd subset, and so on... (Here the "n" could point to either "a" taps only, or to "abcd" taps.)

However this is done, I have troubles in understanding why, the use of four rotated subset calculations would be any better, than to use a single set of four coefficients? Anyway, compared to using the 'long' 16 tap filter for each individual calculation, wouldn't all three options yield different output sample values?

Hopefully somebody, now post AES, could find the time to steer me into the right direction.

Lost in polyspace, Sad C.J., Finland
Logged

Jon Hodgson

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1854
Re: Sample Rate Conversion
« Reply #32 on: October 15, 2005, 04:51:25 PM »

Hi C-J

You've almost got it, except you've got the first bit wrong.

When you first upsample, before the reconstruction filter, a stream of samples
AAAAAAAAAAAAAAAAAA

You don't get

ABCDABCDABCD which you then feed into the filter,

what you get is A000A000A000A000

You then feed it through a convolution filter to get

abcdabcdabcdabcd

But if you think about it, a FIR filter is

sample0 * tap0 + sample1 * tap1 = sample2 * tap2... and so on

So at any time, 3 out of four of those calculations will be redundant, so in your case of a 16 tap FIR, only four taps will be required for each output sample, a different set of taps for each output sample in a set of four.



Logged

Daniel Weiss

  • Newbie
  • *
  • Offline Offline
  • Posts: 29
Re: Sample Rate Conversion
« Reply #33 on: October 16, 2005, 07:09:00 AM »

C-J wrote on Sat, 15 October 2005 21:57

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

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

Could you (easily) explain what a Polyphase Filter means?

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

Thanks Daniel,

Well, I have now read your answer 65535 times, and studied Polyphase filters for a few weeks, not ALL 27000 hits, though. Wink But, somehow, I cannot see the mathematical "beauty" of the polyphase function? I got the impression that ONE purpose, is to (re)use excisting hardware, by running "parallell" processes at higher calculating rates?

From reading Dan's and Nika's writings. I think I understand the basics of FIR filters. We take a chosen amount of coefficients (the sum of which =1, in an LPF), which we then multiply one by one, with the same amount of backward input taps, stored into shift registers. Finally, we add the products of each multiplication. If we want a Phase Linear FIR, we rotate the coefficients, (like CBABC), instead of going back and forth along the taps.

If  we do a 4x upsample, and call the original samples "a", and the new, interpolated samples "b,c,d,", we get a string of "abcdabcd...". If we then use an FIR LPF with 16 coefficients, named "A-P", the 1st subset uses "AEIM", the 2nd "BFJN", and so on... Now,,, some stupid questions. Is the coefficent's sum of each coefficient subset =1, or =1/4?

What taps do we use? The old "a" taps only, or, all "abcd" taps. If so, won't we have to multiply all original "a" tap values by 4, to compensate for the zero valued "bcd" taps? (p159/160 in Nika's book.)

Whichever we use, I can see two choices when we start to multiply the taps by the rotated four coefficient subsets. Either we use the very same four taps, and multiply them in turns by the rotated subsets. Or, we use a total of 16 backward taps:
"n, n(-4), n(-8), n(-12)" for the 1st subset, "n(-1), n(-5), n(-9), n(-13)" for the 2nd subset, and so on... (Here the "n" could point to either "a" taps only, or to "abcd" taps.)

However this is done, I have troubles in understanding why, the use of four rotated subset calculations would be any better, than to use a single set of four coefficients? Anyway, compared to using the 'long' 16 tap filter for each individual calculation, wouldn't all three options yield different output sample values?

Hopefully somebody, now post AES, could find the time to steer me into the right direction.

Lost in polyspace, Sad C.J., Finland


See answer by Jon Hodgson which sheds some light. I.e. I should have mentioned that first the upsampling is done by so called zero filling, e.g. in the case of 4 times upsampling there are three zero valued samples filled in between each sample of the original signal. As described by Jon. When you feed that upsampled signal to the large FIR then the "subsets of coefficents" will be used automatically (four subsets for the very same four taps). Yes, the sum of the coefficients in a subset is 1/N for all subsets, N being the upsampling factor. So the amplitude response is constant (which is good) and the phase response is variing for that fractional delay we want to achieve (which is also good).

Daniel

Logged
Weiss Engineering Ltd.
www.weiss.ch

Bogic Petrovic

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 73
Re: Sample Rate Conversion
« Reply #34 on: November 10, 2005, 05:13:14 AM »

Hi all,

danlavry wrote on Sat, 17 September 2005 18:14


.....
Say you have an independent stand alone 44.1KHz source, and you force a synchronous conversion to 96KHz. Say the house sync is at (96KHz + 10ppm), and the source is (44.1KHz -10ppm) (meaning the converted 96KHz is 96KHz -10ppm). Now you have a mismatch between a 96KHz house sync (or DAW clock) and the newly converted 96KHz audio.
You can not just send the audio in - it calls for a new SRC task, from (96KHz -10ppm) to (96KHz -10ppm). This time, your SRC is Asynchronous. At this point, you may have considered a one step Asynchronous 44.1KHz to 96KHz....
....



I agree with you Dan, and in Sample Rate Conversion between two independent clocks there is not such thing that we can call "synchronous", even if ratio is "1:1". Things can be "synchronous" only if we tolerate loss of samples (fifo is full, slave clock is a bit slower than master) or pauses with silence (fifo is empty, slave clock is a bit faster than master).

If we have great probability to see this situation in real world, then we cannot discuss about Synchronous Sample Rate Conversion, because we cannot have independent clocks with precise rational ratios. In this case things are real, not rational... and that means that we have analog behavior, not digital... we must remember that in overall story about digital audio we still have one thing analog - TIME!

Best regards,

-boggy

Graham Jordan

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 63
Re: Sample Rate Conversion
« Reply #35 on: November 10, 2005, 01:16:40 PM »

You certainly can have situations where a synchronous SRC is totally acceptable and does not run into any 'dropping of samples'. And these days I think there are more situations where you can use this - namely DAWs. Yes when transferring digital audio from one clocked system to another independently clocked system (even if they're both nominally the same rate, like 44.1kHz) you need asynchronous SRC unless you can tolerate dropped and/or repeated samples. (e.g. standard CD digital output to any digital device that does extract and synchronise the whole system to that CD clock)

However, if the two sample rates are dependant, then you can do synchronous.

For example: SRC on an audio file - synchronous (as no actual clocks are used, simply the implied clock in the original, and the known exact ratio to the target implied clock).

Another example: a system is running in real time at a certain clock/sample rate, and uses SRC to send data out at a different rate, where the output rate is exactly locked to the system rate - synchronous.

Also, internal up/down-sampling if needed for processing.

Also mastering etc.

So asynchronous is for independent clocks yes - that's it's definition.

Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation.
Logged

twilightsong

  • Newbie
  • *
  • Offline Offline
  • Posts: 34
Re: Sample Rate Conversion
« Reply #36 on: November 12, 2005, 04:19:35 PM »

I skimmed through the thread

Back to the question of SRC: of late I've been "worrying" about how I downsample to 16/44.1. I've been shown graphical representations of how various products effect the result when doing this. Some of his was admitedly related to salesmanship of a product called R8Brain Pro (Voxengo, $119) which supposedly yields an audibly "cleaner" result

I'm always wary of peeps who say their product is "the best" even and especially when it's NOT a paid endorsement, but I've heard quite a few that this app is so wonderful... I wish I'd never heard of it because I lay in bed at night wondering if I "need" to buy it Very Happy
Logged

Ronny

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2739
Re: Sample Rate Conversion
« Reply #37 on: November 13, 2005, 03:03:30 AM »

twilightsong wrote on Sat, 12 November 2005 16:19

I skimmed through the thread

Back to the question of SRC: of late I've been "worrying" about how I downsample to 16/44.1. I've been shown graphical representations of how various products effect the result when doing this. Some of his was admitedly related to salesmanship of a product called R8Brain Pro (Voxengo, $119) which supposedly yields an audibly "cleaner" result

I'm always wary of peeps who say their product is "the best" even and especially when it's NOT a paid endorsement, but I've heard quite a few that this app is so wonderful... I wish I'd never heard of it because I lay in bed at night wondering if I "need" to buy it Very Happy


The R8Brain won't beat out the Weiss, but it's been holding it's own with and looking better than some of the more common SRC's. The freebie R8Brain has exhibited better results on some tests than the Pro version. You may want to save yourself some bucks and go with the freebie. Also keep in mind with the SRC comparison graphs where the actual noise floor is located.
Logged
------Ronny Morris - Digitak Mastering------
---------http://digitakmastering.com---------
----------Powered By Experience-------------
-------------Driven To Perfection---------------

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #38 on: November 13, 2005, 02:04:42 PM »

Graham Jordan wrote on Thu, 10 November 2005 13:16



So asynchronous is for independent clocks yes - that's it's definition.

Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation.


Although you can put a dependent clock on an asynchronous converter's sync input. Why would you do that? Well, it can sound better. I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock!

The rate converter firmware in the chip's estimate of outgoing sample rate then tracks the incoming rate completely.

BK
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.

Bogic Petrovic

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 73
Re: Sample Rate Conversion
« Reply #39 on: November 13, 2005, 03:27:27 PM »

bobkatz wrote on Sun, 13 November 2005 20:04

Graham Jordan wrote on Thu, 10 November 2005 13:16



So asynchronous is for independent clocks yes - that's it's definition.

Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation.


Although you can put a dependent clock on an asynchronous converter's sync input. Why would you do that? Well, it can sound better. I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock!
....
BK


Hi Bob,

If I understand ASRC mechanism, ASRC can reject overall jitter if we slave its input clock to incoming (jittered) clock, and their output clock to (new, internal, quartz oscillator generated and independent) "jitter-free" clock. ASRC has their own oscillator, but in slave mode we can use more stable clock oscillator than this included in chip. Our MASTER clock can be ovenized quartz crystal oscillator with good power supply. This realisation isn't cheap but we may have lowest jitter as possible today. Main role in this play ASRC.

IFAIK, there isn't a request for integer ratio within input and output clocks.

Your incoming clock can be 47.998kHz and outgoing 44.105kHz, ASRC can do this. Even, incoming clock can be 47.998 and outgoing can be 48.006, ASRC "adjust" samples to outgoing clock, and we have new stream without low frequency jitter down to about 3-4Hz. Also, ordinary PLLs cannot reject low frequency jitter well, because their VCAs has bigger noise at this frequencies. Simply, PLLs generate their own, and new jitter at low frequencies.

Jitter can be fighted only relative to jitter-free clock. ASRC don't synchronise clocks, but make new samples regarding to new jitter free clock, and then we have signal without input clock jitter, only with output clock jitter. And this clock we can keep to be virtually "jitter-free".

In telecommunications, low frequency jitter and lowest frequency wander, is attenuated with ADC, DAC and with software in microprocessor... this means "software" PLL. ASRC is one great  and very low-cost idea when we have problems with jitter at low frequencies. Ordinary PLLs cannot attenuate low frequency jitter well.

There is also problem with high frequency ratios in PLLs used in digital audio, good rule of thumb is that input and output frequencies may be in 1:2 ratio, if we need good jitter attenuation... but when we have 1:64, or 1:128 ratios in digital audio... this is a hard job for ordinary PLLs.



best regards,

-boggy

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #40 on: November 13, 2005, 04:02:48 PM »

boggy wrote on Sun, 13 November 2005 15:27

bobkatz wrote on Sun, 13 November 2005 20:04

Graham Jordan wrote on Thu, 10 November 2005 13:16



So asynchronous is for independent clocks yes - that's it's definition.

Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation.


Although you can put a dependent clock on an asynchronous converter's sync input. Why would you do that? Well, it can sound better. I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock!
....
BK


Hi Bob,

If I understand ASRC mechanism, ASRC can reject overall jitter if we slave its input clock to incoming (jittered) clock, and their output clock to (new, internal, quartz oscillator generated and independent) "jitter-free" clock.




Unfortunately it does not work that way. When the output clock is a crystal clock, the output clock itself may be relatively jitter free, but the output data stream still may contain artifacts (distortion) of the jitter from the incoming clock, minus the jitter rejection qualities of the ASRC's digital phase locked loop. What the ASRC does is to change its sampling filter as a continuously running estimate of the incoming sample rate and it is the continuously-running estimate of the sample rate ratio that causes potential distortion in the outgoing data.

However, as I pointed out, the TI chip has a unique situation in which it COMPLETELY (100%) rejects the jitter from the incoming clock if the outgoing clock is slaved and framed to the incoming clock (e.g. EXACTLY 1/2 or 2X the incoming clock and derived from the incoming clock's edges). It doesn't even matter if the incoming clock is very jittery and the outgoing clock is jittery in this unique case, the ASRC's sample rate estimation filter is slaved to the relationship between the clocks and therefore jitter-insensitive, if you get my drift.

BK
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.

Bogic Petrovic

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 73
Re: Sample Rate Conversion
« Reply #41 on: November 13, 2005, 05:52:02 PM »

[quote title=bobkatz wrote on Sun, 13 November 2005 22:02]
boggy wrote on Sun, 13 November 2005 15:27

bobkatz wrote on Sun, 13 November 2005 20:04

Graham Jordan wrote on Thu, 10 November 2005 13:16


I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock!
....
BK


Hi Bob,

If I understand ASRC mechanism, ASRC can reject overall jitter if we slave its input clock to incoming (jittered) clock, and their output clock to (new, internal, quartz oscillator generated and independent) "jitter-free" clock.




Unfortunately it does not work that way. When the output clock is a crystal clock, the output clock itself may be relatively jitter free, but the output data stream still may contain artifacts (distortion) of the jitter from the incoming clock, minus the jitter rejection qualities of the ASRC's digital phase locked loop. What the ASRC does is to change its sampling filter as a continuously running estimate of the incoming sample rate and it is the continuously-running estimate of the sample rate ratio that causes potential distortion in the outgoing data.



Can you point me out to any documents about this phenomenon.
I'm interested about issue when we have independent or dependent clocks but with near 1:1 ratio. REP forum probably isn't a place for discuss that deep theory.  Smile

Quote:


However, as I pointed out, the TI chip has a unique situation in which it COMPLETELY (100%)



100%? Sounds pretty good for me Smile

Quote:


rejects the jitter from the incoming clock if the outgoing clock is slaved and framed to the incoming clock (e.g. EXACTLY 1/2 or 2X the incoming clock and derived from the incoming clock's edges). It doesn't even matter if the incoming clock is very jittery and the outgoing clock is jittery in this unique case, the ASRC's sample rate estimation filter is slaved to the relationship between the clocks and therefore jitter-insensitive, if you get my drift.

BK


You provide a great information for me.
Unfortunately, as I expect, ASRC chips works only near to same principle... this is a yet another compatibility problem.
Umm, I'm already tired a bit about digital audio "compatibility" issues.  Smile

Many thanks.

Best regards,

-boggy

bobkatz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2926
Re: Sample Rate Conversion
« Reply #42 on: November 18, 2005, 07:03:02 PM »

boggy wrote on Sun, 13 November 2005 17:52



Can you point me out to any documents about this phenomenon.
I'm interested about issue when we have independent or dependent clocks but with near 1:1 ratio. REP forum probably isn't a place for discuss that deep theory.  Smile





Bob Adams' original paper on the theory and practice of the Analog Devices 1890 chip would be the place to look. It was a very thorough review of the technology behind that chip. I have no idea where to find that paper today, it was written long before even PDFs were popular.

I may have a paper copy somewhere in my file boxes.

BK

Quote:



You provide a great information for me.
Unfortunately, as I expect, ASRC chips works only near to same principle... this is a yet another compatibility problem.
Umm, I'm already tired a bit about digital audio "compatibility" issues.  Smile




I think this situation is unique to the TI chip. I've never seen it documented on any other chip. The other competitors are the Analog Devices 1896, and the Crystal 8420 (I think that's the number). Nudge, nudge, wink, wink... the Crystal chip is the one to have!

BK
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.

Bogic Petrovic

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 73
Re: Sample Rate Conversion
« Reply #43 on: November 19, 2005, 11:27:54 PM »

bobkatz wrote on Sat, 19 November 2005 01:03


....competitors are the Analog Devices 1896, and the Crystal 8420 (I think that's the number). Nudge, nudge, wink, wink... the Crystal chip is the one to have!

BK


Nevermind, i think that Cirrus Logic (ok, Crystal Smile ) has new one... CS8421.
One interesting ability of this chip is 32bit non-dithered output stream. Input stream can also be 32bit.


Best regards,

-boggy

Deep White

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 91
Re: Sample Rate Conversion
« Reply #44 on: November 20, 2005, 11:13:57 AM »

Dear All,

I'm not sure if this question belongs to a minor league, but what do you think about the SRC in Samplitude?
Logged
Arys Chien
Song Writer & Producer
Deep White Studio
Taipei, Taiwan
Pages: 1 2 3 [All]   Go Up
 

Site Hosted By Ashdown Technologies, Inc.

Page created in 0.067 seconds with 20 queries.