IPB

Welcome Guest ( Log In | Register )

19 Pages V  « < 13 14 15 16 17 > »   
Reply to this topicStart new topic
Jplay - just another scam? YES IT IS!
icstm
post May 2 2013, 11:24
Post #351





Group: Members
Posts: 121
Joined: 25-January 12
Member No.: 96698



QUOTE (db1989 @ Mar 29 2013, 16:32) *
I hope it goes without saying that tests conducted without complete level-matching are worthless.

What does this mean?
Why are levels changing on a bitperfect stream, unless the two playback engines being used to play the same source are chaing the stream?

Also why did ABK resurect an old thread, I think this discussion had run its course?
Are there new arguments here that were not last year?

Go to the top of the page
+Quote Post
db1989
post May 2 2013, 11:30
Post #352





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (icstm @ May 2 2013, 11:24) *
QUOTE (db1989 @ Mar 29 2013, 16:32) *
I hope it goes without saying that tests conducted without complete level-matching are worthless.
What does this mean?
Exactly what it says.

QUOTE
Why are levels changing on a bitperfect stream, unless the two playback engines being used to play the same source are chaing the stream?
Why indeed. The reason for these differences was never conclusively determined, other than potentially being caused by DirectSound. In any case, the fact that there were differences at all invalidated the tests. But speaking of the tests…

QUOTE
Also why did ABK resurect an old thread, I think this discussion had run its course?
Are there new arguments here that were not last year?
He does that sometimes. Anyway, that wasn’t what led to the most recent flurry of (unproductive) activity. Did you miss the fact that the previous 8 pages or so are about tests performed by sabrehagen? No, there are no new arguments or any points in favour of JPLAY, predictably. But if you want to know what has been happening in the thread, I can only suggest that you actually read it.
Go to the top of the page
+Quote Post
icstm
post May 2 2013, 11:32
Post #353





Group: Members
Posts: 121
Joined: 25-January 12
Member No.: 96698



QUOTE (pdq @ Apr 1 2013, 14:15) *
I am totally confused as to what we have/have not established here. I believe the questions that need to be answered are:

Does JPlay sound different?

Does JPlay alter the bits going to the sound card?

Has either of these been answered?


Now I am confused, I thought last year we were clear that JPlay could not really do (1) without doing (2), even though it might claim otherwise.
Go to the top of the page
+Quote Post
icstm
post May 2 2013, 12:01
Post #354





Group: Members
Posts: 121
Joined: 25-January 12
Member No.: 96698



QUOTE (sabrehagen @ Apr 4 2013, 10:49) *
QUOTE (bennetng @ Apr 4 2013, 19:22) *
For my personal needs:

1. I need native 44k sample rate support
2. I need multiclient ASIO support
3. My soundcard's analog output is louder (to drive my earphone)
4. I need optical and coaxial digital input


I see no mention of digital output sound quality here!

Not sure what you mean by the quality of the digital output, but your Realtek 892 supports 44k or 48k&96k. So standard 16b/44k CD sound is supported bitperfect.

You probably wont have all those digital inputs though.
Go to the top of the page
+Quote Post
db1989
post May 2 2013, 12:05
Post #355





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (icstm @ May 2 2013, 11:24) *
Also why did ABK resurect an old thread, I think this discussion had run its course?
These questions take on a new irony now that you’re replying to scattered posts from a now-dead discussion.
Go to the top of the page
+Quote Post
icstm
post May 2 2013, 12:07
Post #356





Group: Members
Posts: 121
Joined: 25-January 12
Member No.: 96698



@db1989
I did read all the pages.
It was this thread that first drew me to sign up to this site.

So how in general should I perform level matching on two different source files for ABX testing?
Go to the top of the page
+Quote Post
Sirlordcomic
post May 25 2013, 20:26
Post #357





Group: Members
Posts: 1
Joined: 25-May 13
Member No.: 108327



I apologize if this was posted, but I read most of the entire thread; a well done test on JPLAY was done by Mitch at CA. I hope it is ok to post the link. Fascinating thread.

comparing JPLAY & JRIVER
Go to the top of the page
+Quote Post
greynol
post May 25 2013, 21:05
Post #358





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE
I find there is a direct correlation between what I hear and what I measure and vice versa.

Without accusing the well of being poisoned, this particular "finding" (specifically the part about direct correlation) is, how should I put it, bullshit.

In the event that you aren't aware, evidence of a difference in a signal is not evidence of audibility, regardless of the size of that difference.

This post has been edited by greynol: May 25 2013, 21:30


--------------------
Concern trolls: not a myth.
Go to the top of the page
+Quote Post
db1989
post May 25 2013, 22:52
Post #359





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



I agree, and to pile on. . .

QUOTE
As an aside, [Audio DiffMaker, which offers for display or listening the difference of two input streams,] can be used to objectively evaluate anything in your audio playback that you have changed. Whether that be a SSD, power supply, DAC, interconnects, and of course music players
Objective, eh? In the sense of providing empirical data, maybe, but useless in terms of predicting the perceptual results. This pointlessness applies both to comparisons such as the one cited, wherein one would expect differences to be nonexistent or negligible, and to comparisons involving lossy codecs, for reasons that I hope I need not restate in the latter case.

QUOTE
I find there is a direct correlation between what I hear and what I measure and vice versa. I want a balanced view between subjective and objective test results.
What a coincidence! Subjective results only become meaningful when confirmed by objective results. Thus, talk of a balance strikes me as being nonsensical. I do not believe Hydrogenaudio would advocate people wasting their time trying to find any such balance.

I post this to emphasise these corollaries of TOS #8 in case anyone did not already derive them implicitly from its wording. You can measure things all day, and the measurements might be useful from an engineering perspective, but double-blind listening tests are the only way to make them meaningful in audible terms.

The fact that this article managed to arrive at the correct (and surely obvious) conclusion and included some semblance of objective testing does not retroactively validate its methods and justifications. I am pretty sure it was posted not long ago, and after making some brief comments akin to the above, I think I was told that significant portions of the readership of Computer Audiophile need such doses of reality (Jriver vs. JPLAY, FLAC vs. WAV by the same tester, etc.) regardless of how they are provided. While there might be some validity to that, and such tests probably serve a useful purpose for some readers, I find it hard to applaud very much when they perpetuate hindering myths about how things should be tested. Myths that are not quite as bad as other myths are still myths!
Go to the top of the page
+Quote Post
Wombat
post May 26 2013, 00:08
Post #360





Group: Members
Posts: 1011
Joined: 7-October 01
Member No.: 235



On a place where USB cables need burn-in time and good sound can only come from 5.6MHz dsd pecause it does not ring i find it very courageous by mitchco to offer numbers that should show the members over there things simply can´t be that way.
You can´t compare it with our vault here. Reasoning must be different there.
I sometimes read on CA and besides many absurd reasoning and listening reports there is also interesting stuff.
Go to the top of the page
+Quote Post
db1989
post May 26 2013, 00:54
Post #361





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



Good points. My post has, predictably, a heavy bias to how things are done here. While that is all well and good for us, I did not mean to imply that mitchco was not doing something positive in offering some sanity to people elsewhere.

I would like to take this opportunity to separate that possible benefit from my criticisms of the methods or discussion. Although a lot of the methods are naïve and oversimplified, I suppose that is appropriate when dealing with misconceptions of a similar nature! In that respect, yes, mitchco is doing a good thing to try to debunk common myths of audiophoolery. If his articles help to divest people of incorrect ideas about comparative quality, then of course that is good.

Many of my criticisms centred not on the simplistic measurements used but rather on the allegations that they are intrinsically correlated with audibility. I feel that such articles run the risk of debunking one big myth while simultaneously instilling smaller ones. Simple metrics need not be reflective of perception at all. False generalisations that measurement predicts (sighted) perception seem to be counterproductive to the overall conclusions. But small steps in the right direction, and all that. smile.gif
Go to the top of the page
+Quote Post
mitchco
post May 26 2013, 01:27
Post #362





Group: Members
Posts: 8
Joined: 19-March 13
Member No.: 107291



QUOTE (db1989 @ May 25 2013, 16:54) *
Good points. My post has, predictably, a heavy bias to how things are done here. While that is all well and good for us, I did not mean to imply that mitchco was not doing something positive in offering some sanity to people elsewhere.

I would like to take this opportunity to separate that possible benefit from my criticisms of the methods or discussion. Although a lot of the methods are naïve and oversimplified, I suppose that is appropriate when dealing with misconceptions of a similar nature! In that respect, yes, mitchco is doing a good thing to try to debunk common myths of audiophoolery. If his articles help to divest people of incorrect ideas about comparative quality, then of course that is good.

Many of my criticisms centred not on the simplistic measurements used but rather on the allegations that they are intrinsically correlated with audibility. I feel that such articles run the risk of debunking one big myth while simultaneously instilling smaller ones. Simple metrics need not be reflective of perception at all. False generalisations that measurement predicts (sighted) perception seem to be counterproductive to the overall conclusions. But small steps in the right direction, and all that. smile.gif


Mitchco here. Just to point out that in each of the measurement posts referenced above also included ABX listening tests...

If my methods are naïve and oversimplified, and my conclusions with respect to correlating to audibility are incorrect, please correct me. I would like to genuinely learn how I can improve my test methods and understanding. For example, how can I improve on this? http://www.computeraudiophile.com/content/...bility-testing/

Thanks
Go to the top of the page
+Quote Post
db1989
post May 26 2013, 03:38
Post #363





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



I apologise: I think my wording has been imprecise and too harsh in some cases. As I hope was clear, I do appreciate your efforts and the general intention behind these tests. smile.gif

My criticisms were not intended to be general or to devalue your overall conclusions, although I can see how they could be interpreted that way. I started out commenting on just a few particular methods and their relevance, or lack thereof, to psychoacoustics, e.g. difference signals; and to what I interpreted as statements that objective measurements such as these correlate with subjective listening tests, which I took to mean non-double-blind tests. I did see that you had performed ABX tests but was not sure whether that was a universal feature.

Perhaps I have not paid sufficient attention to your articles in my glance through them, and I may have incorrectly extrapolated from what I have seen, so I apologise if I have said anything incorrect/misleading. I would be happy to have a more detailed read through and offer my feedback when I have more time, although I freely admit that I am by far from the most qualified of our members to do so! Certainly you have infinitely more in-the-field experience than me as described in your articles. And, again, I appreciate your using your time to document things like this.
Go to the top of the page
+Quote Post
bennetng
post May 26 2013, 06:57
Post #364





Group: Members
Posts: 224
Joined: 22-December 05
Member No.: 26587



I just read the JRiver vs JPlay and FLAC vs WAV articles.
These 2 articles suggested that they produced -90dB differences in null tests (Audio Diffmaker).

But analog audio will never be identical, I mean, there will be differences even when I compare FLAC vs FLAC being played in foobar vs foobar, and my findings is that differences in WAV vs FLAC vs Wavpack is not bigger than WAV vs WAV and FLAC vs FLAC and Wavpack vs Wavpack, and differences in foobar vs MPC-HC is not bigger than foobar vs foobar and MPC-HC vs MPC-HC and WASAPI vs...(insert other players/formats/APIs here), when everything are correctly configured, of course.

Null tests will only be perfect (-inf dB) in digital streams like SPDIF.

I think mitchco know this already, I just post this to inform other readers.

There are measurable differences in a busy PC vs idle PC though
http://www.hydrogenaudio.org/forums/index....howtopic=100481
Go to the top of the page
+Quote Post
mitchco
post May 26 2013, 07:09
Post #365





Group: Members
Posts: 8
Joined: 19-March 13
Member No.: 107291



db1989, no harm, no foul. If I make or have made any technical mistakes in my articles, I hope folks correct me.
The JRiver vs JPlAY article Sirlordcomic referenced, I wrote in Feb 2012. Recently, I added test results in this thread
Go to the top of the page
+Quote Post
Porcus
post May 26 2013, 09:56
Post #366





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (bennetng @ May 26 2013, 07:57) *
Null tests will only be perfect (-inf dB) in digital streams like SPDIF.


And only if you pick them up digitally from the output. If you read SPDIF off a coax cable, the signal is an “analogue” sequence of bits that attempt to shout “one!” “zero!” so clearly that the “analogueness” should be perfectly filtered away. That won't stop people from reading off measurements and compare differences-in-differences A-minus-reference vs B-minus-reference without any clue of whether the order of magnitude of “analogue” noise is remotely close to getting bits wrong.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
krabapple
post May 26 2013, 16:04
Post #367





Group: Members
Posts: 2220
Joined: 18-December 03
Member No.: 10538



QUOTE (mitchco @ May 25 2013, 20:27) *
If my methods are naïve and oversimplified, and my conclusions with respect to correlating to audibility are incorrect, please correct me. I would like to genuinely learn how I can improve my test methods and understanding. For example, how can I improve on this? http://www.computeraudiophile.com/content/...bility-testing/

Thanks



I admire your curiosity, but looks a bit like the wheel was reinvented...you verified that amplitude difference <0.2dB is inaudible, as is conversion from 16bit or 24 bit to 12bit or above. Both of these limits were known from previous psychoacoustics/hearing research.

But if your investigations tamp down some of the crazier claims on CA, all to the good.

This post has been edited by krabapple: May 26 2013, 16:05
Go to the top of the page
+Quote Post
uart
post May 28 2013, 16:52
Post #368





Group: Members
Posts: 810
Joined: 23-November 04
Member No.: 18295



I'm not sure if this has already been mentioned, but Foobar2000 has the option to buffer full tracks to memory anyway (under advanced options you can set the maximum size limit).

I know Jplay touts the ability to buffer entire play lists, but that's a total waste of memory for my purposes. With Foobar buffering enabled I only get a half second burst of disc activity (which is very quiet anyway on my PC) between tracks, and then HDD is completely silent throughout the track. I'm pretty sure I can live with this. smile.gif

This post has been edited by uart: May 28 2013, 16:52
Go to the top of the page
+Quote Post
Porcus
post May 28 2013, 21:41
Post #369





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (uart @ May 28 2013, 17:52) *
Foobar2000 has the option to buffer full tracks to memory anyway


And then there's http://www.foobar2000.org/components/view/foo_ramdisk ...


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
phofman
post May 29 2013, 08:08
Post #370





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



How can a software at ASIO driver layer buffer full track to memory? At driver level it only receives chunks of decoded PCM, right? Perhaps it advertises its ASIO buffer to be long several minutes. But I doubt that since it could clog a playback application easily - maximum real sound device DMA/playback buffer is at max a few seconds, mostly up to one second.
Go to the top of the page
+Quote Post
[JAZ]
post May 29 2013, 20:10
Post #371





Group: Members
Posts: 1772
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



@phofman: When a software buffers something in memory, it means that it reads from whatever input source it might be (hard drive, USB, HTTP location,...) and keeps it in RAM to work with it.

It has nothing to do with the communication with the output device (in this case, a soundcard via ASIO).
Go to the top of the page
+Quote Post
phofman
post May 29 2013, 20:52
Post #372





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



QUOTE ([JAZ] @ May 29 2013, 21:10) *

@phofman: When a software buffers something in memory, it means that it reads from whatever input source it might be (hard drive, USB, HTTP location,...) and keeps it in RAM to work with it.



Yes but if such software emulates an ASIO driver, it receives data via ASIO calls. Each call provides data for one half of the ASIO buffer (ASIO has fixed ratio of 2 periods per buffer). Such software cannot influence the way the upper layer (JRiver) generates the samples to be handed over to its ASIO driver (emulated by JPlay).

Perhaps the RAM playback feature is available for some other modes where Jplay is closer to the actual source files. No idea smile.gif
Go to the top of the page
+Quote Post
Propheticus
post May 29 2013, 22:57
Post #373





Group: Members
Posts: 219
Joined: 10-September 11
Member No.: 93615



You're talking about the output buffer between application and driver level. A ramdisk buffers the input. It behaves as if it's the HDD that is being read from...while in fact it's a much faster accessible part of the ram memory. Reading a file into the ramdisk supposedly allows the disk to spin down after filling the buffer and limit the interference read actions during playback (again supposedly) could cause.

I think this is only useful in machines where the (audio card's) power supply is so dirty that the HDD's read actions are audible. Actual spinning down of harddisks in an average consumer pc running the typical array of (background) apps will not happen often. You'd need a dedicated music pc stripped from all unnecessary programs and services. An untweaked Windows installation tends to autodefrag disks, update the search index, update performance index, etc. during idle moments...Playing music is such a low load, it might as well be called idling.
Go to the top of the page
+Quote Post
phofman
post May 30 2013, 05:36
Post #374





Group: Members
Posts: 300
Joined: 14-February 12
Member No.: 97162



QUOTE (Propheticus @ May 29 2013, 23:57) *
You're talking about the output buffer between application and driver level. A ramdisk buffers the input.


Yes, exactly. If jplay is interfacing at asio API (i.e. application and driver level), it logically cannot provide RAM playback. Yet it was mentioned here, so I wonder how come

QUOTE (Propheticus @ May 29 2013, 23:57) *
Playing music is such a low load, it might as well be called idling.


You know that, I know that. Apparently there are people who believe the opposite, e.g. http://www.audioasylum.com/forums/pcaudio/.../12/124087.html smile.gif
Go to the top of the page
+Quote Post
Propheticus
post May 30 2013, 12:16
Post #375





Group: Members
Posts: 219
Joined: 10-September 11
Member No.: 93615



It could do both, use a built in ramdisk to buffer raw read input AND buffer the decoded stream to the normal output path (ASIO) like any other ASIO capable player does.
Go to the top of the page
+Quote Post

19 Pages V  « < 13 14 15 16 17 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd August 2014 - 21:03