I hope it goes without saying that tests conducted without complete level-matching are worthless.
Quote from: db1989 on 29 March, 2013, 11:32:31 AMI 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?
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?
Quote from: bennetng on 04 April, 2013, 05:22:36 AMFor my personal needs:1. I need native 44k sample rate support2. I need multiclient ASIO support3. My soundcard's analog output is louder (to drive my earphone)4. I need optical and coaxial digital inputI see no mention of digital output sound quality here!
For my personal needs:1. I need native 44k sample rate support2. I need multiclient ASIO support3. My soundcard's analog output is louder (to drive my earphone)4. I need optical and coaxial digital input
Also why did ABK resurect an old thread, I think this discussion had run its course?
I find there is a direct correlation between what I hear and what I measure and vice versa.
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
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.
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.
Null tests will only be perfect (-inf dB) in digital streams like SPDIF.
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
Foobar2000 has the option to buffer full tracks to memory anyway
@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.
You're talking about the output buffer between application and driver level. A ramdisk buffers the input.
Playing music is such a low load, it might as well be called idling.