Jump to content

couchjr

Members
  • Content Count

    22
  • Joined

  • Last visited

About couchjr

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks, Ted_b, understood. I believe GUTB's statement (from the comments on MJ-10's DAC comparison article posted by George above) referred to alleged sound improvements obtainable to Redbook CD files by up-converting those to "DSD 264" because of a mandatory sample rate conversion from 44.1 to 48 KHz in the Sabre DAC chip for native Redbook files, which was avoided at the higher resolution. Am I correct that JRiver's upsampling of Redbook files all occurs in the PCM domain and therefore would not carry an inherent sonic penalty? I don't know enough math to know why up-converting before the DAC chip would sound better than converting in the DAC chip (other than a higher sampling rate possibly reducing the impact of individual timing errors and different filter parameters)--it's still a conversion. I also don't know whether George's architecture even faces the "problem" that GUTB identifies, though I've seen it mentioned in forums on DAC design. That's why I asked the question. I believe George has usually advised playing each file in its original resolution/format for best sound in his DACs. As a happy e32 owner, if that's no longer the case, I'm interested in understanding the options, and what the sonic benefits and usability penalties are for each.
  2. George, given what you know about the architecture and execution of the e32, would you agree with GUTB's comment below for users of the e32? But since it's a Sabre DAC you can realize big gains by up-converting your non-DSD tracks to DSD 256 through the player; this bypasses Sabre's SRC stage which leads to further quality gains. Actually, do that with the Amber too to bypass its SRC and go straight into the DSD module. I have always assumed that passing the original digital format/resolution without additional processing would yield the best sound for each source file; in other words that the e32 was designed to optimize Redbook CD, higher-res PCM, and DSD signals independently. Are there constraints of the SabreDAC chip's clock/SRC in your implementation that would argue for up-converting in player software (I use JRiver) prior to the e32? Thanks for any insight.
  3. As (I believe) the person Fitzcaraldo215 referred to with a similar experience using a Regen with exa's DACs, I'll add that in my case the decision was also affected by the fact that I initially used the Regen with an e22 MkII and assumed I'd still use it with the e32. In both cases my evaluations were initially done with the supplied switching supply. Even with the switching supply in place, I tried the e32 after burn-in without the Regen and thought it sounded slightly better. So I then engaged the services of an experienced friend and did blind ABX tests with and without the Regen, and with and without two other USB treatment devices. In all cases, the "blind" listener (we took turns as subject and "manipulator" and varied the A - B sequence to minimize bias toward the last sample heard ) found the sound "better" without the devices, judged on specific perceptual criteria. It's my hypothesis now that the improvements in clarity in the e32 made the nature of the Regen's SQ changes more apparent and easier to compare with the untreated chain. It's also possible that the technical interaction of the Regen and DAC is different for the two models, but I'm inclined to think that's a less important factor. Later I substituted the new HDPlex 200W LPS for the switcher, with dramatic improvement audible. As I noted earlier in this thread, I attribute some of that improvement to removing a source of "backflow" digital noise into the power cords for my analogue downstream components, and thus specific to my particular system. But I think some of the improvement was due to removing the last source of digital noise into the e32 and a more robust supply capacity.
  4. I don't see a thread yet specifically for the e32, so I'll post my experiences here. I moved to the e22 Mk II from an Oppo 105D used as a DAC while I set up my Mac Mini and Synology NAS to house my growing DSD (and PCM) collection. I was very happy with the sound overall. I replaced the internal switching supply on the Mac with the UpTone linear supply board and fan controller. I experimented with a Regen, and like some others here I heard a difference, including some bass emphasis that did not feel unwelcome. I was using the e22 Mk II with the supplied switching power supply, plugged in to the same minimalist Shunyata power distributor as my preamp. That power distributor did not isolate the outlets from each other. I was impressed enough with the e22 Mk II and George's discussion of the improvements available with the new ESS pro chip that I upgraded to the e32. After burning in (I have found that--without getting into the psychoacoustic-adjustment-vs.-equipment-changes debate about burn in--both exaSound DACs' sound evolved, taking in excess of 200 hours of operating time to stabilize), the e32 was a clear improvement over its predecessor in many areas, the most immediately obvious (though not the most important) being an increased extension and authority in the bass. With the Regen in place the low end now seemed excessive, and I decided to try the e32 without it. The change made a clear improvement (in blind AB tests with an audio journalist friend). The bass remained extended and authoritative but no longer slightly bloated in the upper bass, and crucially, midrange articulation (timbre characterization and the sense of individual instruments within sections, etc.) was noticeably improved. My friend and I tried the blind AB test with a couple of other inline USB reclock/regeneration boxes as well, and agreed that the e32 sounded better in all cases without them. (I suspect in fact that the e22 Mk II's sound also was not really improved by the Regen--only changed--but some of the factors discussed below masked that to some degree.) George has stated that some sonic improvement is achievable from his DACs by substituting a good linear supply for the supplied switcher. In part he attributes this to the switcher being the last potential source of digital noise into the DAC, given the galvanic isolation and power filtering measures designed to eliminate noise from the signal source. So having been pleased with the HDPLex 100W linear supply used to power my Mac Mini, I ordered Larry's new 200W LPS (same form factor as the 100W) to power the e32. That supply is now plugged in to a pure-sinewave UPS in an adjacent closet (which supplies the NAS and the other HPPlex/Mac mini, but is fed from the same box on a dedicated 20amp circuit as the gear in the listening room, to to minimize ground loops). So the preamp is now the only device connected to the Shunyata distribution box. I was not really prepared for the quality of sound resulting from this set of changes. I expected subtle improvement, but instead it was, in the words of my journalist friend, "an order of magnitude." I hypothesize that this is due to three factors: partly to removal of digital noise into the DAC, as George expected; but also due to digital noise from the switcher no longer being directly transmitted via its plug to the adjacent plug of the preamp; and partly due to the robust capacity of the LPS itself (as Victor Khomenko has written, in an automotive analogy for why he designs oversized power supplies in his components, "there's no substitute for cubic inches"). There is now no switching supply anywhere in my audio chain. I conclude from my experience that the engineering of the e32 is indeed very successful, and that George's measures to address noise from the signal source at the receiving end are effective. I don't want to resort to audiophile cliches to describe the sound. I'll just say that the spatial, spectral, dynamic, and timbral perceptual effects we look for are impressive. The overall system now has among the lowest noise floors I've ever heard, with concomitant resolution of low-level events, reverberant tails, etc. Last night I had the chance to hear several direct AB comparisons of MQA-studio tracks with the same non-MQA tracks (via an Aurender) on a system with high-end Magico speakers and Berning amps. The perceived character of the improvements in reduced "smear" from the e32 and LPS playing DSD files in my system were analogous to (though different in mechanism from) the improvements ("deblurring") that the MQA-studio process seeks to provide. I think my system is now hitting the constraints of the speed of the drivers and enclosure rigidity in my (excellent but now 10+ years old) speakers. But if you had asked me even two years ago whether I'd ever have sound this good, I would have said, "no way." So I'm incredibly pleased to be exploring repertory with the e32 setup. And saving pennies for upgraded speakers . . . . ---------- System: Synology 1515+ NAS -> direct cat 6A ethernet to Mac mini server (HDPLex 100W LPS) -> 0.6 M Supra USB cable to exaSound e32 (HDPlex 200W LPS) -> Shunyata balanced cables to BAT VK-55SE ->Shunyata balanced cables to BAT VK-160SE monoblocks, bi-wired via Tara Labs RSC to Von Schweikert VR 4 Gen III HSE speakers, Martin-Logan Descent sub. JRiver for library and player via JRemote on iPad. VPI Aries & JMW Memorial arm, Grado Reference cartridge. (9' wide by 7' tall fully loaded bookcase on wall behind speakers with volumes inset at staggered intervals to form a pseudo-Schroeder diffuser.)
  5. Adding my welcome to your new CA digs. Thanks not only for great products but also for your generosity with your experience and insights here and elsewhere.
  6. Thanks, Alex. So if I understand correcty, the new device will reduce both kinds of noise potentially going in to the Regen via power: high-frequency grunge from switchers and lower-frequency spikes etc. from linears other than the JS-2. That is, you see value in the product for folks with either kind of "energizing" supply if they are using a Regen. But noise back into the line from either kind of energizing supply will not be affected. Do I have that right?
  7. Alex, will the mystery add-on accept a 5.5/2.5 barrel input for those of us with existing linear supplies supplying 7.5V DC? If not, what input will it accept without an adapter?
  8. This assertion (the "lower freq jitter performance is more important for SQ") matches what I read a while back on the DIY forum, where people were looking at several different clock types with interesting specs. I'm not a digital engineer, but if as you say the 575 clocks have 4dB better performance than the 950s at 10Hz, I'd expect the performance and thus SQ to be much better still in the KHz range and above--and to my ears, that's the range where timing anomalies are most noticeable and annoying. Vocal consonants, cymbals, upper registers of piano and especially violins, with all their overtone series, and spatial cues. The system that can unsmear a well-recorded baroque violin section while retaining the rosin of the attacks and hall bloom so that it sounds like a blend of individual instruments in a recognizable space and not an amplified dentist's drill is the system I can love.
  9. Elise_B, thanks for posting your experiences. I've seen the Wax Box in action, and I agree that it has an elegant interface. In general I think the current state of computer audiophilia under-emphasizes the importance of UX design. It's a shame to leave such an important aspect to the high-end commercial firms, when so much innovation in other areas is being driven by dedicated amateurs and small shops like JRiver. I continue to hope that the Mac version, at least, of JRiver Music Center will improve its interface as it matures and gains market share in a growing market. I've also played with MusiCHI, which is incredibly powerful, but it looks like a tool for database programmers, and is not available on the Mac or (last time I checked) iOS devices. There's no reason that these software products need to have presentations that look like stack traces or low-resolution spreadsheets. Even some of us who spend our days scrolling through code and can assimilate it quickly may want a break from the fatigue, and it would certainly make many tasks quicker and easier to perform if the cognitive load were reduced by losing some visual noise. Power and usability are not incompatible, as programs like Photoshop proved long ago. But for now it looks like good UX design is a differentiator for high-end commercial products because it adds value. I'd like to see it propagate more widely in the audiophile software space.
  10. Not sure how to reach Jesus at Sonore other than this thread, so apologies if this doesn't interest others, but it may. I've just done a batch extraction of 100+ ISO files using his GUI version (ISO2DSD) for the Mac. I thought everything had gone fine until I realized that it skipped about 24 ISOs saying it couldn't read the files. A quick inspection showed that the problem was that it would not read characters with diacritical marks in the ISO filenames (conductors like Paavo Järvi or works like Götterdämmerung or Lt. Kijé). I manually replaced all these characters in the ISO names with plain Latin characters and then they extracted fine. The *output* both for the folder (album) names and the track names *did* include all the correctly accented characters, so I presume Mr. Wicked's underlying utility is not the problem--though I haven't done a one-to-one comparison, I don't remember having this problem with it. Is it possible that the Sonore app could be changed to recognize the appropriate ISO (not audio in this case, but characters) or Unicode character set for input? It's a huge pain and quite time-consuming to have to screen for files with these marks and then manually strip them before running a batch. The software does offer a couple of nice advantages, so I'd like to keep using it. One other feature request would be to abandon the horizontal scrolling in the selection window (appears when reading a folder with a large number of files.) It's hard to tell what you've already selected when trying to do a noncontiguous selection (command-click) of several files, since it's hard to accurately scroll back. A straightforward vertical scroll, as in any Mac Finder folder, with a side slider for fine movement among hundreds of files, would be much preferable, at least to me. Many thanks for the effort to develop this!
  11. If Miska's analysis of the nature and number of truncated frames in the DSD file tails is correct, it makes sense that the audible result would vary from track to track; sometimes little or no sound and sometimes different sounds.
  12. Not sure. But it's a small app. Download it, and click the "Preferences" menu, upper left. If you see a checkbox for something like "Prompt for output directory" or words to that effect, it's the new build. There are only like three preferences, so you can't miss it. There's an email address under "support" so if you don't see it, write Barry and ask him for the new build, or for an ETA on inclusion in the public version.
  13. Thanks, Ted. I have good news. Someone over on the JRMC 19 Mac forum pointed me to a new Mac utility from 2manyrobots called dff2dsf. It doesn't strip commas, and in the version I first tried, it saves output in the same folder as each dff source album--that is, it doesn't intermingle output files from different albums. It's free and it doesn't require a mandatory tweet. Right there, those are three major improvements over Audiogate. It explicitly says it does not re-encode the DSD audio, just repackages it. So I posted a feature request to allow the user to specify an output directory and send converted DSF files to duplicates of the album folders containing the dff source files. This would allow unattended batch conversion of dozens or hundreds of albums at a time, saved if desired to a different drive so that huge files would not have to be moved later. Well. I got an email back in an hour from Barry, the developer, that my request shouldn't be hard to implement, and another hour later had a test build that I'm now using that does exactly what I requested, with the elegant twist that it's a selectable option in preferences. (Jesús, that would be a useful option for your sacd_extract GUI too.) In a single stroke, this has solved every technical problem I had, except the need to go through DFF at all due to the bug in sacd_extract. With this batch conversion retaining the original folder and file names, I can now import dozens or hundreds of albums into JRMC in DSF format via a single mpl, and transfer the tags for all of them at once from the mpl via a single "update tags from library" and "update library from tags" sequence. I highly recommend this conversion utility, and want to publicly thank and congratulate Barry for a beautiful implementation. Check it out, everyone!
  14. Ted, just a heads-up: 6233638 over on the JRiver Mac forum posted this: Even if you had the option, I would not recommend this. Media Center's DSD conversions go to PCM first, and then into your desired output format, therefore it's a lossy process. It's not the same as moving PCM audio from FLAC to ALAC, where it's just moved into a different format and the audio itself is untouched. Someone else there has recommended a DFF -> DSF converter from 2manyrobots, as well as their (paid) Mac tagger called Yate. I'm going to try out the free converter and hope it doesn't strip commas--and maybe even retains folders . . . .
  15. This fixed the problem. The help screen populates and the GUI app seems to be working to extract a file; output is as expected from the command-line version of sacd_extract. Nice work! Adds some convenience. Now if we can just get Mr. Wicked (or someone who can hack his code) to fix the truncated dsf tails bug in sacd_extract, we'll have an efficient set of tools. (If I refer people to your web site to download the Mac version, do I need to send them this unix expression too, or is it something you'll incorporate in your latest update?)
×
×
  • Create New...