JRiver MC Version 18

Then I'm confused. JRiver does nothing special, but you posted you "like their approach"; they charge $50 for what is offered elsewhere free. JPlay does indeed try to do something special, which may or may not matter; they charge €100 for something not offered elsewhere. JRiver accuses JPlay of being a "hoax" with no evidence? JPlay does what it claims; whether that results in better sound is certainly open to debate, but not a "hoax", and they offer a free trial (as does JRiver).
 
Last edited:
JRiver does nothing special, but you posted you "like their approach"; they charge $50 for what is offered elsewhere free.

To me it appears they are open and honest about what they provide. You choose if you want to pay for the features they provide or go for a free package.

JPlay does indeed try to do something special, which may or may not matter; they charge €100 for something not offered elsewhere.

And what is the special thing JPlay tries to do that is not offered elsewhere?
 
Another interesting aspect to throw in here is that when I tried Jriver vs Foobar/ASIO4ALL they didn't sound the same to me. I'm not alone in thinking this yet they are both bit-perfect. As for JPLAY with JPLAYmini it's different again (best IMO).

Re the Jriver popup - I don't have an issue with their saying in may degrade the sound - this is their subjective opinion and however Jriver have engineered their sound it's presumably what they prefer. I do have a big issue with their saying JPLAY is a Hoax. This oversteps the line of what is reasonable to say, even by a competitor. Even if someone doesn't like the sound of JPLAY or thinks it sounds the same as every other bit-perfect player, there's no doubt it plays music so it's not a hoax.

As others have said if it can "degrade the sound" but as it's bit-perfect then the Jriver argument doesn't stack up.
 
...

And what is the special thing JPlay tries to do that is not offered elsewhere?

at least "hibernation" mode and decode FLAC (on hard drive) to WAV (in RAM); I don't know whether it makes a difference or not, but many people apparently do. And what is not "upfront" about JPlay? And how is calling a competitor's product a "hoax" with no evidence either way in anyway ethical or admirable?

In my system, Foobar/ASIO sounds a little better (to me) than JRiver. As I said, I haven't yet tried JPlay.
 
Another interesting aspect to throw in here is that when I tried Jriver vs Foobar/ASIO4ALL they didn't sound the same to me. I'm not alone in thinking this yet they are both bit-perfect.
I think I mentioned in this thread that I compared Foobar to WMP and the former sounded far better. I went searching for reason and found out in default mode, it uses the same pipeline as WMP. And the FAQ emphatically said there is no sound quality difference. I went and tested again and this time they sounded the same. Now here is the very interesting part: if I imagine the differences I used to hear, I can bring them all back! Yet if I remind myself that they can't be there, they vanish. Don't know if everyone can do this. It is not easy to suspend "belief." :) But it is a worthwhile experiment. Try to tell yourself and convince yourself that there can't be a difference and see if it changes the outcome.

Of course the definition of placebo effect is that it is not a lasting difference.

Re the Jriver popup - I don't have an issue with their saying in may degrade the sound - this is their subjective opinion and however Jriver have engineered their sound it's presumably what they prefer. I do have a big issue with their saying JPLAY is a Hoax. This oversteps the line of what is reasonable to say, even by a competitor. Even if someone doesn't like the sound of JPLAY or thinks it sounds the same as every other bit-perfect player, there's no doubt it plays music so it's not a hoax.
If it is a plug-in, how could it be a competitor? Let me give you an analogy. When I was at Microsoft, we would get millions of crash reports that users would send to us. When examining the crashes for Internet Explorer, by far and I mean vast majority of it was caused by Flash plug-in. Wanting to be politically correct as you suggest, we did not tell the world about it. But I can't tell you how tempting it was to issue a press release and say that the #1 cause of crashes was not our software, but this poorly designed plug-in. I am pretty sure the user community would have been better for it had the spotlight put on Flash to clean up its act. To this day it is the #1 thing that causes slow down and crashed on my Chrome browser.

By the same token, JRiver may be doing what we wished we could do at Microsoft. If the plug-in crashes, slows things down, and in general causes reliability problems, it will "degrade" the experience and Jriver potentially get the black eye. So I can see how someone says, "look guys, this is junk, it has no redeeming value other that add bugs to our software; let's let the world know in no uncertain terms that is the case," just like we wished we could have done with Flash.

As others have said if it can "degrade the sound" but as it's bit-perfect then the Jriver argument doesn't stack up.
I agree they have left the door ever so slightly open on their wording to invite the same argument against them. So they should change this wording. Instead of calling it hoax, they should say something along the lines of what I said, "it is the opinion of JRiver that fidelity differences cannot come from changes made by this plug-in; using it may degrade your experience should the software make changes that cause playback to be interrupted or the software to crash." They would still make their point without causing so much uproar.
 
Even if someone doesn't like the sound of JPLAY or thinks it sounds the same as every other bit-perfect player, there's no doubt it plays music so it's not a hoax.

I don't think anyone is claiming it doesn't play music. But nobody is pretending that the reason to pay extra for jplay is just so that it can play music. If you read the jplay FAQ, it most definitely implies that it sounds better than other players (without actually specifically stating so - probably because of legal reasons).
 
And what is not "upfront" about JPlay?

Have a look at stuff like their FAQ. Would you not agree that they do everything they can to make it sound like their product sounds better than any other, without actually saying anything that could be nailed down? Where I come from, that is called "weasel words".
 
Try to tell yourself and convince yourself that there can't be a difference and see if it changes the outcome.
That's one approach that is worth using; it uses short term memory which is very fickle and very short lived (20s?). Hence I feel it's likely subjects will be very suggestible but all approaches are worth trying, there's no single best way. Personally I find long-term listening more reliable but in product development it's not really viable to listen to something for a week or two then swap over.


If it is a plug-in, how could it be a competitor?
It can be a competitor and complimentary. I tried:

- Jriver slandalone
- Jriver + JPLAY
- JPLAY standalone

I went with JPLAY so in this case JPLAY cost Jriver a possible sale. It's not just a plug-in....:)

Regarding support, if Jriver said that any problems reported need to be replicated with JPLAY not installed this would be sufficient and a reasonable position.
 
Last edited:
I have found that with complex technology, intuition is good for ideas, but logic and mathematics is much better for actual facts. Why would the waveform to be played make any difference to the computer when operating in bit-transparent mode? It takes exactly the same effort to move a block of bytes, no matter what the values of those bytes are.

Perhaps I should rephrase this............

A steady-state tone will have a repetitive data pattern. That leads to a different type of problem, which is the reason companies like Wavecrest make analyzers to measure that sort of thing. (Which is about all it is good for. Which is to say it is lousy for measuring plain ol' jitter. The noise floor of its internal oscillator limits that.)
 
Indeed. And I find that JRiver has an approach that is more likely to make good sound, whereas I am suspicious of the claims made for Jplay. If that makes me a "fan boy" for intellectual honesty, so be it.

Uh, I was not referring to you. Sorry you have a guilty conscious. (I was referring to the opposing camp, in case anyone cares.)
 
A steady-state tone will have a repetitive data pattern.

Yes, but... :)

If you have a 1.05-KHz steady tone at, let's say, 16 bit 44.1 KHz stereo, the one-waveform repetitive data pattern would only repeat after 84 bytes (1344 bits). And that is in the rare special case that the test sample rate is an exact integer multiple of the test tone frequency - if not, it will take *much* longer for the pattern to repeat. So on a bit-to-bit level the repetition doesn't matter - it doesn't affect the amount of jitter measured (it of course does affect the jitter spectrum).
 
Uh, I was not referring to you. Sorry you have a guilty conscious.

I always feel a bit guilty whenever I find myself defending any commercial product :)
 
There was a code segment that used to be a part of the VLC project some years ago...
It could route audio data on various paths using in-buffering methods inside a cpu. Then the data was feed the rest of the playback chain.
Various routes sounded slightly different. It is quite a long time ago since they removed it from VLC (Videloan).
It would for sure change or alter the sound.
But there were some setting that would NOT alter it, you would like have to play around based on CPU, Memory Motherboard and such things. It was hardware dependant.
It seemed clearer, more focused and like, better "time aligned". Less Jitter...

It could be the same people? That did that code snippit used by VLC?

Imperial.
 
Archimago has released his latest measurements, this time on JPLAY.

"Bottom line: With a reasonably standard set-up as described, using a current-generation (2013) asynchronous USB DAC, there appears to be no benefit with the use of JPLAY over any of the standard bit-perfect Windows players tested previously in terms of measured sonic output. Nor could I say that subjectively I heard a difference through the headphones. If anything, one is subjected to potential bugs like the 24/48 issue (I didn't run into any system instability thankfully), and the recommended Kernel Streaming mode utilizes significant CPU resources when buffer size is reduced (which the software recommends doing). I imagine that CPU utilization would be even higher if I could have activated the DirectLink (1-sample buffer) setting."
 
Archimago has released his latest measurements, this time on JPLAY.

"Bottom line: With a reasonably standard set-up as described, using a current-generation (2013) asynchronous USB DAC, there appears to be no benefit with the use of JPLAY over any of the standard bit-perfect Windows players tested previously in terms of measured sonic output. Nor could I say that subjectively I heard a difference through the headphones. If anything, one is subjected to potential bugs like the 24/48 issue (I didn't run into any system instability thankfully), and the recommended Kernel Streaming mode utilizes significant CPU resources when buffer size is reduced (which the software recommends doing). I imagine that CPU utilization would be even higher if I could have activated the DirectLink (1-sample buffer) setting."

It's amusing how people keep using the same flawed tests as proof that there is no difference! Repeating flawed tests ad-nauseum & publishing the results as if it has any significance is just wasting bandwidth.

At least one small thing might come of it - some people here may realise that calling Jplay a plug-in to Jriver is mistaken.
 
Archimago has released his latest measurements, this time on JPLAY.

"Bottom line: With a reasonably standard set-up as described, using a current-generation (2013) asynchronous USB DAC, there appears to be no benefit with the use of JPLAY over any of the standard bit-perfect Windows players tested previously in terms of measured sonic output. Nor could I say that subjectively I heard a difference through the headphones. If anything, one is subjected to potential bugs like the 24/48 issue (I didn't run into any system instability thankfully), and the recommended Kernel Streaming mode utilizes significant CPU resources when buffer size is reduced (which the software recommends doing). I imagine that CPU utilization would be even higher if I could have activated the DirectLink (1-sample buffer) setting."
Pretty strong data pointing to lack of differences in playback method. It also makes the point I made earlier. See this measurement graph for example:

16-44+THD.png


There appears to be tiny differences in low frequencies for example. In my test I attempted to zoom into these but what I found is that from run to run with the same gear, the variations would be there so it is not like one is ever so slightly better. The systems being measured and or measurement system have that much variation in them.

Back to Jplay, the fundamental theory of what it is supposed to do, i.e. change CPU and with it, reduce noise/jitter has been shown to not do anything if one uses proper (async) interface to a DAC. So we can throw out the window the objective theories of what it does.
 
I wonder why he couldn't get DirectLink working, even I can do this on a typical i5 laptop. He must be using a very old machine or have a terrible setup. That's all I can conclude.
 
I wonder why he can't hear any difference either? Could it be he's using headphone listening?
I know that Amir realises that J-Test is inappropriate for USB testing so surprised that he hasn't commented on this as a waste of testing time. This has already been pointed out to Archimago some time ago but he continues to use it. Why?

BTW, 'native' is defined as 16bits for 44 and 48 and 24 for anything above....So he obviously is incorrectly reporting flaws that he attributes to software which are in fact flaws in his understanding/reading

As for the other tests -- they are obviously flawed as they don't reveal the differences picked up by listening!!
 
It's amusing how people keep using the same flawed tests as proof that there is no difference! Repeating flawed tests ad-nauseum & publishing the results as if it has any significance is just wasting bandwidth.

I think we would all love to see some measurements that *do* show some differences.
 
I think we would all love to see some measurements that *do* show some differences.
Why, can you not trust what you hear & accept that in time these measurements will come?
 

About us

  • What’s Best Forum is THE forum for high end audio, product reviews, advice and sharing experiences on the best of everything else. This is THE place where audiophiles and audio companies discuss vintage, contemporary and new audio products, music servers, music streamers, computer audio, digital-to-analog converters, turntables, phono stages, cartridges, reel-to-reel tape machines, speakers, headphones and tube and solid-state amplification. Founded in 2010 What’s Best Forum invites intelligent and courteous people of all interests and backgrounds to describe and discuss the best of everything. From beginners to life-long hobbyists to industry professionals, we enjoy learning about new things and meeting new people, and participating in spirited debates.

Quick Navigation

User Menu

Steve Williams
Site Founder | Site Owner | Administrator
Ron Resnick
Site Co-Owner | Administrator
Julian (The Fixer)
Website Build | Marketing Managersing