I hate this issue! Can’t shuffle my library without end-of-song cut-offs!
Are you using the bridge?
If not the DS can’t know when a track is ending ahead of time so it’s not the DAC.
Just recently I noticed with foobar2000 when a DSD track is followed by a PCM track the end gets cut off (tho foobar2000 looks like it’s still playing.) [Edit - deleted bogus stuff - After uninstalling all old ASIO proxy stuff, reinstalling latest foobar2000, and latest foo_input_sacd everything works again. So “Never mind”.]
Confused. Woot - you have Redcloud, (hence the thread name) and are criticising it, or this is a thing you want fixed in it, from the perspective of a Huron user?
I’m sure it’s the second…
BB- no, not yet. Looking for a fix from ALL firmwares for this issue. Thanks for asking!
Ted- Yes using the bridge 2, JR 22 and 23 for mac, 23 for PC, all 3, same issue on all, as always has been. USB no cut-off. It’s an old issue but most peeps seem not to shuffle as much as I do. As a half way fix I make smart playlist of JUST DSD, or 16 bit, or 24/92, or etc… then shuffle just the like files. Sucks.
Sorry about that: I can’t help you with the bridge issue - I’ll make sure that PS Audio engineering knows about this thread, but I don’t have any idea if your problem had been addressed or can be addressed for Redcloud.
Try this. Right click the Bridge in the main JRiver menu, select disable SetNext. The problem should be much better. Let me know. The Bridge is not a properly DLNA compliant device. JRiver includes some fixes. I have the same problem and this mostly fixes it.
Below is a thread on the JRiver site I started discussing the problem. I don’t expect a better fix from the JRiver team (Bridge II is too esoteric, they would need one in hand) then the one I described above.
AndrewFG is the resident DLNA expert. His explanation makes the most sense. I’m pretty sure Bridge II handles gapless in a non-standard way. Makes sense since the lack of gapless in Bridge I was such a limiting omission!
Elk, maybe change the thread title. This is definitely a Bridge II issue.
Exactly, when I had this issues with Jriver, it was exactly one of these settings.
Not to be too pedantic but I’m pretty sure this is a Bridge II problem and not JRiver. However, JRiver is very sensitive to renderers that don’t strictly conform to the DLNA standard.
The fix is to disable “SetNext.” There are still some abrupt track changes but the final few seconds of the preceding song are not truncated. Note, gapless works as intended with SetNext enabled or disabled!
I also experimented with “ignore Transport Events.” This experiment resulted in tracks not advancing at all. Some of my experiments provide an inconsistent result so I hesitate to make a definitive observation statement but am doing so anyway.
It’s all part of the fun!
We’re working with the Convers module guys to get a fix for the gapless cutoff at the end of tracks with Jriver and different file formats. Hopefully it will be available in the upcoming release.
Cool! Hope their successful!