Bit-perfect Monk at Carnegie - like I never heard it before

9/5/24

While listening to my bit-perfect Deadbeef installation, configured as described in a previous post, I played Thelonious Monk Quartet with John Coltrane at Carnegie Hall, which I'd heard through Clementine driving my Zen DAC V2, and hearing it through Deadbeef was like hearing it for the first time. If you get any CD-grade Monk recordings [1], this should be one of them.

Anyways, I listened to music for about four hours, from about 3-7, without any interruptions from software. When I had the "buffering" problem mentioned in the previous post, I rebooted the installation, and it still had the problem. So, I suspect that it was triggered by date and time window, perhaps stored in a file which would be scanned periodically. If it happens again, I'll try changing the timezone, or system time, to see if it helps. But ultimately fixing the problem would require identifying the malware and removing it.

Notes

[1] Consumers don't need high-res, according to High-Resolution Audio: Does it Sound Better?​ by Goldmund Acoustic Laboratory, which is famous for its extremely expensive gear and would sell a super-expensive high-res DAC if they thought high-res sounded better. Recording engineers need high-res to efficiently produce clean CD-grade recordings. Mark Waldrep PhD, a.k.a. Dr. Aix, an expert in recording, was once a proponent of high-res for consumers, but now claims that CD-grade is all they need.

Something's rotten with Deadbeef, too

 As my luck would have it, Deadbeef developed what sounded like a buffering problem soon after I posted the previous blog-entry (about 4pm). By piping its output directly to ALSA, I had bypassed PulseAudio and Pipewire, so neither of them could be the source of the problem, unless one of them contains malware which takes effect whether or not they're being used.

But while listening soon after I got up this morning, Deadbeef didn't have this "buffering" problem for at least an 1.25 hours as of this writing, which is odd since I was listening to the same album yesterday when it was acting up. So, perhaps whatever causes the problem keeps track of the system date/time, and acts up on certain dates/days and/or times. If so, resetting the system clock might fix it.

However, I left the room for a while this morning, and it had stopped playing when I returned, although I hit play and it restarted at the beginning of the track and hasn't had any problems since then. Just strange.

Bit-perfect playback on Linux without interruptions, for at least a few hours

In the course of searching for information about preventing music-players and the underlying audio services/processes from altering data on its way from some music-file on a PC to an external DAC, I realized that "bit perfect" was the key to unlocking the information I sought. Using this term, I soon found a page entitled Bit Perfect Audio from Linux. After my previous unsuccessful experiences with attempting to attain bit-perfect playback with Linux, I was highly skeptical about whether this was actually possible, because I assumed that there was some music-industry conspiracy which had left no stone unturned in forcing us to pay big bucks for bit-perfect playback without interruptions ("musicus interruptus"). So, I suspected that the page's recommendations were no longer valid, but I decided to try one of them, namely installing the music player named Deadbeef (a name based on a hexadecimal code of some significance to coders) on a live installation of MX-Linux 23.3, setting its preferences as instructed, and then creating a Snapshot-ISO of the installation, which I then used to create another live installation which contains Deadbeef and the aforementioned settings by default.

The instructions for setting-up Deadbeef were apparently based on an earlier version of Deadbeef, so I've revised them for the version I was using (1.9.5):

(a) Click on the Edit, then Preferences.

(b) In the Preferences window, select the "Sound" tab and set "Output plugin" to "ALSA output plugin" and "Output device" to the relevant device, which in my case was the Zen DAC driver described as "iFi (by AMR) HD USB Audio - Direct hardware device without any conversions" (my Zen DAC V2 was plugged into the PC, so its drivers were added to the list).                      

(c) Then select the "Plugins" tab, click "ALSA output plugin" in the list until its settings appear in the window, and un-check "Use ALSA resampling."

After creating and booting the aforementioned live installation with Deadbeef, I put Deadbeef to use, and found that it's utterly simple - just drag the files or folders to be played onto the player, and the rest is obvious. At first, I wasn't impressed by the sound quality, but listening is very subjective and the sound quality you hear at first largely depends on what you expect to hear (the placebo effect), until reality overcomes your expectations.

So, I looked for some opinions on Deadbeef's sound quality, and got sidetracked by a bogus speed-error issue until I realized that it's irrelevant when using a DAC with an asynchronous interface (which probably includes any new DAC on the market), in which case the player's output data goes into a buffer, and the DAC, which has its own clock, pulls the data from the buffer as it needs it, in the course of clocking it out at precisely the right speed.

After eliminating the "speed-error" mental block, I listened some more using Steely Dan's Alive in America, which is my reference for cymbals, and realized that the sound quality is as good as I've ever heard through my Zen DAC V2, and that's very good.

But the icing on the cake is that there were no interruptions while listening for hours. There was an interruption at first, but it was apparently caused by something I did, and hasn't happened again.

So, this might be the solution to attaining bit-perfect playback, without interruptions, on Linux. But I wouldn't bet on it, because I thought I was in the clear with Celluloid on a full installation of Ubuntu Mate on a µSD card, until it started cutting out on the first day of the Labor Day 3-day weekend. If the interruptions are triggered by the system's calendar, they could still happen.

In case the interruptions strike again, I've ordered an Android tablet which I would use for running the Neutron player, which has bit-perfect capability and actually has a polarity ("phase") inversion function, which I thought the music industry had forbidden on mass-market gear. I plan on using the tablet to drive the 15-foot (or so) USB3 cable which I've been using between my mini-PC and the Zen, which works because the frequencies involved are relatively low (all my files are CD-grade). For best sound quality, I leave the Zen powered up constantly using a 5V wall-wart plugged into the back, so the tablet wouldn't have to supply any power to it.