JPLAY Responds: An Open Letter

[jkeny]

John: "If I was the only one who heard such improvements then I would agree with you. Did I test myself using an informal blind test - sure I did. If, I also hear many, many people all reporting agreement on the improvements then I take note. I know "mass hypnosis" & suggestibility can be used to explain this, sure!!"

The above explanation only works if you ignore the users of jplay who heard no difference, surely they are just as likely to be correct as the ones who do hear a difference. When there is no objective evidence of any difference, and there is no plausible explanation given of even the wildest speculation of how there could be a difference, then one should very well question their own observations if they hear a difference. BTW, I care not whether you are blinded, in fact I generally do not believe in blind testing, as it tends to test the observer rather than the DUT.

There will always be outliers in every test - we normally look at the centre of the bell-curve for the most probable result, not the outliers

"I think you fall into the trap of assuming that the developers blindly just try "random" changes to see what affect it will have. This is a naive, black & white view of how such developments occur. People often follow their theories/ instincts in developing products, analysing the results with listening tests as they proceed. The end result may not easily succomb to measurements to show these audible differences but it therefore does not invalidate them. So I disagree with your hypothetical picture of the software being developed in a random way just because they have no measurements to show what they can hear."

I do not have a naive view at all, I consult in product development. The problem I have here, is that the jplay developers offer no explanation of how their SW could improve sound (assuming a working asynchronous interface environment). This is what I am responding to, please go back and read my post because you appear to have not gotten it. When they admit to not knowing how, or why their approach could improve sonic performance, they are also admitting to having no working theory to start with. If one has no working theory to start with, then development can only occur by random chance, trying things, and seeing what happens.

Have you read this thread & their reply? Let's see They say "We cannot _control_ timing in OS (due to its design) but we can _influence_ it to a great deal indeed!
And why do we need to influence timing?" ..."Surprisingly, it turns out that size of this buffer which is a sort of a necessary evil, has an impact on sound as in, smaller buffers sounding better! We don’t know why (at least we can measure buffer size lol) but we can theorize that smaller is simply better as less data has to be moved around which means more of it (ideally all) can stay closer to CPU simplifying the process by minimizing ‘fetch data from ram bank’ steps." I'm not going to go through each of their points, it's there in the thread for you to read but I would suspect that as you use Linux for audio, you already know most of the points they make. For you to then try to paint a picture of random, haphazard development is really being somewhat disingenuous, I believe

Now, if noise reduction (airborne and USB cable borne RF) is all that jplay is affecting then it should be relatively trivial for the developers to pay some RF engineers to make the appropriate measurements

You are taking a guess at what the resultant effect of their software should be. Did they say that? From that guess you are building a strawman argument, etc. - I'm sure you know the routine by now, you have been on many forums

When you were testing the different software that you mentioned before - where you found that they sounded different - how did you settle on the particular one you use now? Did you SOLELY listen to it or did you get measurements from the manufacturers? I presume you got these measurements as according to yourself "Anyone who bases their evaluation of an audio system SOLELY on listening is making a lot of big mistakes."

 

[Julf]

What are the "shortcomings" you are referring to? Just curious.

I guess the problem isn't so much with the core standards as with the numerous confusing and sometimes incompatible profiles and implementations.

 

[Julf]

"Surprisingly, it turns out that size of this buffer which is a sort of a necessary evil, has an impact on sound as in, smaller buffers sounding better! We don’t know why

So they are stating that they don't know why their software sounds the way it sounds.

You are taking a guess at what the resultant effect of their software should be.

Do you think there could be something else affecting sound besides:

- the actual data
- jitter
- noise?

All 3 should be easy to measure (the first one is trivial), so it should be straightforward to show the improvements, if there are any.

 

[Vincent Kars]

I guess the problem isn't so much with the core standards as with the numerous confusing and sometimes incompatible profiles and implementations.

Common problems are
Lag of gapless playback. Some devices do but most don’t. They say gapless is not part of the DLNA standard but some say it is part of UPnP and UPnP is part of DLNA.

Transcoding: Often you can’t control what is send to the renderer. Might be MP3 to save bandwidth.
If you can control it, e.g. all is send as 24 bit LPCM, the renderer might not support all the sampling rates.

Tagging: different definitions of Album e.g. one uses Album+Album Artist, the other Album+ Artist.
As far as I know, custom tags are not supported.
I know only one server (Minim) broadcasting tags like composer, conducter, orchestra.
Most stick to the pop-model Album, Artist, Genre
Some examples:
http://www.thewelltemperedcomputer.com/SW/Android/MediaPlayers/UpnPlay.htm
http://www.thewelltemperedcomputer.com/SW/Streaming/MinimServer.htm
http://www.thewelltemperedcomputer.com/SW/Streaming/Asset.htm

 

[cmiu]

Just a test

Hi Jkeny,
Sorry for my poor English.
I’m following this thread with interest hoping that I will have the chance to improve my system.
My current system is comprised from headless disk-less custom made pc (linux mpd) => audiobyte silver dragon dac => vtl it85 amp => jmr offrendre v2. The room is medium threated – only bass traps without diffusers. From my limited experience the best way to achieve best SQ is to have a minimal OS running , good shielding on interconnects + good cable routing (mains vs interconnects) and good music source (meaning good recording and mastering).
I have my old htpc computer (win7) acting as a file server and video player which I used for a quick test of Jplay vs foobar. Just to be sure that I will not miss anything I routed USB thru a Stello U3 (USB to SPDIF- galvanic isolation) and listened the output thru speakers and HD650 heaphones (from IT 85).

I used Jplay with KS and hibernate (the hibernate did not returned the normal OS operation and I had to hard reset the computer therefore I did not use it to test). I was not able to make Jplay to play dsd files (USB – dop) as my DAC does not have an asio driver.
I had listened and I was not able to discern the huge improvement that everybody is raving about by using Jplay. Several tracks 4-5 ,switching from wasapi output to foobar, jazz, clasicall CD rez and Hi rez 94 and 192. total time about 2 hours.
I think it is important to mention that I clearly hear differences between computer analog output (on board and discrete creative something) and USB output thru dac. But I cannot hear differences using Stello SPDIF vs direct USB . But again I can hear differences during tube rolling for my headphone amp (bottle head crack).
One explanation should be that I use only premium motherboards (and components) when I build my systems and pay attention to the other variables. Another that I kinda deaf.
I have the following questions:
- Does any of the Jplay users have those fancy dacs that have bitperfec led or test?
- Did you tried for example Sygnalist HQPlayer or pure player from dyiaudio
My comments regarding jplay are as follows:
- I can hardly thrust a manufacturer or software developer when they are not fully transparent. If Jplay team really found a way to do what they are saying that their software is doing without a proper software patent, the software player market will be full of the programs using that approach (it is very simple to reverse engineer a software or in this case a driver emulator)
- The last solution from Jplay comprising of 2 MS server is … I don’t know how to put it because I don’t want to offend any one. Just from economically perspective: software licenses 900 euros (2 MS + Jplay +- Jriver) + 2 computers …. With this kinda money you can buy and atom system and a fancy DAC and you are set.
At the moment, in my personal opinion, using the above system, I can say that in a well tempered computer / system bitperfect players sound the same.
I will go now to make some DRC filters and play around and there I will have for sure some SQ changes.
Cheers
PS: I still try to make some tests when my friends will drop by (KS only )

 

[Phelonious Ponk]

So they are stating that they don't know why their software sounds the way it sounds.



Do you think there could be something else affecting sound besides:

- the actual data
- jitter
- noise?

All 3 should be easy to measure (the first one is trivial), so it should be straightforward to show the improvements, if there are any.

And, lacking this critical, fundamental knowledge, they have managed to make their software sound superior. Serendipity?

Tim

 

[barrows]

Common problems are
Lag of gapless playback. Some devices do but most don’t. They say gapless is not part of the DLNA standard but some say it is part of UPnP and UPnP is part of DLNA.

Transcoding: Often you can’t control what is send to the renderer. Might be MP3 to save bandwidth.
If you can control it, e.g. all is send as 24 bit LPCM, the renderer might not support all the sampling rates.

Tagging: different definitions of Album e.g. one uses Album+Album Artist, the other Album+ Artist.
As far as I know, custom tags are not supported.
I know only one server (Minim) broadcasting tags like composer, conducter, orchestra.
Most stick to the pop-model Album, Artist, Genre
Some examples:
http://www.thewelltemperedcomputer.com/SW/Android/MediaPlayers/UpnPlay.htm
http://www.thewelltemperedcomputer.com/SW/Streaming/MinimServer.htm
http://www.thewelltemperedcomputer.com/SW/Streaming/Asset.htm

Vincent: thanks for responding, certainly I agree, gapless playback is critical. The Rendu plays gapless perfectly with jriver as the streaming SW at the serving device. Any player which cannot be gapless is a total failure as far as I am concerned, in fact, I do not understand what the **** people (developers) are thinking when they make things which will not play gapless? Transcoding is not a problem, not sure what devices/streaming SW you are referring to here? We could just as easily criticize direct play computer audio (iTunes for example) for the same thing, if it is not set up properly. Like any computer audio approach, Ethernet streamers have to be chosen carefully, and set up carefully, but when this is done, they do not have the problems you are pointing out. The Rendu, supports all PCM rates to 24/192, and DSD 64. Support for DSD 128 may be added in the future; again, you are pointing out limitations that only exist on some hardware, we could say the same thing about some USB DACs as well… I personally have only used minimserver, so its tags are about equal to iTunes. Tags are a problem (for some people) for many direct computer audio players, again, this is a problem shared by computer audio across the board, not specifically with Ethernet. Personally, I get all the info I need (artist, album, track, cover art) with minimserver/plugplayer, and I am told that the jriver/jremote combo is much better.
My point is that Ethernet is a viable alternative to a direct server, and that there really are no limitations to it, either approach can work very, very, well and give excellent sonic performance and a great interface experience. Personally, I still choose to use a custom server via USB (my house is not wired for Ethernet, and I am lazy…) but I have tested the Sonore Rendu, and was really impressed with the ease of use and sonic performance-I cannot speak about the other devices out there, but I suspect that there are other good units as well, the Ayon Ethernet DAC looks pretty interesting to me, and I have heard the Linn Klimax DS at dealers sound very, very good as well. I have no interest in saying Ethernet is better than USB, or Firewire is better than Ethernet, etc… In my experience all of these approaches can result in superb performance when well implemented, I just want people to consider that there is more than one viable way to do things and still get SOTA sonic performance.

 

[barrows]

hmmm...

jkenny: It appears you may have access to an actual survey of everyone who has ever tried jplay, and you can show us the numbers of how many think it is improving sonic performance and how many have found no improvement? If not, then you have no basis for your claim (opinion actually) that the "no improvement" group are outliers. When I see someone of the listening experience level of Bruce Brown say that he heard no difference, I do not consider that observation something which can be so easily ignored. Mr. Brown is a professional who is paid specifically for his ability to hear differences, he is much less likely to be imagining things than the average audiophile.

Yes, I have made noise measurements (rather crudely, but still actual measurements) of the RF emissions of my current server, both airborne, and what is going out on the AC line. Specifically because of these measurements I decided to go forward and build a server which used even less power, and to power it from batteries to isolate that noise from the mains. I also listen, to music.

As to a specific example: you point out that the developers found that shorter buffers improve sound… but, there is no explanation of how/why this could be. And, there is not even any wild speculation about how/why this could be. In other words: they do not know! Because they do not know, they could not have started to investigate this with a working theory. Without a working theory, they would be just randomly trying different approaches, and then subjectively listening to the results. "hey, what do you know, these shorter buffers sound great, we should do that, cool!"

I am more concerned about high sunspot activity altering the sound of my system than I am about jplay at this point. I am willing to listen to anyone who can give a considered explanation of a plausible theory, of how this software improves sonic performance… so far I, outside of the noise possibility, have not heard a single plausible theory, as to how jplay could improve the sound of the system, just random things like "timing is critical", which we all know is not true in an asynchronous DAC environment.

 

[Vincent Kars]

Barrows:
Thanks for your elaborate and interesting reply.
It almost make me overcome my aversion to streaming audio.

I have no interest in saying Ethernet is better than USB, or Firewire is better than Ethernet, etc…

I can only agree (as long as it is async ? ).
Spoilt as I am by JRiver with all its custom tags (I use a couple like Opus, Catalog, Year_Composition, instrumentation) I do think interface wise, streaming is a bit down to direct playback.

 

[barrows]

Barrows:
Thanks for your elaborate and interesting reply.
It almost make me overcome my aversion to streaming audio.



I can only agree (as long as it is async ? ).
Spoilt as I am by JRiver with all its custom tags (I use a couple like Opus, Catalog, Year_Composition, instrumentation) I do think interface wise, streaming is a bit down to direct playback.

As to the interfaces, of course. I was considering them equal with the assumption of good implementation, they all have the potential to be terrible when done poorly as well!
As to jriver, if you use it to stream, and jremote as your client, do you then have access to all of its tags? From what I have been told by those who have used it, jriver is the best option for streaming to a renderer like the Sonore Rendu.

 

[jkeny]

jkenny: It appears you may have access to an actual survey of everyone who has ever tried jplay, and you can show us the numbers of how many think it is improving sonic performance and how many have found no improvement? If not, then you have no basis for your claim (opinion actually) that the "no improvement" group are outliers. When I see someone of the listening experience level of Bruce Brown say that he heard no difference, I do not consider that observation something which can be so easily ignored. Mr. Brown is a professional who is paid specifically for his ability to hear differences, he is much less likely to be imagining things than the average audiophile.

Indeed, I do have an idea of the number of people who think Jplay is well worth purchasing from the sample of my customers who I recommend it to. The overwhelming majority who have tried it report that it is great (>90%) to the extent that they purchase it. This is my, not insignificant, sample size which I judge it by. Correct me if I'm wrong but you have no feel for the numbers either positive or negative.

Yes, I have made noise measurements (rather crudely, but still actual measurements) of the RF emissions of my current server, both airborne, and what is going out on the AC line. Specifically because of these measurements I decided to go forward and build a server which used even less power, and to power it from batteries to isolate that noise from the mains. I also listen, to music.

I didn't ask you about measurements on your system but rather about the measurements of the various software players you used before you settled on your existing playback software. You claim that selecting by listening alone would be a bad mistake so I assumed you got measurements from the software manufacturers as you expect from Jplay? I would also be interested in the underlying philosophy they used to develop their software or did they use random techniques?

As to a specific example: you point out that the developers found that shorter buffers improve sound… but, there is no explanation of how/why this could be. And, there is not even any wild speculation about how/why this could be. In other words: they do not know!

As they said they followed the philosophy of making it as simple & direct as possible - using shorter/smaller buffers would certainly fit this philosophy approach & not at all random

& Because they do not know, they could not have started to investigate this with a working theory. Without a working theory, they would be just randomly trying different approaches, and then subjectively listening to the results. "hey, what do you know, these shorter buffers sound great, we should do that, cool!"

I am more concerned about high sunspot activity altering the sound of my system than I am about jplay at this point. I am willing to listen to anyone who can give a considered explanation of a plausible theory, of how this software improves sonic performance… so far I, outside of the noise possibility, have not heard a single plausible theory, as to how jplay could improve the sound of the system, just random things like "timing is critical", which we all know is not true in an asynchronous DAC environment.

You have already said that it is not for you, I understand that but using such random excuses to reject it seems rather churlish unless you have demanded the same for all the software players that your tried & heard differences in using

 

[barrows]

John: apparently you do not understand me, I am not sure why? I made measurements of the noise caused by my server, running my preferred software, which is free actually, so I do not expect any measurements, or need them to prove anything to me, never the less, the developers of mpd and the linux distribution it runs on, indeed do explain their approach. They try to make the entire OS and player as small as possible, using as few resources as possible, in order to run on the lowest profile hardware as possible, and, therefore, producing the least noise possible.
I am a little confused about jplay, perhaps you can help. You say the developers attempted to make it as simple as possible. Seems to me it would be more simple to run jriver without jplay at all, right? From people building custom servers, I have learned that most people who choose to run jplay find the need to choose a MoBo with an I-5 or I-7, that does not sound very simple to me? Does jplay really need so much CPU power to run? Not to mention, if simplicity was the desired result, why build a player for the windows environment at all? One simple question: does CPU load drop when playing back a file via jriver/jplay compared to jriver alone?
I had heard mixed reviews from people trying jplay, I have heard just as many people saying it made no difference, as I have saying that it improved sound. I have also heard some people say that they were not sure. When I hear mixed reviews like this, I am curious. I had hoped that through reading this thread I might learn something about how jplay attempts to improve sonic performance. Instead, I read a lot of what sounds like bs from the developer, with absolutely no plausible explanation-to me, this is a red flag. As I said previously, I would respect this product more if the developer had just come out and said that what we do is proprietary, rather than the weird smoke screen of unsubstantiated claims made here.

 

[amirm]

Indeed, I do have an idea of the number of people who think Jplay is well worth purchasing from the sample of my customers who I recommend it to.

I thought you said there was no expectation bias? If you recommended it to them, then you planted a seed there for bias. You told them someone who they trust with audio advice is saying the software does some good. The game was fixed from then on....

 

[jkeny]

John: apparently you do not understand me, I am not sure why? I made measurements of the noise caused by my server, running my preferred software, which is free actually, so I do not expect any measurements, or need them to prove anything to me, never the less, the developers of mpd and the linux distribution it runs on, indeed do explain their approach. They try to make the entire OS and player as small as possible, using as few resources as possible, in order to run on the lowest profile hardware as possible, and, therefore, producing the least noise possible.

Ok, so how is this any different from Jplay's approach - they focus on the KISS principle, it would seem. BTW, I would be interested in seeing your noise measurements - have you published them anywhere?

I am a little confused about jplay, perhaps you can help. You say the developers attempted to make it as simple as possible. Seems to me it would be more simple to run jriver without jplay at all, right? From people building custom servers, I have learned that most people who choose to run jplay find the need to choose a MoBo with an I-5 or I-7, that does not sound very simple to me? Does jplay really need so much CPU power to run? Not to mention, if simplicity was the desired result, why build a player for the windows environment at all? One simple question: does CPU load drop when playing back a file via jriver/jplay compared to jriver alone?

You need to go back & read Jplay's posts here to look for the answers to your questions - some Qs are already covered in those posts, some not. BTW, JPlay can operate in stand alone mode using JPlayMini - it doesn't require Jriver or any front-end software. Many say that it sounds best just using JplayMini.

Audio is a strange animal, isn't it - some like the NOS approach which is simple, others prefer upsampled audio, still others prefer heavily upsampled or even converted to DSD. I'm agnostic about the two ends of this spectrum - the simple NOS approach & the much less simple/direct heavily upsampled approach. Who knows, sometimes we have to use complex underpinnings to achieve the effects of simplicity?

BTW, I agree with the general thrust of your comments - why not dispense with a complex computer platform, altogether & go with something simpler, more directly focused on audio rather than a general purpose computer? It's all a case of trade-offs!

I had heard mixed reviews from people trying jplay, I have heard just as many people saying it made no difference, as I have saying that it improved sound. I have also heard some people say that they were not sure. When I hear mixed reviews like this, I am curious. I had hoped that through reading this thread I might learn something about how jplay attempts to improve sonic performance. Instead, I read a lot of what sounds like bs from the developer, with absolutely no plausible explanation-to me, this is a red flag. As I said previously, I would respect this product more if the developer had just come out and said that what we do is proprietary, rather than the weird smoke screen of unsubstantiated claims made here.

Sure, you have your experience & objections - I have my sampling & personal listening. I don't reject something that I can hear an audible advantage using just because it has no underlying theory to validate what I hear.

If I heard Bybees & they improved the sound, I would chalk it up as just another thing that we don't know the underlying theory of operation. Just because the developer has some vague or unbelievable story about them would not make me deny what I hear.

 

[jkeny]

I thought you said there was no expectation bias? If you recommended it to them, then you planted a seed there for bias. You told them someone who they trust with audio advice is saying the software does some good. The game was fixed from then on....

All choices we make are based on recommendations, research, evaluation of options, evaluation of opinions. To then say that all our choices are flawed because we take advice from someone is ridiculous.

I'm sure you recommend products in Madrona - so all your customers are equally subjected to expectation bias. The simple fact that you carry a small portfolio of products is in itself suggesting to the customer that these are the ones you consider best & therefore you are already setting up expectation bias.

I'm of the opinion that people are adults & have an ability to evaluate products themselves!

One could take the contrary view that they have just spent an amount of money on an audio product & are reluctant to accept that they need to spend more to achieve even better sound. The bias here would be to reject Jplay as not worth the extra, would it not? Unless it delivered value, of course!

 

[barrows]

"Audio is a strange animal, isn't it - some like the NOS approach which is simple, others prefer upsampled audio, still others prefer heavily upsampled or even converted to DSD. I'm agnostic about the two ends of this spectrum - the simple NOS approach & the much less simple/direct heavily upsampled approach. Who knows, sometimes we have to use complex underpinnings to achieve the effects of simplicity?"

All of these different approaches produce measurably different results. They are acting in the analog domain, and it is fairly easy to understand how they could produce different sonic results. This is in no way analogous to the claims made for jplay. This is actually a good example of what I object to, you give an example of things which act in the analog domain, producing easily measurable differences. But in the purely digital domain of the computer, the same cause and effect process does not exist, and it is wrong to impose analog ideas of signal change to a pure data environment. If things actually worked this way, we would send an e-mail, and it could be different on the receiving side, say with letters out of order (OK, this is a very simplistic example, but we should get the concept at least). Really, how ridiculous is this.

Agree on the effect of Bybee devices (I have not tried the music rails). But these are fairly easy to understand as well, despite the fact that Jack Bybee (have you met him, he is quite a character) is very coy about letting on what compounds they are made of. But it is easy to acknowledge that there are many different elements and compounds which can couple with various EM frequencies, and turn some of the energy present into heat, quartz for example. Nothing strange and mysterious about it, it is science. The only debate in my mind as to the relative effectiveness of the Bybee devices is in terms of the magnitude of their effect, and if that effect is worth the cost. OK, totally OT, but I cannot resist. Since Jack will not tell us what to measure to test Bybees objectively, try this test: get two large Bybee purifiers. Wire an AC outlet box with one outlet with a Bybee in series on hot and neutral, wire the other outlet direct to the mains. Now plug your TV monitor alternatively into the two outlets, anyone will see the difference in this test, it is undeniable.

 

[jkeny]

Barrows, in searching for Music Program Daemon & noise measurements, I cam across this paper which you might be interested in https://www.kernel.org/doc/ols/2009/ols2009-pages-159-168.pdf It's about "OS Noise" or "everything not under the control of the application that has a negative impact on performance and latencies"

It seemed to me that if Jplay used this definition & referenced papers then the objections here would be far less or at least different. AFAIK, Jplay has attempted to get more control of the OSes timing aspects in pursuit of better sound. I watched the development of Jplay & form what I gathered they did enough experiments to prove this approach had a beneficial effect on the sound. What they can't say is how this has a beneficial effect or measure it yet.

 

[jkeny]

"Audio is a strange animal, isn't it - some like the NOS approach which is simple, others prefer upsampled audio, still others prefer heavily upsampled or even converted to DSD. I'm agnostic about the two ends of this spectrum - the simple NOS approach & the much less simple/direct heavily upsampled approach. Who knows, sometimes we have to use complex underpinnings to achieve the effects of simplicity?"

All of these different approaches produce measurably different results. They are acting in the analog domain, and it is fairly easy to understand how they could produce different sonic results. This is in no way analogous to the claims made for jplay. This is actually a good example of what I object to, you give an example of things which act in the analog domain, producing easily measurable differences. But in the purely digital domain of the computer, the same cause and effect process does not exist, and it is wrong to impose analog ideas of signal change to a pure data environment. If things actually worked this way, we would send an e-mail, and it could be different on the receiving side, say with letters out of order (OK, this is a very simplistic example, but we should get the concept at least). Really, how ridiculous is this.

I'm not going to get into that digital Vs analogue debate - it is really simplistic & the analogies laughable

Agree on the effect of Bybee devices (I have not tried the music rails). But these are fairly easy to understand as well, despite the fact that Jack Bybee (have you met him, he is quite a character) is very coy about letting on what compounds they are made of. But it is easy to acknowledge that there are many different elements and compounds which can couple with various EM frequencies, and turn some of the energy present into heat, quartz for example. Nothing strange and mysterious about it, it is science. The only debate in my mind as to the relative effectiveness of the Bybee devices is in terms of the magnitude of their effect, and if that effect is worth the cost. OK, totally OT, but I cannot resist. Since Jack will not tell us what to measure to test Bybees objectively, try this test: get two large Bybee purifiers. Wire an AC outlet box with one outlet with a Bybee in series on hot and neutral, wire the other outlet direct to the mains. Now plug your TV monitor alternatively into the two outlets, anyone will see the difference in this test, it is undeniable.

Funny, because there was a whole thread on DIYA about Bybees which very much mirrors this thread. All the usual stuff trotted out about lack of measurements, ambiguous claims, DBTs, etc. SY ( a moderator) set out to measure Bybees & declared them no different to a 0.3c resistor. Interesting test you suggest - pity you didn't say this on DIYA or did I miss it - frankly I got tired of that thread as I'm getting tired of this one?

 

[Phelonious Ponk]

All choices we make are based on recommendations, research, evaluation of options, evaluation of opinions. To then say that all our choices are flawed because we take advice from someone is ridiculous.

I'm sure you recommend products in Madrona - so all your customers are equally subjected to expectation bias. The simple fact that you carry a small portfolio of products is in itself suggesting to the customer that these are the ones you consider best & therefore you are already setting up expectation bias.

I'm of the opinion that people are adults & have an ability to evaluate products themselves!

One could take the contrary view that they have just spent an amount of money on an audio product & are reluctant to accept that they need to spend more to achieve even better sound. The bias here would be to reject Jplay as not worth the extra, would it not? Unless it delivered value, of course!

Correct and correct. Now the only difference between you and every credible, experienced behavioral research professional in the world is that you think this is ridiculous.

Tim

 

[jkeny]

Correct and correct. Now the only difference between you and every credible, experienced behavioral research professional in the world is that you think this is ridiculous.

Tim

And tell me why this doesn't apply "One could take the contrary view that they have just spent an amount of money on an audio product & are reluctant to accept that they need to spend more to achieve even better sound. The bias here would be to reject Jplay as not worth the extra, would it not?"