![]() |
Digital Drive Upsamplers, DACs, jitter, shakes and analogue withdrawals, this is it. |
Register / Login
|
In Reply to: Re: You might be interested in this ... posted by Werner on March 2, 2007 at 00:07:15:
*** 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.
This post is made possible by the generous support of people like you and our sponsors:
Follow Ups
- Re: You might be interested in this ... - Christine Tham 16:58:49 03/02/07 (4)
- Re: You might be interested in this ... - Werner 00:31:32 03/05/07 (3)
- Re: You might be interested in this ... - Christine Tham 14:58:30 03/05/07 (2)
- Re: You might be interested in this ... - Werner 23:41:41 03/05/07 (1)
- Re: You might be interested in this ... - Christine Tham 14:10:30 03/06/07 (0)