JRiver Feature Requests

[SavantGarde]

JRiver's filter does not have pre-ringing.

Its PCM SRC filter (for up- or downsampling) definitely does. MC 20 for Windows as well as for Mac both use the "SSRC High Precision" filter (according to the JRiver Interact forums). Measurements are available here, where it's plain to see that it's an extremely steep linear-phase filter that accordingly rings as a bell.

 

The images you posted concerns conversion from PCM to DSD. Judging from the graphs, MC uses a minimal/intermediate phase filter for that; thus less pre-ringing but more post-ringing.

[ElviaCaprice]

If we are not making any changes to sampling or format on the fly with JRiver, just plain old ASIO native, does it make any difference SQ wise between media players?

[Skeptic]

My main "feature request" is to finally get software that does look like it was designed for MacOS and not ported from PC with Mac as an afterthought.

 

Suppose this will never happen.

It can happen, but they need to be dedicated to improving the skinning engine.

I already have a large portion of the work completed on an OS X skin which fits in with the general aesthetic of that OS - my plan was to release it when version 20 shipped.

But what I have seen from JRiver is that they are willing to implement "quick fixes" but seem unwilling to dedicate the resources to more complex issues with the skinning engine - and fixing those would be required to have a program which looks "native" on OS X.

You can only get about 2/3 of the way there in its current state, and things break if you want retina support.

 

If we are not making any changes to sampling or format on the fly with JRiver, just plain old ASIO native, does it make any difference SQ wise between media players?

If you leave the volume at 100% and are not performing any DSP, it should sound the same as any other "bit-perfect" media player.

Once you start adding in DSP, which includes simple things like adjusting the volume level, that is when you start to see differences between players.

JRiver has a robust 64-bit audio engine with great VST plug-in support, but it fails on basic things like volume reduction due to the fact that they are using RPDF dither, while other players will be using TPDF, noise-shaped TPDF, or licensing proprietary systems like iZotope. (which seems to be noise-shaped TPDF if configured properly)

Their reasoning seems to be that you won't hear this problem if you're using a 24-bit output anyway.

I'd argue that a lot of networked streaming solutions (e.g. Airplay) are still using 16-bit so it can be an audible problem.

 

Its PCM SRC filter (for up- or downsampling) definitely does. MC 20 for Windows as well as for Mac both use the "SSRC High Precision" filter (according to the JRiver Interact forums). Measurements are available here, where it's plain to see that it's an extremely steep linear-phase filter that accordingly rings as a bell.

And it was v20 where it was upgraded to the "high precision" variant.

They have said many times that they don't plan on changing the PCM resampling engine.

[ElviaCaprice]

If you leave the volume at 100% and are not performing any DSP, it should sound the same as any other "bit-perfect" media player.

Once you start adding in DSP, which includes simple things like adjusting the volume level, that is when you start to see differences between players.

JRiver has a robust 64-bit audio engine with great VST plug-in support, but it fails on basic things like volume reduction due to the fact that they are using RPDF dither, while other players will be using TPDF, noise-shaped TPDF, or licensing proprietary systems like iZotope. (which seems to be noise-shaped TPDF if configured properly)

Their reasoning seems to be that you won't hear this problem if you're using a 24-bit output anyway.

I'd argue that a lot of networked streaming solutions (e.g. Airplay) are still using 16-bit so it can be an audible problem.

 

 

Thank you Skeptic for that explanation and confirmation of JRiver. I do not use DSP or volume. Volume is disabled and I allow the Chord Hugo to act as the preamp.

With your explanation it would make no sense for me to change to any other media player such as HPQ if all I would be achieving is the same SQ.

[Nikhil]

Once you start adding in DSP, which includes simple things like adjusting the volume level, that is when you start to see differences between players.

 

JRiver has a robust 64-bit audio engine with great VST plug-in support, but it fails on basic things like volume reduction due to the fact that they are using RPDF dither, while other players will be using TPDF, noise-shaped TPDF, or licensing proprietary systems like iZotope. (which seems to be noise-shaped TPDF if configured properly)

 

Their reasoning seems to be that you won't hear this problem if you're using a 24-bit output anyway.

I'd argue that a lot of networked streaming solutions (e.g. Airplay) are still using 16-bit so it can be an audible problem.

 

That is really useful info. I have Volume Disabled on my Audio PC as I found it affected sound quality.

I would prefer to have DSP settings turned off but I need Output Format settings to convert down to PCM when needed.

[Nikhil]

Its PCM SRC filter (for up- or downsampling) definitely does. MC 20 for Windows as well as for Mac both use the "SSRC High Precision" filter (according to the JRiver Interact forums). Measurements are available here, where it's plain to see that it's an extremely steep linear-phase filter that accordingly rings as a bell.

 

Thanks for the info on the Interact discussion on PCM settings. Must read up on that.

[Nikhil]

Filters? In v20 they added a JPlay filter, maybe they'll add a Server 2012 filter in v21!

 

Maybe you didn't see the JPlay debacle, but they went out of their way to make them not compatible. I wouldn't expect much.

 

Not saying anything to start another discussion here ... but they are responsive when convinced.

 

Optional different Sample Rate Conversion: SoX Resampler library

[firedog]

Skeptic:

If you leave the volume at 100% and are not performing any DSP, it should sound the same as any other "bit-perfect" media player.

 

And there are those who will argue that this point is not correct. Evidence in favor is that measurements have shown different levels of ground plane noise produced when the only variable changing is the player.

[Skeptic]

Skeptic:

And there are those who will argue that this point is not correct. Evidence in favor is that measurements have shown different levels of ground plane noise produced when the only variable changing is the player.

Then you have a ground problem, which is allowing noise to be transmitted from the PC to your DAC.

That's a hardware problem, not a software issue.

 

Sure, you can affect this noise by the amount of CPU load present, but that doesn't mean the "fix" is to futz about with that sort of thing.

The actual fix is to sort out the underlying ground problem.

 

JRiver has some of the lowest CPU and Memory usage during playback of any player that I've seen, as it is.

[firedog]

Then you have a ground problem, which is allowing noise to be transmitted from the PC to your DAC.

That's a hardware problem, not a software issue.

 

Sure, you can affect this noise by the amount of CPU load present, but that doesn't mean the "fix" is to futz about with that sort of thing.

The actual fix is to sort out the underlying ground problem.

 

JRiver has some of the lowest CPU and Memory usage during playback of any player that I've seen, as it is.

 

First, it isn't me.

 

Second, John Swenson, did the measurements and reported on them a while back. Even the same software using different settings caused measurable changes in ground plane noise being created by the PC. You can read about it - there are various reports posted on the Net. Third, according to John, these results had little relationship to CPU load. Fourth, I think JS knows when he has a ground problem or not.

 

I don't think the issue is a ground problem. I realize from your various posts that you think you know all the answers. But maybe you don't. Maybe there are ideas you haven't tested or considered, and not everything neatly fits into the intellectual structure you've created that explains everything.

[Skeptic]

First, it isn't me.

Second, John Swenson, did the measurements and reported on them a while back. Even the same software using different settings caused measurable changes in ground plane noise being created by the PC. You can read about it - there are various reports posted on the Net. Third, according to John, these results had little relationship to CPU load. Fourth, I think JS knows when he has a ground problem or not.

 

I don't think the issue is a ground problem. I realize from your various posts that you think you know all the answers. But maybe you don't. Maybe there are ideas you haven't tested or considered, and not everything neatly fits into the intellectual structure you've created that explains everything.

As I said, you are trying to affect the symptoms, rather than address the cause.

The cause is a grounding issue, which is hardware related.

 

The severity of this issue may vary depending on the software in use - whether that's the player or other processes loaded on the system - but the underlying issue is a hardware one.

Solve that, and software stops making any difference.

 

But this really isn't relevant to JRiver.

[4est]

It is hardware related, but does not take the player program out of the equation. It seems to exist on all OSs, and not readily/easily removed or isolated.

As I said, you are trying to affect the symptoms, rather than address the cause.

The cause is a grounding issue, which is hardware related.

 

The severity of this issue may vary depending on the software in use - whether that's the player or other processes loaded on the system - but the underlying issue is a hardware one.

Solve that, and software stops making any difference.

 

But this really isn't relevant to JRiver.