BitPerfect Support

If you are working on the Mac platform, allow me to recommend DSD Master from BitPerfect Sound Inc. This produces PCM conversions that are close to indistinguishable from the DSD original. From the linked blog page you can download free samples of high quality pure-DSD files together with DSD Master's PCM conversions at a variety of sample rates. Take a look, and see what you think.

Absolutely spot on.

Two maintenance notices have been posted on our Blog Page regarding OS X 10 9.5 (Mountain Lion) and 10.11 (El Capitan).

Contact me directly on the BitPerfect Support e-mail line. Unfortunately, swamped with construction at the moment and struggling to keep my head above water, so response may not be instant

I am reluctant to recommend that in isolation. There are many reasons for which you may wish to upgrade OS X, and unless your Mac is primarily used as a music server you need consider the bigger picture. Additionally, if your Mac is an older one, for example with a Core 2 Duo, you need to consider whether the latest OS X may be asking too much it. Having said all that, I do have an old ~2009 MacBook Pro with a Core 2 Duo, and I have upgraded that all the way to El Capitan. Actually, I found that while Yosemite (10.10) did cause it to run significantly more sluggishly, installing El Capitan did seem to speed things up a bit. But YMMV. BitPerfect on that MBP under El Cap worked straight out of the bag. - - - - - - - - - BTW, I am getting reports of an odd problem which seems to afflict certain users who upgrade both iTunes and El Capitan at the same time [if you are not already running the latest version of iTunes then it appears the El Cap upgrade will upgrade iTunes whether you want it to or not]. It seems that when this happens, sometimes BitPerfect cannot find the iTunes music library when it first launches. This in turn apparently prompts OS X to open a finder window with no message to tell you why, or what to do with it. What you must do is navigate that finder window to the folder containing your iTunes music library, and click Open. BitPerfect then opens normally. When we learn more about this odd behaviour we may push out a separate update to deal with it.

I agree with that. A new problem is emerging - or at least our handle on it is emerging. Users running OS X 10.9.5 who have upgraded to BitPerfect v3 are reporting serious problems. What we are now learning is that our new AppleScript-based method of communicating with iTunes, which has been thoroughly tested under Yosemite and El Capitan, is failing under Mavericks and Mountain Lion (and possibly Lion as well, although we haven't heard any reports of that yet). What is happening is that those earlier versions of OS X are denying BitPerfect permission to use AppleScript to talk to iTunes. This appears to be what is called a "sandboxing" issue. All Apps sold on Apple's App Store are constrained to play exclusively in their "sandbox", which is a controlled environment where they supposedly can play safety without causing any harm. There is no way around this, other than to withdraw from the App Store and sell direct. In certain cases, though, when you submit your Apps to the App Store, you can request an "exception" to a specific sandboxing rule. In fact we already do this - we have a number of exceptions in place. However, the documentation provided by Apple to assist in navigating your way through the exceptions process is not at all helpful. We have been through it many times and haven't found anything that would deny Scripting Access under Mavericks and Mountain Lion (but allow it under Yosemite and El Capitan) to which we could request en exception. The workaround we are actively working on is to include both communications paths, AppleScript and Scripting Bridge, and invoke one or the other depending on which version of OS X is running. This type of surgery is actually a lot more fiddly than you might imagine, and offers plenty of opportunity to really screw something up, so it is taking a little while to do it properly. And test it.

I understand why you would be puzzled by this. BitPerfect relies heavily on good communication with iTunes. We have been using Apple Scripting Bridge to do this. However, what seems to be happening is that the internal process within iTunes that services this Scripting Bridge interface runs with a seriously low system priority. It doesn't take much for OS X to decide that it doesn't have enough spare whatever (we'll call it resources, but hard to know what exactly) to allocate some of it to this process. What we do know is that quitting other Apps etc can be of considerable help. With v3 we have switched some of this dialog to AppleScript which, if nothing else, permits a more focused communication, but with some headaches of its own. On balance, in testing, this has proved to be the more reliable method. Unfortunately, though, we can't test for every possible scenario. At the end of the day, though, the root cause may be neither AppleScript nor Scripting Bridge, but rather the internal iTunes process that both of these communications protocols invoke to retrieve the requested information from iTunes. In which case the difference in performance between the two may end up being minimal. All that notwithstanding, it is possible that updates to iTunes itself, rather than the updates to BitPerfect which were rolled out in the same approximate time frame, may also be responsible for changes in performance. But if so, we didn't observe anything significant during testing.

In those cases you can raise that to closer to 100% by importing the album by dragging in individual tracks from Finder in track order. At least that's how it works out for me.

Yes, but with the added complication that tracks with the same Date Added are sorted first by Artist and then by Track Number. So different Artist fields will screw up the track ordering. I really think that must be an iTunes update issue as there really is no opportunity for BitPerfect to be responsible. BitPerfect invokes a certain Scripting Bridge call, and that simply hasn't been changed in any way between version 2.0.2 and version 3. The idea of determining changes from version to version of iTunes is really a lot more complicated than it might appear at first glance. A necessary precondition is to understand the behaviour sufficiently at one point in time so that when you see a change you can make sense of it. Right now, I only have a tenuous grasp of the current behaviour so that, for example, I can make sense of it in the light of my own Library and the various machinations I have gone through to get it to behave the way I want it to, and that's as I described it in my previous post. I didn't actually notice any change in Gapless Playback over the recent iTunes updates, which, since I play mostly classical music I am as a rule quite sensitive to. But clearly, if others like yourself and t'other Richard are seeing deviations from that then I must conclude that I can't have the whole picture. Way back in the early days, I had a version of BitPerfect that would spit out detailed entries in the Console Log telling me what track was currently playing and what track was currently being queued. I used that to compile great lists of what was happening under what circumstances. I would change views, playlists, sorting options and what-have-you. It only served to confuse the hell out of me. The current scenario, post 'up next', actually seems to me to have simplified things somewhat. I actually did try building a new parallel iTunes Library, importing all 35,000-odd tracks in one swell foop. The result was calamitous and almost nothing would play Gaplessly under any circumstances. So, as a result, I don't recommend doing that! .............. Finally, with all this talk about queueing files for Gapless Playback, it is an amusing diversion to note that queueing is the only word in common use in the English language which has five consecutive vowels! A great pickup line in bars, I feel ....

Will the real Richard please stand up! This one is the Richard from BitPerfect. We have had to deal with a few issues with the release of BitPerfect v3. Between us submitting it to the App Store, and Apple finally approving it for release, Apple released El Capitan. All of our testing on v3 has been done using beta releases of El Cap, as have the majority of our Beta Testers. One of the problems in working within Apple's (or anybody else's, I guess) beta programs is that when dealing with a beta you don't know whether something that isn't working the way you expected (or wanted) it to is the result of a bug that is slated to be corrected, or a designed new behaviour. We are quite low down on the Apple Developer totem pole and it is not possible to have any meaningful dialog with Apple on matters like these. All this means that pre-release testing is never as straightforward as a lot of people would like to imagine, and to test every possibility comprehensively is beyond the resources of a small enterprise like BitPerfect. Having said all that, it surprises me that issues with Gapless Playback should surface between v2.0.2 and v3 of BitPerfect, since those parts of the source code have remained unchanged. The biggest recent change to Gapless Playback behaviour has been with the introduction of iTunes' 'up next' feature. In order for BitPerfect to be able to guarantee Gapless Playback we need to know what track is due to play next, otherwise we have to wait for it to start playing in iTunes before we can load it and play it ourselves (with a resulting gap). Therefore, we need to know what is next in the 'up next' playlist. The problem is that iTunes does not provide any method for a third-party App such as BitPerfect to access the 'up next' playlist. I discussed this with Doug Adams (he of the dougscripts.com reknown) and he concurs that the 'up next' list is not scriptable. Instead, when we ask iTunes what the next track is in the playlist, I have established that the playlist iTunes uses to tell Apps like BitPerfect which track is due up next corresponds to the All Songs playlist, listed in reverse "Date Added" order (i.e. most recent first). For tracks which have the same "Date Added" property, the interior sort order used is the "Artist" field (not the "Album Artist"). As regards Fixed Indexing, Doug Adams provided me with a vague description of what that meant, from which I deduced that neither of us have a clue what it does. Personally, I seem to get best results with Fixed Indexing checked, but, clearly, YMMV. If you use the iTunes "File|Add to Library..." dialog to add albums to your library one album at a time, then I find that album will play gaplessly with Fixed Indexing checked. However, this only applies if all the tracks in the album have the same thing in their "Artist" metadata. If they don't, then your only solution seems to be to add the album to the library one track at a time in track order. I do this by drag-and-dropping from Finder rather than using the File...Add dialog. By doing all this, and by playing with the Fixed Indexing property checked, I get good gapless playback performance. Generally, when Gapless Playback bahaviour is found to be changing, it is almost certainly due to an update of iTunes rather than an update of either BitPerfect or OS X. As you can imagine from the above, testing for this sort of thing is fraught with difficulties, since it depends heavily on the relatively fine details of how the iTunes Library is configured. I can only beg your indulgence, and hope that Apple one day decides to expose the 'up next' playlist as a scriptable property.

You've sold the DirectStream, so you can't try this, but for the sake of the ongoing discussion I thought it was worth an airing. Inside the DirectStream, the output bitstream is generated using an SDM. The DS's volume control is applied in the digital domain prior to the SDM. Naturally, the greater the attenuation, the lower the actual resolution will be in the SDM's digital output and therefore in the DS's analog output. This could be what you are hearing. I'm not sure I hear it though. It seems to me this is only really an issue if, like me, you are connecting the DS directly to the inputs of the Power Amplifier. Otherwise, you would leave the DS's volume on 100 (or some other value you might like better) and use your PreAmp's volume control. Since I connect directly to a 300W/ch Power Amp, I would seldom want to use the DS at much more than volume 50-70, which implies 2-3 bits of resolution loss due to digital attenuation in the SDM. The solution is to engage the badly-named "filter" on the DS's remote control. This engages 20dB of analog attenuation at the DS's analog output, and means that I can run the DS with its volume setting in the range 80-100 (with negligible resolution loss). The other thing to bear in mind is that, as other posters have noted, when connecting the DS directly to a Power Amp's inputs, there are significant opportunities for interface mismatches or other synergy/compatibility issues. Some combinations will work better than others. I don't know the extent to which this is (or isn't) a greater problem with Power Amp inputs than with corresponding PreAmp inputs.

Just a quick note to say that my findings with this DAC have been the opposite of yours, and I have had it for over a year now. Globally, the product has developed a reputation more in line with my findings than with yours. In particular, the bass which you don't appear to like, I find to be exceptionally good. Please don't take this statement wrongly ... but you describe your situation as follows: You bought the DirectStream, found you didn't like what you heard, and responded by replacing every other component in your system. Seriously? It looks like you either don't know what you're doing, or are acting upon some incredibly inept advice. Again, I'm really not out to bash you here, but that's how it looks to me

I doubt simplistic equipment like that would help resolve this issue. I doubt it is just a question of RF power, or even the RF power spectrum (it is possible, although unlikely, that it could just be as simple as that). Most likely is would require a sophisticated correlation analysis between the RF and the audio signal, or even its digital representation. The level of sophistication required just boggles the mind, and is quite beyond us at BitPerfect. Try asking at CERN I am sure Bruno is spot on. PC emissions are regulated more by concerns of health and interference with regulated radio transmissions than with audiophile performance. However, RF that is transmitted down the USB cable is not leaked per se, and would not be regulated by the FCC.

Again, I have to emphasize, NOT CORRECT. BitPerfect's sonic "signature" is not an artefact of any alteration whatsoever of the audio data at the Mac end. To the extent that that there is any alteration, it would in principle be limited to the analog representation of the digital data stream which is transmitted from the Mac's USB port, but not to the actual data thereby represented. I hope that is clear.

I expect it would, although I have never verified that myself. AirPlay itself raises a very interesting question, and I'm surprised that nobody has seriously challenged me with it before. When AirPlay support became possible using BitPerfect with the introduction of Mountain Lion, I asked myself if BitPerfect could possibly make a difference over AirPlay. To the extent that we have a plausible rationale for how BitPerfect impacts audio replay, it did not seem obvious to me that this could be extended to the AirPlay link between the Mac and the DAC. For sure, an AirPlay receiver is an RF-rich environment, but it doesn't necessarily follow that subtly affecting the RF environment in the computer would cause a corresponding subtle effect in the RF environment of the destination AirPlay receiver. My expectation was that using BitPerfect over AirPlay would not result in any significant audible improvement. My first immediately experiments proved me wrong. I have three primary AirPlay test setups, of which one (the one using an AppleTV) is not capable of 'bit perfect' performance. The other two are my Classe CP800 preamp/DAC which sports its own ethernet-connected AirPlay receiver, and my AirPort Express using its toslink output. Much to my surprise, I found that playback over BitPerfect was noticeably better - in fact surprisingly so. In particular, playback using BitPerfect seemed to give the impression of being consistently louder. To this day I am somewhat puzzled by these findings, which many other users have confirmed. Sure, I can make an arm-waving RF interference-based argument as to what is going on, but, unlike the rationale I present for improved audio playback over USB, I don't really buy into it myself. On the other hand I don't really have any alternative candidate mechanisms (other than Buffalo Bill's 'Emperor's New Clothes' argument, I suppose) that make any more sense.