 
|
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 |
80.66.130.220
In Reply to: Re: Nope posted by Todd Krieger on February 24, 2007 at 18:28:37:
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
Follow Ups:
"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!
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 © 2023, Audio Asylum, all rights reserved ]
