 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
65.222.68.3
http://www.diyhifi.org/forums/viewtopic.php?t=1027
Follow Ups:
I asked the question to the Lavry tach supoort some times
ago.
Anyway the DA-2002 is non sigma-delta which should
make the diff. Remember the sound of old multibits
players....Here is the answer.
Ciao.
********
Hello-The prices are:
DA-2002 $8,500.00
DA 10 $975.00
The DA-2002 and DA 10 both use synchronous up sampling at 44.1 kHz or 48 kHz.
This is different than the asynchronous sample rate conversion used in the DA
10’s “wide” lock mode or some of our competitor’s DA converters.The type of synchronous up and down sampling used in Lavry converters utilizes
much simpler and thus more accurate math to change the sample rate in even
multiples of the original. In the case of the DA-2002 or DA-10, the lower
sample rates are simply doubled to 88.2 or 96 kHz before conversion.The asynchronous sample rate conversion used in the wide mode of the DA 10
allows non-standard or variable sample rates to be converted. The advantage of
this approach is that the DA converter operates on a stable internal clock,
and is “disconnected “ from the input and any timing inaccuracies it contains
( as long as they are not so extreme that the input cannot “track” the
variations and losses “lock”). This has a lot to do with why other
manufacturers use this relatively simple solution to allow a wide range of
input sample rates and minimize conversion distortion caused by jitter.The DA-2002 and DA 10 also have a “CrystalLock” input circuit which is a more
“purist” approach to the problem of jitter in the digital data causing DA
converter distortion. By using an input memory buffer in conjunction with a
special “tunable” crystal circuit, the internal crystal of the DA converter
can “track” the frequency of the incoming signal and clock the data out of the
buffer at an extremely stable rate. This gives you the “best of both worlds”
because it allows the DA converter to clock from an internal crystal
oscillator that is very close to being as stable as a fixed crystal, while
allowing perfect bit-for-bit transmission of the input data to the DA converter.So in CrystalLock mode, Lavry DA’s are virtually immune to the effect of input
jitter on the accuracy of the conversion.Brad Johnson
I had one a DA10 for a brief period of time. If it were not for the Don Allen player, I'd probably still have it now.The only other thing I will say is I heard no symptoms of ASRC with the DA10. In fact, after hearing several units that had ASRC, it was conspicuous in its absence with this DAC.
HowdyDoesn't that show you that ASRC isn't nessacerily "evil"? For example tho many switching power supplies leave something to be desired, there are some great components that utilize them, and as you've discovered not every DAC that uses ASRC sounds the same. In fact (if I can put words in your mouth) some ASRC DACs can even sound good.
-Ted
I'm going to have to look at this further before stating anything technically-speaking on the subject. I don't want to make false presumptions like I once did with that DSD discussion.I find it curious that Lavry's discussion forum requires a user name and password just to merely look at the forum. It's also interesting that Dan seems to have avoided explaining his side of the story.
I will say I'll be shocked if what I listened to had an ASRC stage in it. For as I said, the symptoms I normally associate with ASRC were striking in their absence.
Question Ted- Do normal "synchronous" oversampling DACs use a clock oscillator whose frequency is actually a multiple of the media's base sample rate? (I could maybe look up some designs and do the math.) It seems like the premise of that whole discussion is the notion that a clock oscillator that is asynchronous with the media's base rate can only do asynchronous conversions. Thanks.
HowdyIf it's synchronous it does indeed have to be directly derived "synchronously" from the input clock. Usually in small integer ratios, e.g. upsampling from 44.1 to 88.2, 176.4, etc. You can do any integer ratio by first upsampling then downsampling.
To get rid of jitter you may use a local clock and buffer, but since you are synchronous you never have to worry about getting too far ahead or behind so you never need to resample the input data or interpolate it.
It is definitely the case that asynchronous input and output clocks imply that you have to do ASRC. I speculate that one of the benefits of picking a specific output clock freq and doing ASRC to it are that you can better control the jitter and other clock accuracy with a fixed rate clock and you can also better control the accuracy and resolution of a fixed freq reconstruction filter. Also by choosing a output clock that's weird, i.e. not near simple integer ratios of the input clock, you avoid the phasiness (flanging) you get as the input and output clocks go in and out of phase, well actually you sort of whiten it. Whether these make up for the degradation of the input data would depend on the implementation.
Just as a refresher of SSRC, conceptually you upsample by the numerator of your ratio, then filter out everything over 1/2 of the lowest of the input clock rate and the output clock rate and then down sample by the denominator. To upsample you can just put in zero samples between the real samples, e.g. to upsample by 55 you put in 54 zero samples between each input sample. To downsample you throw away the samples you don't want, e.g. to downsample by 47 you throw away 46 of every 47 samples. Clearly there is a lot of math to be saved by not calculating the samples you don't use and also you can take advantage of all of the zeros in the input to save work on the filter. So if you are SSRC by 55:47 there have to be 55 output clock cycles for each 47 input clock cycles.
-Ted
The original question I had was whether it was requisite for the clock oscillator to be an exact multiple of the sample rate to execute synchronous sample-rate conversion. (I see it being a major help, but I'm not sure if it's requisite. I'd personally use such an oscillator.) The original answer you gave provided the impression that I may not have stated the question clearly.I thread we ended up on was totally off of this topic. If I learned anything, it's the origin (or near-origin) of the "zero-stuffing" myth. And I cannot blame you or Christine for thinking that, for it's from a data sheet from a reputable semiconductor manufacturer, not an outside audio designer speculating how the process works.
HowdyI don't base my understanding on the data sheet from a manufacturer. I worked with the people who originated the current ASRC algos that many of the manufacturers use and also I have taken classes in school where this stuff (e.g. SSRC) is considered elementary. I have implemented both for myself as well as for companies I've worked for. I strongly recommend that you take a class or two or at least implement some of this stuff for yourself to get a better idea what's going on before you spread more unfounded rumors about this stuff.
I'm sorry that I also didn't make it clear that if there are two clocks that if they are not synchronized (i.e. that in the long term the ratio of the clock rates doesn't exactly match the ratio of the sample rates to the nat's ass) then you have to do ASRC conversions or worse.
-Ted
It almost looks like the root of our disagreement is over the "soundness" of ASRC for audio playback. You think the it's a true advancement. I think it's a technological fraud.I tried explaining why it's a technological fraud. The only other thing I will say is I cannot stand how it sounds.
By the way, the Lavry accusations are mostly speculation. The nuts and bolts of what's going on are not established, and I generally just avoid such feuds, unless I see something factually wrong or something factually true claimed to be wrong. But hardly anything there is factual, just merely speculative. (It's hard to figure out speculation, because it's hardly ever concept put into writing.) I presume Dan will explain the story, and I'm 99 percent certain his DAC in normal playback does *not* use ASRC. (This is something that I'm certain would pass a DBT, if it comes down to that.)
HowdyYou are putting words in my mouth. I've stated over and over that tho I'm not a fan of ASRC in principle, I have and know of DACs that use it that sound fine.
There are more than one source (including Lavry) that talk about the components actually used. Go look at the data sheets. It's not speculation. As with all technologies there trade offs one to another and in addition there are good and bad implementations.
-Ted
"To upsample you can just put in zero samples between the real samples, e.g. to upsample by 55 you put in 54 zero samples between each input sample."Oh man, I never thought you would say that.....
The so-called "zero-stuffing" myth.... That's not how upsampling works....
If this actually took place in D/A conversion, the resultant signal wouldn't even sound like a music signal.... (You may want to ask- What's done with those "zero samples?" And how does the output of ASRC conversion still sound like a recognizable music signal?)
The samples may be "cleared" initially, but then these samples are populated with calculated values (aka "interpolation"), by means of a mathematical process called "convolution." The basic function of all FIR audio filters, and a process that should occur with anything that upsamples or oversamples. For it's at the very core of a digital filter's function.
ASRC involves convolution based oversampling (albeit not necessarily precise mathematically, due to shortcuts needed to attain such a high sample rate). Due to the high sample density, the output clock just has to "grab" the nearest sample for D/A conversion. The problem is the calculated value isn't ideally precise (due to limitations in processing power) and and jitter on the input gets transformed to noise components on the output.
HowdyPerhaps you didn't notice that I said "Just as a refresher of SSRC, conceptually you upsample by the numerator of your ratio, then filter out everything over 1/2 of the lowest of the input clock rate and the output clock rate and then down sample by the denominator."
It's that filtering that does your interpolation. There are of course other methods of interpolating but they are heuristics. The method I outlined is the mathematically correct one...
-Ted
The question is what does the data look like *between* the upsampling (numerator) and downsampling (denominator)? I'm certain this is **not** trivial. It's very critical. The most critical part of such conversion.If zero-stuffing actually takes place in the upsampling (with no further calculation before downsampling) that intermediate data would be a zero signal with periodic spikes of the original signal. This is the signal that would then be downsampled. But the downsampling just cannot "restore" that signal.
I think the root of the misconception the notion of filtering and oversampling being two separable or different things. But they're not. The oversampling is where the filtering takes place. Oversampling *is* the digital filter.
Chiming in here. Don't even remember whose post I'm responding to (so Ted I'm not picking on you ok?)Again a lot of confusion, but then industry has done its darnedest best to confuse this for all, not?
You're all pretty close (even Todd, in a way ;-) so there is not much reason for argument. All together in a room with a whiteboard? I'd be glad to. Who's bringing the wine?
Just a couple of remarks, linked to the zillions of posts around this thread.
1) Why did ASRC make it to consumer audio? Because marketing/sales needed a reason to shift more gear. Because DVD was all 48/96/192 (CD should have been 48, too ;-), and they wanted to cash in on the 96/192 buzzwords. How does ASRC sound to them? Easy: like the opening bars of that Pink Floyd song ... That's ALL what matters at the corporate level. And yes, even audio-noble companies like dBS would go that low to shift more gear that way. Especially with the consumer audio world being what it is.
2) Mathematically there is not much wrong with ASRC. Build one for yourself with Matlab and see/listen. Of course, if you have to put one in half a square mm of silicon things look slightly different ...
3) Figure 4 in that AD note is OK. Nothing wrong with it, actually.
Especially 4d, Yes Todd, 4d is correct. Adding zeroes in a dirac-impulse sample train does not alter its informational content or its spectrum. It only moves the stream sample frequency ('enlargens the unit circle'), so that some of what before was above fs/2 (images), now sits below fs/2.
If just zero-stuffed, would the signal sound like music? Of course. It would be like a NONOS DAC. I could generate you music samples of 48kHz baseband, and then the same stream with 2x zeroes (96k) or even 4x (192k). Can you replay such files?4) Damn, I forgot what I wanted to say ...
Cheers,
W
"2) Mathematically there is not much wrong with ASRC."Very true. Because no standard criteria was ever established to define "correct" in this regard. Hence no basis to claim it's doing something wrong, objectively speaking.
But my ears tell me there's a lot wrong with ASRC. But in the scheme of things, it's only one man's opinion.
And while I've explained the flaws of ASRC, it's nothing more than a theory of mine. It's never been proven unequivocally. Although I'm starting to see this "transformation of jitter to noise" show up from other critics of the conversion method.
*** Because no standard criteria was ever established to define "correct" in this regard. ***Check out the link provided below, which is a pretty comprehensive evaluation of various professional resampling algorithms using a variety of tests.
A "correct" SRC algorithm should have a "perfect" passband, and "infinite" attenuation past the passband. In addition, there should be no additional harmonic distortion generated.
The criteria is simple, but very difficult to achieve. As you can see from the link provided, very few SRC algorithms perform well. I was shocked at how bad the resamplers built into well regarded software such as Pro Tools, Pyramix, SaDiE, etc. are.
I would imagine hardware/silicon based SRC would be even worse, due to limited computation power and precision.
Although the examples used in the link provided are based on downsampling 96kHz to 44.1kHz, I have discovered through my own tests that the artefacts generated by upsampling are very similar.
So basically whenever someone gushes about how good "upsampling" sounds, it's conceivable what they are hearing are artefacts generated by SRC.
So I think we are all agreeing (you, me, Ted, Werner, etc.) that theoretically there should be nothing wrong with SRC (ASRC, SSRC, etc.) but practical implementations leave much to be desired, notwithstanding that sometimes the results may be euphonic.
"*** Because no standard criteria was ever established to define "correct" in this regard. ***"The criteria exist and are a trivial extension of Nyquist-Shannon. Tackling ASRC is nothing more than combining standard good-practice AA or AI filtering with a suitable form of interpolation (you need *something* to get from fs1 to fs2), plus a compensation for the sampling-peculiarities of the chosen interpolation method. Nothing of this is conceptually very hard, although correct implementations are not feasible in cheap silicon. But with software, or custom/over-engineered silicon, it can be done very well indeed.
"As you can see from the link provided, very few SRC algorithms perform well. I was shocked at how bad the resamplers built into well regarded software such as Pro Tools, Pyramix, SaDiE, etc. are."
(Hey, they updated their comparison site! Now it shows the raised wide-band noise floor of Audition.)
Yes. But a more interesting shock is to learn that some, often cheap, implementations are near-perfect. Which proves the point that, conceptually, this is not difficult at all. You have to be thorough, that's all. Apparently that was not the case with the designers of a lot of the pro tools.
*** But a more interesting shock is to learn that some, often cheap, implementations are near-perfect. ***Are you talking about Secret Rabbit Code? I must admit, it performs better than I expected, but I wouldn't consider it "near perfect".
The "winner" in the comparison appears to be izotope 64-bit SRC. Not surprisingly, since the comparisons were done with the input of Alexey Lukin, who is associated with izotope. Still it does demonstrate the advantage of 64-bit precision.
Audition and BIAS Peak fares well, but then I expected they would.
*** You have to be thorough, that's all. Apparently that was not the case with the designers of a lot of the pro tools. ***
I think there's a bit more to it than mere carelessness. Most implementations have to trade accuracy with speed, and many of the tools were originally written when computing power was a lot less than today, and the algorithms haven't caught up with processing power.
Which brings us to the original topic of hardware based resamplers, implemented on a chip, which is typically what is units like the Lavry and the Benchmark DAC.
I would like to see how a hardware SRC performs on the same tests - I suspect the results won't look good (the precision on a hardware SRC may potentially be as low as 24-bit fixed).
"Are you talking about Secret Rabbit Code? I must admit, it performs better than I expected, but I wouldn't consider it "near perfect"."No. Audition, Barbabatch, r8Brain Free, ... compared to most they are pretty neat. And $250 Mac soft Wave Editor contains the iZotope SRC. (Should I buy a Mac now?)
"I would like to see how a hardware SRC performs"
Have a look at the Weiss and the Z-Systems. Don't know about Weiss, but the Z uses a Crystal SRC chip. As you see, many software solutions are much worse. Just bad bad filter design and coding.
bring bac k dynamic range
*** No. Audition, Barbabatch, r8Brain Free, ... compared to most they are pretty neat ***Audition is pretty good, but I wouldn't rate Barbabatch and r8Brain as "near perfect". Perhaps I'm more picky than you.
Even Audition doesn't generate "near perfect" results - in a non ABX comparison I feel the resampled output seems to be audibly inferior. I did some tests on Audition (generated some test wave forms in 44.1k - resampled to 96 then resampled back to 44.1) and the resultant file was quite different from the original (more than 1dB amplitude differences for frequencies higher than fs/4) - even using Audition "999" pre and post filter.
Lastly, these may be "cheap" compared to say Pro Tools or SaDiE but they are mostly limited purpose tools. And they are hardly "cheap" in terms of CPU processing power. Audition for example, in the highest quality mode (999) will definitely not be able to do SRC in real time, even on the fastest CPUs. Therefore impractical in terms of embedding in a player or DAC (which was the original topic).
Even if you could embed a real time "near perfect" software implementation of SRC into a DAC, it would generate so much EMI and dump so much logic induced modulation into the circuits (due to the heavy CPU processing required) that it wouldn't actually serve the purpose of reducing jitter or improving audio quality. There ain't no such thing as a free lunch.
*** Have a look at the Weiss and the Z-Systems. ****
I wouldn't consider either of these to be "near perfect" either. In the Z-System results seem worse than many software implementations (such as the ones you referred to earlier).
*** Just bad bad filter design and coding. ***
As I've said before, not necessarily bad design or coding. Tradeoffs between speed and accuracy are a far more likely reason. For example Michi said some time ago that Sound Forge till version 6 or thereabouts still relied on 486 assembly for many of the core effects - because the code was written a long time ago in a galaxy far far away ... And the code made many quality sacrifices and compromises in the name of speed.
"but I wouldn't rate ... as "near perfect". Perhaps I'm more picky than you."The context of our subthread is the list of comparative tests at the src.infinitewave.ca site. 'near perfect' in that context means the absence of the blatant non-linear and aliasing artefacts that many of the tools display.
"Even Audition doesn't generate "near perfect" results - ... the resultant file was quite different from the original (more than 1dB amplitude differences for frequencies higher than fs/4)"
That's contrary to my experience then. I can't see any gross artefacts from Audition's SRC. As for uncontrolled listening ... yes, of course we feel that something is wrong after SRC ;-)
"even using Audition "999" pre and post filter."
I never use the pre/post filter. A cursory inspection of the SRC's impulse response shows that enabling the additional filter does strange things to the response tails. You'll also see this in the raised wideband noise floor in the measurements at the src. site.
Leaving the filter off and living with a bit of aliasing (I'm only interested in SR reduction) is IMHO a better option. Mind, the ear is pitch-insensitive above ~12kHz, so aliasing in the band 15-22kHz only increases the perceived brightness, and is not perceived as non-harmonic distortion. dCS use this strategy, among others. Also see iZotope in its Mid position.
"Even if you could embed a real time "near perfect" software implementation of SRC into a DAC"
Why would you want to do that? If one wants to increase SR from, say 44.1k, to something higher, in real time, then by all means go for integer oversampling. A 1001-tap 40-64 bit FIR with massively better specs than what you see in typical consumer/pro DACs and filters is perfectly feasible in a modern FPGA. And for the DAC itself it really doesn't matter if it is clocked off a multiple of 88.2kHz or 96kHz.
"*** Have a look at the Weiss and the Z-Systems. ****
I wouldn't consider either of these to be "near perfect" either"Neither do I. But you asked for examples of hardware implementations.
"As I've said before, not necessarily bad design or coding. Tradeoffs between speed and accuracy are a far more likely reason"
Oh yes. Many of the results on that website originate in either ignorance or contempt for the object at hand (music!). This is (mostly) all software intended for batch processing. Speed as such is not very relevant. What's the point of a 10x reduced processing time when the result of it will be - forever - at a /10 quality?
Many of the implementations showcased here are outright unacceptable for a signal processing point of view, and I really cannot think of a valid excuse for that.
*** The context of our subthread is the list of comparative tests at the src.infinitewave.ca site. ***Well, I was referring to the context of the original post, which was about whether the DA10 used ASRC or not.
*** I can't see any gross artefacts from Audition's SRC. ***
Try it yourself. Generate a 16-bit test waveform (mine was two sine waves sine-modulated in frequency and amplitude) in 44.1, upsample to 96, then downsample to 44.1. Invert phase then add back to original signal.
If everything worked, you should get a zero signal. Otherwise, it's a good way of seeing what the resultant artefacts are. The results may or may not surprise you.
*** As for uncontrolled listening ... yes, of course we feel that something is wrong after SRC ;-) ***
Actually, no. it was the other way around. In my naivity, I was expecting SRC to be transparent, but my ears kept telling me something was wrong. So I generated some test signals (per above) and they surprised me. I only found out about the src.infinitewave.ca site much later.
*** Why would you want to do that? ***
Again, remember the original context of this thread - the use of (A)SRC in DACs as a jitter reducing mechanism.
*** A 1001-tap 40-64 bit FIR with massively better specs than what you see in typical consumer/pro DACs and filters is perfectly feasible in a modern FPGA. ***
Actually, I am not so sure. I am happy to be proved wrong, but I suspect it's not as feasible as you think. Anyway, try and design one. If you are successful, I think a lot of people will be interested in it.
*** But you asked for examples of hardware implementations. ***
Yes, but it was mainly a rhetorical question. My point was I don't think they will outperform software implementations.
*** Many of the results on that website originate in either ignorance or contempt for the object at hand (music!). ***
I'm sorry, but this is an unfair comment, and is unsubstantiated speculation on your part. Perhaps your comment is true in some cases, but the people I know personally are neither ignorant nor are they contemptous.
*** This is (mostly) all software intended for batch processing. Speed as such is not very relevant. ***
This is an assumption on your part, and incorrect.
Speed is a very important consideration in a DAW - there's no point using up all the CPU doing resampling in a DAW because then you have no room for doing other effects processing. Try and mix over 30 tracks in real time with reverb and EQ and you'll find there's not much CPU left for resampling.
The people who write DAWs actually aim for for a target level of CPU utilization for every effect. You subdivide the total amount of processing power in a typical CPU and you say - let's aim for this % for file handling, this % for the mixing engine, and this % is then available for effects/processing. Otherwise you may end up with a product that doesn't actually do it's job in typical scenarios, and LOTS of unhappy customers.
You could argue that a DAW should have two algorithms - one for real time and one for batch, or perhaps one algorithm that is tunable. That is a fair point, but most people who use DAWs (including myself) do not use them for batch processing. For that, I fire up a wave editor.
*** I really cannot think of a valid excuse for that. ***
A valid reason has been presented to you, but you don't want to acknowledge it.
It's easy to create a batch resampler that produces good results - here's one recipe - use an infinite number of taps (ie. number of taps equal number of samples in file to be converted), do all computations in IEEE double precision, and then dither the result prior to truncation. About an afternoon's worth of coding if you know what you are doing. I can assure you the people who write DAWs and the ones who design filters for DSPs have the knowledge to do this - at least the ones I know.
However, in the real world, in a practical implementation, compromises need to be made. It's actually a LOT more difficult to write an algorithm that is not quite as perfect, but is a lot faster. Many painful decisions have to be made. I know first hand exactly how painful some of these decisions are.
Try and write a DAW sometime that needs to resample in real time. Try and build that FPGA that you alluded to and see if you can make it work in a jitter reducing way in a DAC. Then perhaps you may be a little bit more forgiving towards people who have released commercial products. It's easy to be dismissive and criticize from the comfort of an armchair.
"Generate a 16-bit test waveform (mine was two sine waves sine-modulated in frequency and amplitude) in 44.1, upsample to 96, then downsample to 44.1."If you did so in 16 bit then indeed it is no wonder you got bad results. Now please try again in 32 bit.
"I am happy to be proved wrong, but I suspect it's not as feasible as you think."
At least one such has been inexistence for more than four years now. I think this proves feasibility.
As for building one myself, I'd love to. Who provides the funding?
But I agree we've had a disconnect re speed/real-time/batch processing. I don't care a jot about real-time processing, especially not SRC. This indeed deviates somewhat from the thread's beginning, but then, the distinction real-time <> not-real-time has nothing to do with the core of the problem: how to do SRC properly.
*** If you did so in 16 bit then indeed it is no wonder you got bad results. Now please try again in 32 bit. ***Again, please refer to the original context of this post - using ASRC to reduce jitter in a DAC. The signals usually being processed *are* 16-bit.
*** At least one such has been inexistence for more than four years now. ***
Details? And is it actually used as an ASRC in a DAC? Remember - the question of feasibility is in the context of reducing jitter in a DAC, mere existence is not sufficient proof.
*** the core of the problem: how to do SRC properly. ***
No - if you refer to the original context of the discussion - the problem is not "how to do SRC properly". This has never been the topic of discussion (and I thought we were all agreeing that theoretically there should be no issues with SRC done right) - the issue was ASRC as a method of reducing jitter. What is being traded off here is accuracy, as the ASRC needs to happen in real time, and in a way that doesn't inject too much noise back into the circuit. Not an easy problem to solve.
Some people believe that the penalty that is paid in terms of loss of accuracy through ASRC is too high to pay for the jitter reduction benefit. The examples on src.infinitewave.ca give an idea of the magnitude of potential inaccuracies.
Personally I can see both sides of the argument. Although I would prefer a "bit perfect" DAC - in reality, examples like the Benchmark DAC and the Lavry DAC show that the use of ASRC can result in good sound (hearsay - I haven't actually personally heard either of these).
(I wrote up something lengthier, and then Firefox froze ... oh well, here's the short version.)"The signals usually being processed *are* 16-bit."
You force Audition to work with 16b internal precision. Craps out.
Read file, convert to 32b internal, the do all SRC, then back to
16b. Artefacts gone. Try it."Details? And is it actually used as an ASRC in a DAC? Remember - the question of feasibility is in the context of reducing jitter in a DAC, mere existence is not sufficient proof."
I you read closer you'll know by now that *I* never discussed here anything in the context of jitter or jitter reduction (not one of my pet obsessions, have too many others ;-). Another disconnect? Maybe.
We talked a lot about SRC and concluded that many implementations, even those for non-real-time apps, are utterly faulty. This is worrying. It is also good, because it indicates fields for future improvements.I referred to the existing FPGA as it proves the feasibility of 40b+ accuracy (in fact its 64b internally) audio FIR filtering with 1000+ taps. I never claimed otherwise. Yes, it is only used in a DAC as SSRC. I feel confident that using same technology (trust me, I know more than a thing or two about ASIC and FPGA design, and image processing, for the matter) can yield an ASRC that runs rings around something like the AD1896. Luckily, as it would cost a couple of orders of magnitude more.
"the problem is not "how to do SRC properly". This has never been the topic of discussion "
Well, since you pointed to src.infinitewave.ca and since that site indicates that SRC is almost never done right, methinks it became part of the discussion, not?
*** You force Audition to work with 16b internal precision. Craps out.
Read file, convert to 32b internal, the do all SRC, then back to
16b. Artefacts gone. Try it. ***I'm sorry, but this is irrelevant, and also incorrect. I didn't "force" audition to work with 16bit internal precision (I can't anyway, because Audition always works internally at 32-bit fp precision. This has been true since Cool Edit days).
Remember: the original context was you claimed you have never seen SRC artefacts in Audition. I gave an example in which you can experience SRC artefacts in Audition. The example is also valid in the context of the topic of discussion.
Rather than exhorting me to "try it", why don't *you* try it, and show us the results. That way, *you* can make sure you are not "forcing" Audition to do anything.
*** I you read closer you'll know by now that *I* never discussed here anything in the context of jitter or jitter reduction (not one of my pet obsessions, have too many others ***
I'm sorry, but what you are obsessed about or not is irrelevant. You joined a topic about ASRC in DACs, and usually it's polite to try and stay within topic. If you want to talk about something else, start a new topic.
*** I referred to the existing FPGA ***
You still haven't provided any details. Which existing FPGA?
*** We talked a lot about SRC and concluded that many implementations, even those for non-real-time apps, are utterly faulty. ***
No, you concluded that they were faulty. I drew a different conclusion.
*** Well, since you pointed to src.infinitewave.ca and since that site indicates that SRC is almost never done right, methinks it became part of the discussion, not? ***
Can you show me exactly where on that site does it state that "SRC is almost never done right"?
That was an extrapolation and speculation made by you. All the site did was provide graphs. My view is that the graphs are consistent with the hypothesis that SRC implementations are a trade off between accuracy and speed. This trade off is important in the context of the topic of discussion (ASRC in DACs). If you want to discuss a different topic, such as "faulty" SRC implementations and the competency of the implementers, start a new thread :-) I may even join you there!
HowdyThe point is that you don't have to filter both as a part of upsampling and then again as a part of downsampling. One filter in the middle at the lowest of the two Nyquist freqs is sufficient.
You save boatloads of work by simply zero stuffing, then filtering then simple decimation. I'm not trying to minimize the work or the details of implementing a good filter, but you only need one and (if your numerator is larger than your denominator) you are at a higher sample rate where the filtering is easier.
You used the word "oversampling" not me. I try to avoid words taken over by marketing, etc. I was talking about SSRC which is a general method for changing the sample rate by a fixed integer ratio. It isn't oversampling, undersampling, etc. it is synchronous sample rate conversion and I outlined it at the conceptual level (i.e. the block diagram you'd see in a signal processing text book.)
-Ted
As long as the output sample rate is higher than the input sample rate.You can call a conversion from 44.1 and 88.2 "sample rate conversion", "oversampling", or "upsampling". But if "zero-stuffing" is done in any such conversion instead of interpolation, it's just not going to sound right.
HowdyYou need to read and understand a basic digital signal processing book or take a class in the subject.
The interpolation you talk about is the digital filter I'm talking about.
The process of zero stuffing followed by (digital) filtering at 1/2 the input clock freq is exactly the correct way to raise sample rates by an integer.
The process of filtering at 1/2 the output clock rate and throwing out all but every Nth sample is exactly the correct way to lower sample rates by an integer N.
The process of zero stuffing followed by (digital) filtering at 1/2 the lowest of the input and output clock freqs and then throwing out all but every Nth sample is exactly the correct way to synchronously sample rate convert by an integer ratio.
If this isn't clear I'm sorry but I'm dumbfounded in that I don't know where to start to make it any clearer.
-Ted
The problem is, Ted, is people mention the zero-stuffing part, and not the interpolation part. And then equate oversampling to zero-stuffing with no further process.Personally, what should be omitted is the "zero-stuffing". In the whole process, this part is trivial. (I personally would have called it "new placeholders" for the interpolated data.) The "interpolation" is the important part of oversampling. And it shouldn't be treated as separate from oversampling. Because it cannot even be executed without oversampling.
In fact, Ted, it's been used by some CD player and DAC manufacturers to dupe customers into thinking oversampling is "zero-stuffing" and interpolation is an "innovation" by the manufacturer!! Most people don't even realize it's deceptive advertising.
And I'm sure there have been quite a few products brought to market based on misconceptions about oversampling. I think the number of products that mangle the signal to be alarmingly high.
And then audiophiles complain about the sound, and engineers complain about audiophools criticizing what they think are products of superior fidelity.
And in practice, I'm not sure if the zero-stuffing part even takes place!! The oversample values may just as well be overwritten once the new data replaces the old. Had the concept been stated that way, there wouldn't have been so much confusion.
HowdyManufacturers aren't as technically illiterate as you make them out to be. Some (dCS for example) chose to use interpolation strategies that aren't based on filtering (and hence aren't mathematically optimal) they may be better by some other criteria (perhaps the designer's ear) and they are certainly less math. Most designers put their mark in by making different choices of how to implement the filter, e.g. FIR vs. IIR, minimum ripple or minimum phase...
Of course zero stuffing takes place in SSRC, you simply avoid multiplying by the samples you know are zero.
Like I said before, you should really implement these things for your self so you get a feel for them. If you can't implement a FIR filter with the desired impulse response or filter shape then you shouldn't be speculating about how these kind of things work.
-Ted
I think misconceptions of classic oversampling played a major role in asynchronous conversion getting off the ground.ASRC, in my humble opinion, is a process that should have never found its way into consumer digital audio playback products. It was originally intended to convert data for transfer from one media format to another, not necessarily in real time.
But technically-corrupt products do make it to market when sound concepts are mis-characterized. And very few concepts have been a bigger victim of this than classic oversampling/digital filtering. The "old fashioned" 8x oversampling IMO is still the best method of digital filtering that we have. Where the innovation lies is in the FIR filter function, which is still the one part of CD playback design that I think has room for vast improvement.
HowdyYou continue to speculate about cause and effect of things you have no personal knowledge about.
-Ted
.
HowdyYou should have heard jj in person about some of the people here :)
-Ted
.
I found it hilarious last year when he got so incensed he started accusing me of things that Todd had said :-)I will admit I baited him a little, but I didn't expect him to swallow the bait, hook, line and sinker and then choke on it :-(
Check out Figure 4c and accompanying text on page 3 on the following link.
This is the first time I've seen "fuzzy" information on a chip data sheet, that could be interpreted totally wrong. Looking at the age of the data sheet, I think it was more an oversight than a deception.It deals with the paragraphs and Figure 4. Starting at "To the Rescue"....
Figure 4 shows how oversampling filters work in both the time and frequency domains. We start with a sampled signal at 44.1 kHz (Figure 4a), which has images in the frequency domain (Figure 4b). The next step in the process is to increase the sample rate of the digital signal by inserting zero-valued samples (Figure 4c), resulting in the spectrum shown in Figure 4d.
The root of this whole problem deals with the "analog traces" superimposed with the digitized signals in Figure 4. Projecting the impression that "zero stuffing" would have no impact on the signal, at that particular stage, if it were to be converted to analog. Technically Figure 4c does show the "spikes" with a "zero signal," as I stated earlier. But the "analog waveform" pictured in Figure 4c does *not* depict what the waveform would look like if it were to be converted to analog at that particular state. It's just a representation of the **input** analog signal, to provide reference.
But instead of providing reference, the analog traces in Figure 4 provided confusion.
The one picture that is factually incorrect is Figure 4d. It would *not* be identical to Figure 4b. (Along with the analog trace, this induces the misconception.) There should be "much taller" spikes present at the sample frequency and all harmonics. (44.1 kHz, 88.2 kHz, etc.) Because the signal has been converted to a pulse train whose fundamental frequency is the base sample rate. (If I were to re-write this white paper, I'd remove Figure 4d altogether.)
The low pass interpolation filter, mentioned afterwards, is where the digital filtering actually takes place. The "zero values" does not filter anything. It's just a pre-stage for the digital filter. The final reason for the misconception is this is never mentioned explicitly.
The sad part is this ambiguity has caused a big misconception. Zero-stuffing being what solely occurs with oversampling. Which has gone as far as being accepted fact across the audio engineering community. (I've even heard this misconception applied to digital radio applications at a place I used to work at.)
And it may have even compromised or corrupted some designs along the way.
But at the time this white paper came out, I don't know if anybody would have known enough about oversampling (aside from those within the chip manufacturers themselves) to have caught this.
And since this has evolved into accepted misconception, the only way to realize it's a misconception is to literally "field strip" the individual elements that make up the oversampling/digital filtering process.
*** Zero-stuffing being what solely occurs with oversampling. Which has gone as far as being accepted fact across the audio engineering community. ***I don't think anyone is saying that. Not Ted, not the paper, and certainly not myself.
You will note I said "zero-stuffing followed by a digital filter works", and NOT "zero-stuffing (by itself) works"
*** And it may have even compromised or corrupted some designs along the way. ***
Can you give some actual examples?
"Can you give some actual examples?"The fact ASRC is even present in digital playback is the prime example.
And the sheer denial without explanation, going on all the time. It's maddening. Call me whacked all you want.
I'm putting stuff up on public record, and putting my real name on the line. I'd be thrilled to one day have all of you in the room, with nothing more than a huge white board. People are treating this like it's rocket science, and it need not be.
There was once a famous line- "If you cannot dazzle 'em with brilliance, baffle 'em with bull...." The statement holds so true, people can no longer distinguish one from the other. And that includes a lot of audio designers.
The bottom line is that for 20 years, the sound of digital mostly sucked. And it sucks now. And too many people would rather blame the end user for their delusions of "golden ears" than come to the reality that designs are not nearly as good as they've claimed.
Too much blind belief and consensus, not enough investigation. This is at the very core of why I think the audio industry is corrupt.
I'm not a big fan of ASRC myself.And I'm sympathetic to the view that potentially some designs are making it a lot more complicated than it needs to be.
My personal view is that digital "by the book" can sound pretty good (ie. an "application note" design using a flagship DAC without any fancy frills, or reclocking, or up/over-sampling, or weird output stages). Provided of course you can feed it a reasonably jitter free signal. Problem is achieving that "reasonably jitter free signal" :-)
You could always go directly to the source and ask Dan Lavry at http://www.lavryengineering.com/lavry_forum/ and see what he has to say. He is a very active participant there and often gives very detailed answers to questions.
Goto http://www.diyhifi.org/forums/viewtopic.php?t=1027 and you will see that all input sample rates are reclocked to 117 kHz !!
HowdySRC === Sample Rate Conversion (either synchronous or asynchronous)
SSRC === Synchronous SRC ("Simple" up/down sampling by "small" integer ratios, the output clock is derived from the input clock in the exact inverse ratio)
ASRC === Asynchronous SRC (Up/down sampling by a essentially arbitrary ratio, input and output clocks are independent (or at least not related thru the SRC device))
The link you provided is pretty clear that the Lavry is ASRC and SRC :)
-Ted
Yes, I meant SSRC or ASRC.
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
