|
Home
/ FAQ
/ News Classifieds / Events |
Audio Asylum Thread Printer |
Get a view of an entire thread on one page |
79.73.0.110
In Reply to: RE: @fmak, clarify your conclusions from src.inifinitewave.ca posted by cics on August 04, 2007 at 18:59:32
I shall try to explain. What you are referring to is the band limited signal to noise or signal to harmonics levels and not related to the hf images that I have been referring to. If you look at the link that I posted, you will see that src has significant iamges over the place. Post filtering is important to sonics and really one doesn't know what is going on in a given PC system. There are no measurements in the public domain on usb to spdif or usb converter products being talked about here. Goto diyhi.org on measurements made on usb bridghes and the technical issues surrrounding them and you will see what I mean on hardware and software issues. Also, if you look at PC forums, you will see that usbs are not by any means robust as spdifs. At least there are some published bt Stereophile on SPDIF sound cards that one can use as a performance reference.
What is the point in going from:
PCI to USB
USB to SPDIF and throwing away PCI to spdif systems and not making sure that the outputted SPDIF stream is correct and high quality.???
![]()
Infinitewave’s frequency sweep graph for SRC (Best Sinc).
You raise 2 issues:
1. SRC (as in Secret Rabbit Code) results in HF images all over the place. These HF images are beyond aliasing artifacts arising from bandlimit reduction (96k to 44.1k).
2. Quality and measurement of USB based interfaces.
Looking at SRC (Best Sinc) version, I don't see those HF images you’re referring to (see above image - those purple lines are below -97db). (I have by reply post added scale graph depicting colors to db levels). High noise levels are however visible for the low quality SRC algorithms (Linear and ZOH) which must be NOT be used and nor are they recommended! SRC's website suggests they be used ONLY when CPU is a bottleneck. Best Sinc noise levels are below -97db whether this be aliasing artifacts or the HF images you mention.
More facts need to be addressed on src's (as in Sample Rate Converters). This also applies to SRC (note case sensitivity).
a. Algorithms based on real numbers (32 & 64 bit float) are superior to integer only ones. 16 bit allows for 65536 signal variations whilst 24 bit allows for ~16.8m (256 times more). Rounding errors arising from integer algorithms will result in less accurate signal amplitudes. You definitely want to avoid this. SRC, R8Brain, Audition etc use float. Integer multiples of original sampling (as in 44.1 -> 88.2 vs 96) is not a factor ito quality when using correct interpolation - see point c.
b. Upsampling from 44.1k to 96k has no added noise in the original frequency band. That is, noise is not added up to 22.05kHz whilst above this, noise could occur whose extent is determined by design of the src. Because these artifacts are ultrasonic and at very low levels (e.g. for SRC this would be below -97db) they're not a major concern.
c. Whilst much has been said about 'Noise', more needs to said about the 'Signal'. Audition and other srcs don't provide details on interpolation algorithms employed with some using hybrid techniques. SRC uses a technique known as Bandlimited interpolation. This is based on sound mathematical principles and theorems which recreate the analogue waveform from a given set of bandlimited samples. This is most CRITICAL as other techniques are likely to deviate from the analogue waveform resulting in audible interpolation errors. Of course this is a game of trade-offs involving computational cost, signal accuracy and SNR. With SRC, we have superior signal accuracy at acceptable SNR and can be easily computed using latest generation processors. A poorer choice would entail weak signal quality against excellent SNR. Ideal would be a src using Bandlimited interpolation with better SNR but without undue processing overheads.
On USB based devices, this in itself is not a basis to relegate pc based solutions as problematic. Other interfaces are available (PCI, PCIe, Ethernet, Firewire). USB, Ethernet and Firewire are by design bit-perfect. From an audio perspective this is powerful as upsampled data is dispatched to an outboard device or DAC perfectly. This outboard device adds a quality clock... Like any new development, there will be challenges in its implementation but will be superior to SPDIF which is a lossy interface as it offers minimal error correction capabilities.
![]()
.
Fred,
Look no offense but I don't think this is a credible statement because you have never really got PC audio to work.
You built 3 pc's and complained that none of them even worked. The EMU0404 USB is simple and yet you are pulling your hair out. The lynx card problems listed below and others.
I can point to probably 20 threads on three forums that you have never really got any of this to work.
I think you want this too work but I don't really think you have ever really experienced this type of system really excell as some of the others have.
~~~~~~
Also with regards to what I and others posted on DiyHifi is all based on the PCM27xx series parts. No one said these parts were end all or the best available. They are only the easiest to use.
As for bit perfect... I say you bypass the kmixer and your set. As I stated on Diyhifi, here and head-fi. Consistency on the PC platform is really a problem mainly due to lack of consistent encoding and decoding of music files under Windows.
I think this is were we need to look at the most on the Windows side of the equation.
Thanks
Gordon
J. Gordon Rankin
Gordon
You are beginning more and more to distort the contents of what I said in different posts, stringing them together journalist style.
Just because I built 3 PC and am not satisfied with the best sound cards has nothing to do with the topic in question, or need to go over to usb only; a format that you yourself find flawed.
Watch it, or I may well start to reciprocate.
OK you have 7 or 8 PCs, and all you can do is to tell people to go MAC. Well I don't want to, nor do many others.
Fred