emmodad

@sunjitwhy = @sanjay: a clarification, the "brutal honesty" comment is not directed at your DAC-evaluation efforts, any interpretation in that regard was certainly not the intended one...perhaps for better clarity i could have written something to the effect of "be cautious in your articulation of "brutal honesty" when posting product observations on CA" rather, the commentary was presented in advice of caution as you go forward, given -- as one example -- incontrovertable evidence that the June Computer Audiophile Symposium attendee list was "sanitized": host and at least one "Sponsor" were active in denying entry in cases where they were uncomfortable with simple but direct technical and Conflict of Interest questions, concerning marketing and their positioned products (for which those persons were a dealer a/o a frequent poster) --- @clay: having known him for years, i would suggest that "daniel" would be the polite manner in which to use daniel weiss' name correctly --- @clay wrt barrows: it would be helpful to understand some brief context about barrows' posts. his activity on the old PS Audio boards was generally not technical, more marketing or product management style (that's no criticism intended, and it's certainly possible he is an engineer who was told to keep it non-techy. i've worked places where our engineers needed be active in front-line contact but also needed to keep some veneer of buffer so they didn't get insanely swamped by having their names public) in any case, barrows' posts here have been helpful observation, primarily anecdotal, not technical (ie the trend in comments about ASRC, and AES3) --- @barrows: as some of your posts are trending toward declarative in nature, touching on concepts of signal processing and data conversion implementation, would you be willing to inform the masses to some degree about your background -- engineering / systems / digital signal processing / analog circuit design / whatever?

@ clay & audioelf - many good points (and yah, "fora" is a high-falutin proper plural form of "forum"; used analogously in several languages but apparently not the "typical use" variant in 'merikun English which prefers "forums") --- too many meds for both me and the dog, at least i'm not taking his by mistake: i realized post-posting, while away from comms, that i had failed to mention one other consideration wrt AES3. as noted, AES3 balanced can certainly be just fine in an appropriate system. ie quality cable/connectors and data Tx and Rx (transmit and receive) subsystems. "quality" need not mean expensive. however in less-well-implemented systems, or even thru the statistical variation of "which equipment manufacturers are diligent in interface design, and which are lazy," there can be variations in system impedences which can lead to signal reflections... the sensationalists and minutae-obsessed will say that this can have Dire Consequences, overwhelming and swamping the ability of the Rx unit to do its job correctly to the point of Stressing it and even perhaps causing (gasp) occasional ERRORS which lead to THE END OF THE WORLD for an audiophile. fortunately, despite these concerns, the world as we know it is still here, and data still flows reasonably correctly via AES3 standard interfaces -- as it has for a few years in the worlds of pro audio and broadcast, IIRC. as one option addressing the issues of perfect impedance matching in balanced Tx / Rx designs, another variant of AES3 exists, AES3ix (where i don't recall the letter for "x"). this uses the AES3 protocol but on 75-ohm coax cabling with BNC connectors. relatively speaking, easiest to engineer for consistent impedance matching; quite commonly found in broadcast environments. this would be a "preferred" AES3 physical interface connector format for sunjiywhy's testing, if available on all equipment. much posting about this here on CA, in head-fi, hoffman, AA, and other fora ...errrm, ahhh, forums. --- there appears to be some possible misinterpretation of my earlier posting's intent. i'm not advocating that the only testing should be FW>AES3>DUTs; just pointing out that to compare one variable -- DAC performance -- there would need be a common datastream at their inputs. what is comes down to is the subtle difference in comparing the {{ item under test for comparison }}: 1/ data from computer source > [ physical interface ] > {{ [ DAC input + DAC processing + DAC output ] }} vs 2/ data from computer source > {{ [ physical interface ] > [ DAC input + DAC processing + DAC output ] }} re: 1/ if the objective is to discern DAC output differences from the same data source, test setup should be option 1. ie, distribute identical bits to the same format physical DAC input connector on all DAC boxes. hence this could mean AES3, or SPDIF on RCA; and hence the weiss FW > AES3 suggestion as one example. it also allows (with an appropriate distribution / format conversion box) the format conversion to be a single controlled variable, hence it would be possible to test the effect of data transport over different physical interfaces to the same DAC, or to different DACs..... re: 2/ if the objective is in testing data transport and conversion *together, as a system* (which provides "best" combination of equipment for a given DAC, and hence can be under the heading of "opinion regarding optimal setup environment for that DAC") then sure, go ahead and sent bits to different DACs over different physical transport: FW to weiss, lynx>AES3>BADA or FW>convert>AES3>BADA, usb>(transit or pace car or wavelength or whatever)>another DAC, bits by hamster wheel bucket brigade to yet another DAC. but these contain more variables under simultaneous evaluation (incl possibly different SW drivers, etc.) most rigorous (and perhaps of most value in comparative interest) is to test first by method 1 (all DACs receive identical data at a common type of physical input connection). then observing and comparing "tuned" solutions (ie your favorite physical interface plus a given DAC) adds additional info above the baseline. --- (purely anecdotal story): almost seven years ago, several obsessive audiogeek buddies (as a group we were mostly ex-Bell Labs types, humorously enough) were interested in the issue of cables / snake oil for digital audio signal transmission. one person invited us to her company's lab which had extensive audio measurement and networking verification equipment. we hooked up and measured a slew of audio equipment (it was somewhat perverse having el-cheapo cables - bought down the street ay Fry's in blister pack - connected in something like a quarter-million-dollar network data traffic analyzer setup). i had brought along two boxes: a (then-new) Benchmark DAC1 and my ancient Genesis Digital Lens. the Lens, although admittedly limited to Fs = 48 kHz, has AES3 output on XLR balanced, as well as SPDIF on RCA, ATT Glass (inputs all of these plus TOS and AES3 BNC). allowed us some degree of digital format conversion and signal distribution in various permutations of CD-based equipment setups. long story short, in all of our geek testing, probing and measurement, waveform purities inside the DAC1 after the digital interfaces were essentially impeccable, speaking to the good work done in selection of components and design of the data Rx systems (and design heritage of these products is from the broadcast industry, no surprise). many data source / transport variations in test setup were used. ie different transports, different processors a/o format conversions; from z-systems and Digital Lens and i-forget-what to AES balanced directly; Lens RCA > 75ohm RCA-BNC matching transformer > BNC; and other connections directly from test equipment feeding digital audio traffic via 75 ohm. similar result with several other DACs, some of which had BNC inputs, others only SPDIF RCA. and also, some DACs had less-good waveforms after Rx, speaks to data Rx design. net takeaways from that evening: - anderson valley brewing's oatmeal stout is great - good bang for the buck digital cabling gets you most of the way there, in audiophile terms (me, i like bluejeanscable) - the Digital Lens was quite the toy for its day, I'm keeping mine /a/ for sentimental audiofool reasons and /b/ it allows even an inexpensive transport to box well above weight in providing great redbook a/o HDCD playback --- @sunjitwhy and his merry band of testers: btw, be cautious about the concept of "brutal honesty" regarding products here on CA. it's unfortunately experience based in solid evidence (communications trails confirming that CA Symposium had a "sanitized" attendee list, bannings for questions/comment re heavily-discussed products a/o marketing issues) that the CA host and some of his related sponsors appear (to a reasonable person presented with the aforementioned information) to be uncomfortable with airing of such concepts as applied to their products (HW, SW, consulting) and concerns wrt potential for Conflict of Interest and other agendae.

+1 to clay that FW should be utilized / tested wherever available. however, where FW is not an available option, there need be a common ground in data transport. hence AES3 (aka ("AES/EBU"). would not simply dismiss AES3 as inferior, that is a somewhat superficial statement often found on "audiophile" fora. AES3 balanced is perfectly capable data transport / interface variant when viewed (and utilized) in a system context together with a capable data receiver providing quality clock/jitter handling. pragmatically, in order to provide a level testing field you will have to feed all DUTs (Device Under Test) with a common source. this could mean that you use FW from your computer to feed a quality FW-to-AES3 converter (ie weiss); then distribute AES3 to all DACs. You can always do complementary testing of direct FW connection for sake of comparison; but again, you need to remove all possible sources of variation from the common testing scenario for each DAC.

your proposed testing is a lovely issue in multi-variable optimization.... if you are truely interested in only the result of a different DAC (post-DAC measurements, perceived sound quality), then you must strive to fix any other possible variables -- ie keep them from changing and thereby influencing your test. this seems to imply: - only one source of a given type (ie only one computer source with its inherent OS and data-access timing variations, not multiple computers; or one single optical disc-spinner with its error-correction possibly taking place) - computer: only one playback SW. period. no switching during entire course of testing or you introduce a major irrepairable source of placebo / confusion (and variable processor loading and etc etc). and you should really not use any SW playback engine which has unknown variables about operation / mathematics yada yada. would strongly suggest single track-at-a-time through a known professional editing/mastering program. ie perhaps solicit input from Bruce Brown (pugetsoundstudios), who does post here on CA. you've also got several great folk in your area who have lived / eaten / breathed such DAC evaluations, Alan Silverman (arfdigital in NYC) comes to mind. - perhaps approach this project like a recording / mastering engineer shootout of converters. rent/lease an appropriate workstation for playback. maybe you might solicit input on gearslutz wrt test setup / procedure / methodology. engage one of aforementiond folk on a contract basis -- they've done as audio professionals what you are loking to do as a commercial product dealer. a small amount of money spent wisely a priori will help you avoid issues..... - from the single source, sending data over only one single physical AES/EBU link. if not to a workstation, then to a splitter / distributor which can parcel out the same stream simultaneously to multiple DACs. this means looking at pro audio a/o broadcast industry equipment: try z-systems, sonifex, ocean matrix, radio design labs... of course, if you were say to lease a workstation (Pyramix, etc), the point could be moot as AES/EBU routing and target selection could be included functionality. - if you do go the standalone monitor controller route, coleman is indeed a very good choice. you may wish to consider an active unit to remove any possible impact of cable-length- (and generally cable-parameter / destination impedance) interaction effects with the various DAC output stages. Coleman also makes these; other excellent choices would be Crane Song, Dangerous Music, spl.... ie again equipment from the pro audio / mastering world. IOW, buffer the analog playback electronics input, or do something appropriate, to remove possible system variation due to different DAC output stages having different reaction to downstream cabling / variable impedance / etc.... reactionist audio hobbyists may (naively) jump on the word "active" concerning a monitor controller which would perform selection of the various DAC outputs; but having the DACs all drive a known buffered load removes many electrical sources of possible variation in your scheme. for additional subjective consideration, you can always test again with a passive monitor controller. - issues if identical cabling, level matchng, gain-staging etc etc are self-evident.

a user named "barrows" was a frequent poster as employee, and referred to by other employees, on the PS Audio Forums until several months back.

barrows, you have more than once posted dismissive commentary that ASRC as utilized by some designers in DAC system architectures harms sound quality. however unless i've missed it, i don't think you've ever provided substantiation for that assertion. could you kindly post some objective info supporting your contention, with attribution? you know, controlled tests, measurement,.... somethig beyond merely anecdotal just trying to reconcile with the reality that even ASRC IC designs which are over ten years old yet widely utilized, exhibit distortion products down in the -120 to -140 dB range. And some more modern designs exhibit even lower figures...

i seem to recall info (somewhere) that the iTunes application itself is one of the items specifically not rewritten to 64-bit native code in time for SL release. can anyone confirm this with definitive information, and an attributable source? before general audiocardial infarction results in those obsessing on how iTunes processes audio data.... recall this issue means (pending clarification, and CompSci guys pls excuse the poor terminology) only that the "instructions" in the iTunes "program" would not be in the "new" native 64-bit instruction set. It does not mean that the program would be somehow deficient in handling of audio data. several senior software folk from a certain large fruit company live in my neighborhood.... if i happen to have any audio-obsessive conversation with them while walking the dog, i'll post relevant info.....

this may be interesting for some of you, especially if you've not had the pleasure of suffering through years of EE study, Digital Signal Processing theory, and DAC design, or spent much time in the entertaining über-tech world of the AES...... those who have had such good times, know that in the world of dsp audio professionals, there is a very short list of people who truely understand the fundamentals and application of dsp, system design, analog and digital design, etc etc. -- and make products which prove it. not hobbyists who "design" products; not "producer/composers who started recording" and spout drivel in online fora about dsp; not people who come from on-chip interconnect design and are stepping far outside of their expertise in pontificating about signal processing... Dan's is one of the names often mentioned by the leaders in the field as someone who truely understands the technology of digital signal processing as applied in creation of pro audio products (as context, other highly-regarded names you may encounter in the world related to CA are such as Daniel Weiss, without a doubt one of the gold-standard dsp guys; Bob Adams (Analog Devices, you owe it to yourself to read everything he's published about data conversion and sample-rate conversion); Jim "JJ" Johnston (one of the fathers of perceptual audio coding among many other signal processing achievements); Rich Cabot (tech brilliance behind the creation of Audio Precision and many other signal processing developments); Karlheinz Brandenburg, Harald Popp, Jurgen Herre and others at Fraunhofer; John Strawn, Mike Story, Bob Stuart...) why the buildup about Dan? simple: there is a lot of posting in audio fora about the alleged "superiority" of NOS DAC design. Generally, when you do some forensic investigation and track back through web postings, "reviews," references, etc; you find that the posters generally have little more than subjective info ("I like how it sounds") or anecdotal stories ("I've heard that..."; "my customers say..."; "this guy has posted a lot and says"); and as a rule few have any idea at all about the fundamentals of digital signal processing, sampled-data systems, analog and digital filter design, data conversion fundamentals, overall audio system design.... well, Dan is the real deal. He posts based in technology and fact. Any occasion when he makes time to post (especially in fora filled with die-hard subjectivists) and explain technology in a way to shortcut years of academic study, it's worth reading. over in head-fi land right now, there's an interesting thread where Dan is taking pains (with some obvious frustration, he may be blunt but that is his nature) to explain the technology fundamentals underlying concerns about NOS design. worth a read, enjoy: http://www.head-fi.org/forums/f7/nos-dac-marketing-bs-438220/

for pure bulk storage, would recommmend you consider drobopro. connection via iSCSI has very fast transfer rates to/from host; you can fall back to FW800 if needed. iSCSI initiator (the SW "driver" for iSCSI on OS X) included in drobo SW. works very well in 10.5.x i have drobopro for bulk library storage (connected iSCSI, and configured for two-drive redundancy (meaning two of the eight drives can fail)); and other drobos / NAS / drives / audio interfaces (connected FW800 and FW400) through the simple "hub" of a 15" PowerBook drobopro unit itself is not "inexpensive," but considering overall cost of "bulk storage system"; mindless expandability (hot swap/add/remove drives, no RAID management required); and data storage redundancy (drobo uses a mix of RAID-style mirroring, parity and striping techniques); it seems to be reasonable money spent up-front in building a storage core easily expandable up to some huge number of TB. I currently have 6x 2TB in it; waiting to populate the other 2 slots (with 2x 2TB) for drive prices to drop in the next round of market maturity over coming months (and other vendors to come in). meanwhile, will be slotting in 2x 1TB that I have lying around from other RAID units I'm selling. one more drobopro benefit: you don't need to populate it with "fast" drives or enterprise-spec'd drives, works admirably with ie lower-priced bulk WD Greenpower drives (dynamic rotation speed control as part of their power saving algorithm) which are "quoted" as 5400-6000rpm. have spoken w/ several of drobo's engineers; their product positioning (RAID-like with simple ease-of-use for users with lots of media, ie photographers, musicians etc) targets use of commodity drives in a high-reliability but simple useage scenario. another bulk-storage option, if you are on OS X and have many disparate drives (and even older ones of varying sizes) sitting around: SoftRaid is generally considered a step up from Apple's integrated RAID support. A simple and stable way to combine many external drives in RAID sets as part of your redundant backup scheme.... i use this with a slew of older drives, provides another manner of redundancy. edit -- correct typo FW400n > FW400; some formatting; add iSCSI initiator note and "not inexpensive" paragraph

http://www.atlona.com/Atlona-HDMI-1.3-Audio-De-Embedder-p-17801.html happily accessing a variety of 24/44.1 decoded HDCD, 24/96 and 24/192 this evening from BDP-83 HDMI.... available direct or thru amazon (atlona=lenexpo vend thru marketplace)

perhaps one option would be to set it up as a wiki so that (registered) CA members can add / edit / correct info. manufacturers, consultants and others with vested/finanical interest are welcome (and encouraged) to be part of the community contributing product info. to keep things honest, on-point and avoid CoI improprieties, lay down ground rules that main entry (whatever "form" or "format" is decided upon) is only for factual product info (features / tech / capabilities), not reviews, opinion or marketing. this main product entry can include links to separate venue (separate CA fora for product reviews, members of the trade comments, etc) which can be set up for such content. my .02

well, as the entire universe knows by now, Borders slipped up and made public mention of an upcoming Apple "iPad" given totality of public info (+ innuendo, rumor and heresay ) such a product would most probably be focused as e-book and media presentation platform. would make one heck of a couch-surfing remote, too....

if looking for used macs, lowendmac.com is another helpful resource wrt tech specs / model history / market pricing

saw this announced here (tail-end of a thread otherwise immensely humorous for some of its technical misunderstandings): http://www.head-fi.org/forums/f133/24bit-vs-16bit-myth-exploded-415361/index26.html#post5928953 direct link: http://soundcloud.com/linnrecords/sets/24bit-comparison-alyn-cosker

jamie, +1 on appreciation for providing correct info; the pfo assertion re plangent @ 24/96 did seem somewhat odd given other available info wrt the NYA team's transfer/mastering work (and the conversation i was fortunate to have with you back at AES SF following the Forensic Audio session )<br /> <br /> fyi there is another published source closely-related to all-things-Neil which has this particular info incorrect (and perhaps was a contributing factor to the pfo article content?); you might wish to alert them to the error: http://www.thrasherswheat.org/2009/05/nya-question-of-moment-riverboat.html