Suggesting a new fb2k slogan:

Ensuring zero sound improvement at zero cost
(both quantities user-tweakable, unidirectionally, to opposite signs)

VLC is highly configurable. Most likely your setup involved some DSP. Check the advanced config, there are lots of options.

But I didn't have anything checked/enabled but audio itself (the first option).


A quick check of JPlay trial version showed that it passed an impulse and pink noise unaltered.

You have difficulties in accessing two or more ASIO applications is because your audio interface does not support multiclient ASIO. In order to support multiclient ASIO your audio interface need to have a hardware DSP mixer. As far as I know, interfaces including Creative/EMU kx-based soundcards and some models of X-Fi soundcards, RME HDSP series and interfaces from Echo support multiclient ASIO. USB interfaces usually have no multiclient ASIO support, including my Roland SC-D70.

Technically there is no mixing involved in accessing playback and capture streams with different applications as long as there is just one each. I am surprised asio would not allow such common scenario.

Google "multiclient asio" will get some software-based multiclient asio driver discussions, but I don't know if they work or not.
Another alternative to do the recording test is REAPER, it is a frequently updated DAW supporting DS/MME/KS/WASAPI/ASIO and its trial version is fully functional.
http://reaper.fm

This topic is hotter than when WMA gets brought up, definitely been interesting reading for a $99 piece of software that does nothing but mess with processor scheduling, which windows has already gotten pretty good at. $75 just bought me a used pair of paradigm atoms which has far more benefit to sound than this drivel.

This topic is hotter than when WMA gets brought up, definitely been interesting reading for a $99 piece of software that does nothing but mess with processor scheduling, which windows has already gotten pretty good at. $75 just bought me a used pair of paradigm atoms which has far more benefit to sound than this drivel.

Well I'm surprised it took 8 pages of JPLAY bashing before somebody actually decided to run some scientific tests, when this is supposedly a scientific audio forum. Nonetheless, it was somebody from the JPLAY camp. Says a lot for attitudes around here.

And look what the results were. People can be forgiven for not rushing to disprove wild claims when, as usual – and apparently this has to be stated over and over again – it’s the responsibility of the claimant to provide valid evidence, not the audience to disprove claims (with the convenient corollary that they should be assumed true in the absence of said disproof). In this case, such evidence must be produced by double-blind tests that are fully controlled for all possible confounding factors. That still hasn’t happened. Your test was found to have been invalidated by changes to the signal caused by VLC for some reason. Prior tests have shown either complete bit-identity or difference signals so far below the noise floor as to be completely insignificant (and probably easily remedied if it were to matter).

So, what is your point, other than an attempt to take the moral high ground despite not having anything concrete to stand on? …something that, as I already noted, does seem to be a particularly common meme among advocates for Jplay and other such products.

Haha I'm still lost on what jplay actually DOES do... The proprietor claimed earlier on that it does not affect bitstream, only affects processor caching and other such nonsense. I can do that within windows task manager for free.

VLC definitely does alter the sound. I tried 44.1, 48 kHz, 16 to 32 bit WAVs containing a single impulse and VLC always outputs something that looks like the result of resampling (HF roll-off) or some other kind of processing including upsampling.

VLC is highly configurable. Most likely your setup involved some DSP. Check the advanced config, there are lots of options.

I can't get VLC to output bit-perfect stream no matter what I set, I've turned off everything already (EQ, compressor, spatializer, replaygain, time stretching, normalize, dolby surround)

RMAA result:

http://www.flickr.com/photos/82931408@N02/...in/photostream/

Tools -> Messages; set Verbosity to 2(debug). You'll see something like:

Code: [Select]

main debug: filter(s) 'f32l'->'f32l' 52800 Hz->48000 Hz Mono->Mono

or:

Code: [Select]

main debug: filter(s) 'f32l'->'f32l' 48510 Hz->44100 Hz Mono->Mono

It seems that the reason for this is: http://forum.videolan.org/viewtopic.php?f=13&t=25114

the filter you see is to correct the tempo in case realtime vs. arriving time starts to get skewed.

Thanks lvqcl, I can see similar messages as well.

Make a 30 second sample of a song that you like, which shows the differences. Play it first in foobar2000, and record the output (if your soundcard has both a line-out and a line-in, simply use a male-male cable and connect the line-out to the line-in). Play it again with jplay, and record the output. Post the two recordings in the uploads forum. Someone competent can then sample align the recordings and volume match them, and then compare them.

I have done exactly this and the two outputs to not match, there is significant difference. I used Audio DiffMaker to do the test. I have also posted in the uploads section: http://www.hydrogenaudio.org/forums/index....howtopic=100156

This is a sound output. Now how do I test the bitstream?

Obvious level mismatch:

Jplayer statistics:

   Left   Right
Min Sample Value:   -8468   -7478
Max Sample Value:   7747   8107
Peak Amplitude:   -11.75 dB   -12.13 dB
Possibly Clipped:   0   0
DC Offset:   0    0
Minimum RMS Power:   -84.24 dB   -88.94 dB
Maximum RMS Power:   -21.02 dB   -21.38 dB
Average RMS Power:   -29.42 dB   -30.17 dB
Total RMS Power:   -28.42 dB   -29.14 dB
Actual Bit Depth:   16 Bits   16 Bits

Using RMS Window of 50 ms


Foobar statistics:

   Left   Right
Min Sample Value:   -12652   -14834
Max Sample Value:   13255   15442
Peak Amplitude:   -7.86 dB   -6.53 dB
Possibly Clipped:   0   0
DC Offset:   0    0
Minimum RMS Power:   -85.54 dB   -88.7 dB
Maximum RMS Power:   -15.74 dB   -14.48 dB
Average RMS Power:   -26.31 dB   -26.18 dB
Total RMS Power:   -24.75 dB   -24.5 dB
Actual Bit Depth:   16 Bits   16 Bits

Using RMS Window of 50 ms

Excuse my ignorance, but is this difference in volume contributing to the large difference in the A-B file that DiffMaker outputs? That is, if they were closer to the same volume, would the difference be less, or does the amplitude of a waveform not affect this?

Crap; and all this time I thought the comparison was between VLC and Jplay. Oh well.  I of there is a problem getting unadulterated playback from fb2k then you've come to the right place.

Do we still need a sample of the original or has this been deemed unnecessary?

I see you added it. Thanks.

I see you added it. Thanks.

Just added it then for your own testing purposes: http://www.hydrogenaudio.org/forums/index....mp;#entry829528

Excuse my ignorance, but is this difference in volume contributing to the large difference in the A-B file that DiffMaker outputs?

Yes.

That is, if they were closer to the same volume, would the difference be less, or does the amplitude of a waveform not affect this?

A difference in amplitude is a difference, and one this large swamps out possible more subtle differences.

It is generally easy to control amplitude, and amplitudes should be generally matched within 0.1 dB or less in any listening test or application of analysis software.

Excuse my ignorance, but is this difference in volume contributing to the large difference in the A-B file that DiffMaker outputs?

Yes.

That is, if they were closer to the same volume, would the difference be less, or does the amplitude of a waveform not affect this?

A difference in amplitude is a difference, and one this large swamps out possible more subtle differences.

It is generally easy to control amplitude, and amplitudes should be generally matched within 0.1 dB or less in any listening test or application of analysis software.

I'd really like to make some more accurate tests, but don't have the skills to do so. Can I put a call out to some people on the forum who are experienced in this area to run a quick test with the volume levels of the tracks matched?

VLC is highly configurable. Most likely your setup involved some DSP. Check the advanced config, there are lots of options.

But I didn't have anything checked/enabled but audio itself (the first option).


A quick check of JPlay trial version showed that it passed an impulse and pink noise unaltered.

The impulse and pink noise tests sound very interesting. Can you please post some results?

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?

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?

I can answer two thirds of your questions.

1. Yes it sounds different.
2. I don't know, my tests seem inaccurate due to my inexperience. I have requested others (who appear to have done their own tests) to post their findings. There is a contradiction in this whole idea though. If the bits are the same, it shouldn't sound any different. JPlay claims to sound better. I can hear it sounds different. Personally it's better, because I can hear things I've never heard, or can't hear with other players, but that is a subjective matter. Therefore, measuring the sound coming out of the sound card will show a different result, but the bits going in is where the real test needs to be done. I don't know how it's meant to be different. Maybe more accurate timing? I don't know; it's all a black box.
3. One, not the other.

You need to perform the tests yourself. For example, I proved that foobar2000 and MPC-HC can output bit-perfect audio, but it is only true on my environment (OS, driver, hardware, configuration etc), it doesn't mean the same will apply to everyone automatically.

Maybe in your environment, JPlay really sounds better, but according to Hydrogenaudio's rule, you need to provide valid test samples and DBT results. I don't know if your playback/recording equipments are good enough for doing such tests or not but in my opinion, if you are willing to pay 99 EUR for JPlay, buying a 99 EUR audio interface with decent analog quality and bit-perfect digital I/O should not be a problem for you.

I wonder also what we talk about here now.
We know that the recorded samples "3 copy.wav" and "4 copy.wav" when level-matched still sound completely different!
These huge differences between these 2 samples you provided can only be caused by hefty processing -> Something on your playback does alter the sound when played back with VLC to a not small degree.
Please try to get your playback right first before making any more speculations. Others already provided some hints how to get it right.

I installed Jplay with an intention of testing it thoroughly, including recording the output via both S/PDIF and analog, and comparing to other players.

Here are some initial observations:

- the installer required computer restart, pretty unusual for a medi aplayer
- the antivirus had some doubts about the program
- the computer is no longer accessible via remote desktop
- there are signs of heavy processor load (for example, foobar visualisations became choppy when played over JPLAY) which are hidden from the Task Manager (I'll download Process Explorer onto this machine later)'

I think these are pretty worrying signs and I am leaning towards getting this software off my machine instead of doing any serious testing.

I'd add one:
- foobar2000's playback time display become inaccurate and the seekbar moves jittery.

- there are signs of heavy processor load (for example, foobar visualisations became choppy when played over JPLAY) which are hidden from the Task Manager (I'll download Process Explorer onto this machine later)

Nothing specific shows up in the Process Explorer, so maybe it's not processor load but yet another symptom (in addition to those described by bennetng) of messing up with foobar.