Couldn't you just use a sound card with digital out and in to record the digital data?

I do not know. It does not test the same path. I do not know if in windows the playback application can check whether the selected output is digital, i.e. if this information is available in the API. If so, the application could change its behaviour. Just like windows audio subsystem disables volume control for SPDIF output etc.

But if the above is not the case, the digital-out path is certainly the way out. It requires a specific hw not everyone can have available.

Couldn't you just use a sound card with digital out and in to record the digital data?

I do not know. It does not test the same path. I do not know if in windows the playback application can check whether the selected output is digital, i.e. if this information is available in the API. If so, the application could change its behaviour. Just like windows audio subsystem disables volume control for SPDIF output etc.

But if the above is not the case, the digital-out path is certainly the way out. It requires a specific hw not everyone can have available.

I have a sound card with S/PDIF in and out. So if I set jplay (and foobar for comparison) to output to S/PDIF out and record from S/PDIF in with another application using a loopback cable, can the result be helpful? I am asking because I do not have much time and I have reservations about installing jplay on my system. So I am willing to make the sacrifice ;-) only if you guys confirm it's worth doing.

Yes, most likely you will get relevant results, unless jplay detects the spdif output which I doubt. I used such setup for bit-perfection tests of the card driver in linux.

First you need to establish and verify a bitperfect recording loopback. I always used audacity, switched to 24 bit internal sample and turned off dither. Recording digital input was always bitperfect on linux. However on windows you need a reliable bitperfect recording route, i.e. asio. There should be audacity compiled with asio support somewhere available, though not officially due to asio licensing limitations. Also sample alignment and subtraction of the original and recorded tracks was easy in audacity. I checked zero contents of the subtracted (i.e. difference) wav in sox (command sox diff.wav -n stats must show zeros only). Sole looking at straight line in audacity is not sufficient, IMO.

Once you can playback (e.g. from foobar) and record bit-perfectly, you can record jplay output and do the analysis.

Good luck, your work will be appreciated a lot among people here and elsewhere.

It may have to wait until Monday (or maybe someone will be able to do it in the meantime). I attempted playing a test file via foobar while recording it into Adobe Audition 3.0 via S/PDIF, and I can't get it to work. Either my soundcard (M-Audio Fast Track Pro) does not allow simultaneous S/PDIF in/out, or the driver does not allow to be accessed by one program for recording and by another for playback. I tried DS and ASIO in different combinations. I'll keep trying a bit more before I give up until Monday.

I thought I would re-activate my mobo soundcard and use it as a source while recording into the M-Audio, but mobo has optical S/PDIF and M-Audio has coaxial. Other machines at home either have no S/PDIF or have optical, or there are other reasons why they cannot be used.

On Monday when I am at work I should be able to set up my M-Audio Fast Track Pro on a computer that has M-Audio Audiophile 192, so I would have two separate cards each with coaxial S/PDIF.

I also have Tascam DR100mkII portable recorder, but again it's at work. More importantly, it's S/PDIF input is not bit perfect, which is an interesting story by itself.

I hope it goes without saying that tests conducted without complete level-matching are worthless. I appreciate people’s efforts to achieve this and re-do the original test in a valid way. I suspect most of us know what the conclusion will be.

It does, it seems that I made a bit-perfect recording within Audition via S/PDIF loopback using ASIO driver. But probably ASIO cannot be accessed by two programs at the same time. I can't get Audition to record using a non-ASIO method (which is Audition's own pseudo-ASIO driver "Audition 3.0 Windows Sound", I suspect their own version of ASIO4All). Any suggestions appreciated.

At the suggestion of members on another forum, I ran my own tests on Jplay a while ago to check for bit-perfectness. Along the way, I discovered that 'bit-perfect' recording is really bloody hard. I started off with Foobar2000, reasoning that if I could achieve a perfect null with Foobar's output and the source file I would know that my test was working properly. I discovered several things:

1) Random volume mismatches everywhere because sound card drivers are silly as far as recording is concerned.2) The "What U Hear" option on my sound card inexplicably inverts the phase of what it's recording, as well as doing all kinds of resampling silliness.3) Audacity has severe issues as far as being bit-perfect is concerned.4) Jplay is a horribly designed piece of shit.

I eventually resolved these issues via the usage of the "Virtual Audio Cable" program, which creates a virtual audio interface to which applications (such as Foobar or Jplay) will output. As such, I can see the data that's reaching my sound card drivers when I use Jplay or any other player. VAC then diverted its output via some driver jiggery-pokery to the digital input of my sound card, set up to receive the appropriate sample rate, and set to record. I then had two files I could perform null tests with.

Now, when I tested Jplay I found it, like Foobar, to be bit-perfect (digital silence obtained under null testing with the original material). This was using Jplay's "Kernel Streaming" and its most advanced 'audio engine' - the stuff the designer recommends for the 'best' sound. I thus cannot exclude the possibility that some bizarre combination of settings/inputs of varying sample rates will cause Jplay to perform equalisation or something similar, but I think it unlikely. It would suggest a level of effort and competence on the part of the designer that he has so far failed to demonstrate in either his interactions with this forum or his software design.

If people are really eager, I could set up the tests again, but I'd rather not - Jplay is awkward to work with and the whole process of setting things up so that if things are bit-perfect they will show as bit-perfect (no resampling anywhere in the chain) is quite annoying.

I have a Creative X-Fi soundcard and a Roland SC-D70 USB audio interface connected by an optical SPDIF cable. What I did in the video was:

1. Generate a test signal using RMAA.2. Use SC-D70 to play the signal with foobar2000 while record the signal with X-Fi using RMAA.3. Use RMAA to compare the original and the recorded signal.4. Use Adobe Audition to align the original and the recorded signal, then invert one of the two files and mix them to show that they are identical.5. Use SC-D70 to play a music file while record the music with X-Fi using RMAA. Please note that I only use RMAA as a recorder to show the playback/record procedure is same as step 2, I am not going to analyze the music with RMAA because RMAA cannot do that.6. Same as step 4, after invert and mixdown, Audition showed that the recorded music is same as original because the statistics showed -inf dB in all fields.

I can't do the same test on jplay because jplay keeps saying that cannot connect to [some IP address] and I can't play anything with jplay. But at least my test showed that foobar2000 can playback music without any modification to the original file. Therefore... you see what I mean...

I've compared the spectra of both of sabrehagen's samples, and the jplay sample has a significant frowny curve EQ applied to it, in addition to being about 4dB quieter in the midrange.

I retract my earlier statement about stereo separation. I can't decide one way or another. The difference is probably caused by the EQ on the channels.

I don't know if this truly is what sabrehagen is listening to by default (which is why I keep caling it "the jplay sample", rather than "jplay output"), but it's different, and it's certainly not better quality.

Thanks for the report, dhromed. The same applies to all other users who are analysing this.

QUOTE (bennetng @ Mar 29 2013, 18:34)

I can't do the same test on jplay because jplay keeps saying that cannot connect to [some IP address] and I can't play anything with jplay.

Heh. More unsportsmanlike behaviour by Jplay? I thought it likes to market itself as being so unobtrusive – side-note: to things that almost certainly will not impact audio at all – that it even has a ‘hibernate mode’. So, why would it be trying to connect to the internet? Oh wait, >looking for logic in a product like this

1) I think too much trouble is going into coming up with bullet-proof arguments and if I didn't trust the members involved, I'd suspect concern trolling.

2) If sabrehagen were to playback his samples in foobar2000 and agree that each matches his expectations based on his double-blind testing then we don't need to be so cautious in distinguishing a "jplay sample" from "jplay output".

Yet another unsportsmanlike behaviour or the developers of JPlay can't understand elementary English? I speak Cantonese and I only got mediocre results in my English exams, but I still understand the meaning of TOS8.

Thanks for the input everyone is providing. You are all putting in some serious thought and work on this project.

QUOTE (bennetng @ Mar 30 2013, 04:34)

I can't do the same test on jplay because jplay keeps saying that cannot connect to [some IP address] and I can't play anything with jplay. But at least my test showed that foobar2000 can playback music without any modification to the original file. Therefore... you see what I mean...

That issue should be easily fixed. They have a client-server option. Under Audio PC in the settings dialogue to you have This Computer or Search My LAN For PC selected? These seem like some of the most conclusive tests so far, and the best setup, so it would be very valuable to us I believe if you persist with trying to get JPLAY to work so some comparisons can be done!

Thanks for providing the samples sabrehagen!I listened both samples and i really wonder how anybody can think this huge difference can only come from some magic software acting and NOT altering the bits just making the bits more fluid.At least now i understand when some audiophiles hear huge differences when using "tuning" software

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 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.

It does, it seems that I made a bit-perfect recording within Audition via S/PDIF loopback using ASIO driver. But probably ASIO cannot be accessed by two programs at the same time. I can't get Audition to record using a non-ASIO method (which is Audition's own pseudo-ASIO driver "Audition 3.0 Windows Sound", I suspect their own version of ASIO4All). Any suggestions appreciated.

ASIO/KS/WASAPI etc are not absolutely necessary for bit-perfect transfer. Basic MME can get the job done as well, but you need to pay attention to the following (assuming you are using Windows7)

1. The test signal should not be very close to 0dBFS because Windows will automatically limit the volume to prevent clipping, resulting a non bit-perfect stream.

2. Always use 24-bit in your recording software because Windows will add dither in your recording if you are using 16-bit.

3. In Windows' audio playback and recording properties, make sure the sample rate is correctly configured and always use 24-bit to prevent dithering and resampling.

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.