Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Jplay - just another scam? YES IT IS! (Read 303958 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Jplay - just another scam? YES IT IS!

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

Jplay - just another scam? YES IT IS!

Reply #201
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.

Jplay - just another scam? YES IT IS!

Reply #202
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.
Ceterum censeo, there should be an "%is_stop_after_current%".

Jplay - just another scam? YES IT IS!

Reply #203
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.

Jplay - just another scam? YES IT IS!

Reply #204
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.
Ceterum censeo, there should be an "%is_stop_after_current%".

Jplay - just another scam? YES IT IS!

Reply #205
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.

Jplay - just another scam? YES IT IS!

Reply #206
Either my soundcard (M-Audio Fast Track Pro) does not allow simultaneous S/PDIF in/out,


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.
Ceterum censeo, there should be an "%is_stop_after_current%".

Jplay - just another scam? YES IT IS!

Reply #207
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.

Jplay - just another scam? YES IT IS!

Reply #208
I think I can offer some help, please see the video below (please use 720p):

http://youtu.be/QMxzF3ctKx8

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 uploaded the original and recorded music here for anyone who want to align and compare the files themselves:
http://www.sendspace.com/file/f4p0se

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

Jplay - just another scam? YES IT IS!

Reply #209
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.

Jplay - just another scam? YES IT IS!

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

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

Jplay - just another scam? YES IT IS!

Reply #211
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".

Jplay - just another scam? YES IT IS!

Reply #212
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.

http://www.6moons.com/audioreviews/jplay/3.html
Quote
I nearly got banned on the official foobar forum where asking questions related to sound quality is against their regulations

Jplay - just another scam? YES IT IS!

Reply #213
Would you mind translating that to layman a terms for me?


It (RMS power values) means the foobar sample is 'louder' than the Jplay sample.  An 'audible difference' result for ABX of these would be no surprise.

If these are of the same snippet of music, then they cannot possibly both be bit-perfect.  They are very significantly different.

Jplay - just another scam? YES IT IS!

Reply #214
What if I record jplay output, save it as a flac, and play that back with jplay?

Here's a situation where I would be on-board with mindlessly doing this 100 times and then auditioning the result at the end.

Jplay - just another scam? YES IT IS!

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

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!

Jplay - just another scam? YES IT IS!

Reply #216
sabrehagen:

Do you
agree that each [of the samples you provided] matches [your] expectations based on [your] double-blind testing
when played back through foobar2000???


Jplay - just another scam? YES IT IS!

Reply #218
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
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Jplay - just another scam? YES IT IS!

Reply #219
yes, i believe they do.

Then it would seem that foobar2000 is not altering the sound but either VLC or Jplay is altering the sound, if not both.

Now it's time to figure out which is doing what.

At this point, I suggest you run each version through their respective player and record the output and then continue the process.  Repeat this a few times.  Feel free to do the same with foobar2000.

Jplay - just another scam? YES IT IS!

Reply #220
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.
"I hear it when I see it."

Jplay - just another scam? YES IT IS!

Reply #221
All I can surmise is this latest attempt to justify paying for something that can be done by fb2k for free has failed.  As to jplay being a scam, I think this topic stands on the merits.

Jplay - just another scam? YES IT IS!

Reply #222
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.

Jplay - just another scam? YES IT IS!

Reply #223
What if I record jplay output, save it as a flac, and play that back with jplay?

Here's a situation where I would be on-board with mindlessly doing this 100 times and then auditioning the result at the end.


Looping jplay 100 times should obviously grant true cosmic god-like audio quality, should it not? 

 

Jplay - just another scam? YES IT IS!

Reply #224
Either my soundcard (M-Audio Fast Track Pro) does not allow simultaneous S/PDIF in/out,


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.

4. Bit-depth of your test signal should not be higher than 24-bit.

5. Correctly configure your SPDIF master/slave setting.

I uploaded a video to demonstrate bit-perfect playback (MPC-HC) and recording (RMAA) using MME:
http://youtu.be/Z8HD0YCvhv8
Audio files:
http://www.sendspace.com/file/jcmh5f

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.