Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[amsco15]

Some here might be interested in this post by PS Audio's Ted Smith.  He wrote the software the runs PS Audio's Directstream DAC.  Post #22

https://forum.psaudio.com/t/bit-perfect-or-not/5306/20

[RD James]

I’m not using the bridge with JRiver, but with JRiver MC 23 via USB the ends of DSD files get chopped off (not quite every time, but most of the times.) I think it’s chopping off the amount of time that matches the file read ahead buffer, but I’m not sure. With DSD it’s also far from gapless even when correctly configured for gapless.

While I’m doing a backup right now and using ASIO double DSD rate sounds like crap, sounds like buffering isn’t working at all. Some single rate almost plays. With WASAPI single rate play much better but double rate is too gappy to listen to. In foobar2000 I can be doing replay gain scanning, wave seek bar scanning, backups, chkdsk’s, and huge file copies while reading my files over wireless from my NAS and everything plays great (not an exaggeration, except for chkdsk that’s what’s going on when I rip CDs). I’ve tried the obvious things, but to tell the truth JRiver MC DSD support is all over the map and I don’t even care to try anymore. Just call it a bad attitude on my part.

[Edit: FWIW this morning JRiver plays single and double rate DSD pretty well except for the notes in the first paragraph above. Maybe having foobar2000 doing a waveform scan in the background helps ]

Quoted.
This doesn't surprise me as I've had issues with pops/clicks on track change or at the start of playback with Media Center that did not exist in other players or DSD converters. There can be issues even when playing back as PCM rather than bitstreaming.
 
The buffering issues when running a backup or with network/disk activity sound like they could be related to memory playback.
Unfortunately none of the recent changes to that have been focused on making playback more robust, just using a lot of RAM.

[Fitzcaraldo215]

My library is mostly DSF files ripped from SACD - thousands of them.  I cannot say I have ever noticed the issue, although a slight tick, almost inaudible and no big deal IMO, was a known problem with the ISO-DSF extraction software.  Later versions of that software corrected that several years ago.  I cannot say I have really noticed much difference in normal listening.  But, I have never spotted anything resembling a noticeable end of track truncation, although it just might possibly be there.

In my earlier experience, an Oppo player did the same tick on direct play of the silver disc, but, again, no truncation I ever heard.  Through the grapevine, I heard Oppo solved this by precisely chopping play a bit or so early based on track timings from metadata on the disc.  Does JR also do this?  If so, is the algorithm perhaps too aggressive, resulting in more truncation?

I spent some time with a classical DSD recording engineer several years ago, and his Sonoma workstation revealed the end of track problem graphically. We discussed it, and it is an artifact of the peculiar and complex DSD representation of data, since DSD, unlike PCM, carries no sample by sample level information.  Instantaneous level is more just like a cumulative integral of the pulse densities, not an explicit data value in the DSD data stream.  So, when the input signal stops, the one-bit samples suddenly stop, even though that might be in the middle of a digital word full of one-bit samples, making that last word and only it an oddball.  Hence the tick and possibly a truncated final DSD word lasting mili- or is it micro-seconds?  But, my feeble logic tells me that if you hear the tick caused by the final bit in the track compared to the next bit with no signal, there has been no truncation of actual source signal.

Again, no big deal.  It is very hard to hear unless someone points it out and you strain to listen for it.  You might hear the tick, but it is doubtful you will hear any obvious end of track truncation. A tempest in a teapot, perhaps?

Incidentally, I do not use memory play.  And, I do play DSD using on the fly conversion to 176k PCM for the application of DSP.

[amsco15]

For the record, I hear it on my system.  A tick between tracks.  Never knew what it was.  Not a big deal in my life.  I only have a handful of DSF files and they’re all DSD 64 (PS Audio Bridge is limited to DSD 64). 

Comes up in transitions between PCM and DSD when playing a playlist.  I’ve always blamed it on the PS Audio Bridge.  Don’t know, but it “repeatedly” happens.

[JimH]

Many DAC's do that when changing between formats.  You can use MC's DSP Studio > Output Settings to force everything to the same format.

[RD James]

Yeah, you can't guarantee silence when switching between DSD and PCM.
When everything is being converted to PCM, or with gapless DSD playback, I wouldn't expect to hear clicks when the track changes - and that is a problem with Media Center.
DSD is very sensitive to this however, due to the nature of it being a 1-bit format. I would recommend avoiding DSD if that album exists in another format.

[Fitzcaraldo215]

As I said earlier, the end of track tick on DSD might not be from JRiver.  Chances are it might have been put there by the rip/extract from SACD or it might be there even in downloads from the studio, even on DSD playback. 

It is not a result of conversion of DSD to PCM, in my opinion.  It happened to my recording engineer friend on pure DSD playback from a Sonoma workstation to a Meitner DAC, even on his own native DSD recordings.  It is a known technical issue in engineering circles when working with DSD, according to my engineer friend.  Perhaps some studios themselves have since taken steps to eliminate it on their DSD recording releases.

I believe the only solution is a sophisticated algorithm to silence it gently and at precisely the right time in the tricky DSD representation, much as the authors of SACD_Extract software did years ago, and Oppo did years before that in firmware.  I used to hear it occasionally and softly on my old Oppo 83 playing the silver disc itself.  Apparently, JRiver now lacks that algorithm.  At one point years ago, the end of track tick problem was also reported on a number of SACD players.  I think many, like Oppo, have since developed a way to suppress the tick.

But, it really does not bother me much at all on most recordings in my JRiver library, many ripped before the problem was fixed in the extract software.  I just have not found it noticeable > 90% of the time, and it is certainly not grounds in my system to avoid DSD releases or to rerip/extract the many I have.

[RD James]

Of the two, I'd certainly prefer that attention was focused on memory playback / buffering than DSD playback, but there is room for improvement. Media Center is causing there to be clicks like there used to be with the old version of sacd_extract.
I believe one of the main causes is a DC offset in the track, which causes the track to end at a non-zero value. This is fine if the album is played back perfectly gapless, but if there is a gap upon track changing, it will click because DSD requires a gradual transition to zero, unlike PCM.

[Fitzcaraldo215]

Yup, although I think if it is solved in normal play, it will also be solved in memory play.  I don't think it is an either/or situation.

[RD James]

Yup, although I think if it is solved in normal play, it will also be solved in memory play.  I don't think it is an either/or situation.

They're separate issues.
One is that DSD playback sometimes has the very beginning or end truncated, which can result in a click at start/end of playback, or when changing tracks during 'gapless' playback.
 
The other is that DSD playback is highly susceptible to interruption if there's heavy I/O access outside of Media Center on the same storage that the track is being played from.
Enabling the "Load full file (not decoded)" Memory Playback option should fix that for the current track if you have split DSD tracks, though it does not work with SACD ISO.
 
However, this does not guarantee that gapless playback of an album or playlist will perform correctly, since it does not keep a rolling buffer with upcoming tracks loaded into memory.
If that storage connection is saturated by another process running on the computer, there can often be large gaps in-between tracks while Media Center slowly loads it into memory.
 
In theory the "load full album (not decoded)" option should fix this, but generally does not due to the way that it's set up.
It is literally only for loading a single album into memory, rather than keeping a rolling buffer of upcoming tracks.
If you have too many tracks, it starts playing directly from storage without loading anything into memory - and it won't tell you this.
It means that playback can be very slow to start (several minutes, even) as it has to wait for all tracks to be loaded into memory before it begins.
And there are no restrictions on how much memory it will use, so it can use up everything that your system has available, which is completely unacceptable for a system that is not 100% dedicated to music playback.
 
They appear to have all the components for a robust memory playback system, but putting it all together just doesn't seem to be a focus for the JRiver team.