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: [TOS#8] Jplay BS (Read 355 times) previous topic - next topic - Topic derived from Jplay - just another ...
0 Members and 1 Guest are viewing this topic.

[TOS#8] Jplay BS

Hello Everyone.  I do not have a dog in the JPlay fight.

However, I do have independent and objective observations I would like to share with the community in the interest of discussing real results:

JPlay vs any other player (Bughead Emperor/PinkHQ, Foobar, JRiver, PotPlayer, a few other jokes but why mention?)

In this simple comparison scenario, JPlay outperformed the competition in terms of depth and warmth.  The comparison was made with the same .WAV 44.1khz 16-bit source material.  EVERY DSP IS OFF.  Windows enchancements = off.  Windows audio ducking = off.  All available DSP's, volume controls, audio transforms, etc. found within each program natively were disabled / reduced down to their source constituents.  Bit-exact settings were used.  Even with these stripped settings, regardless of which audio output used (WASAPI, ASIO, etc.) all of the comparison players exhibited a more harsh, treble-heavy, quality.  When examined closely, these high, tinny trebles exhibited distortion qualities, and so are assumed to be the manifestation of error / distortion in the playback for whatever reasons (with the exception of Bughead Emperor / PinkHQ)

Interestingly enough, JPlay would lessen this distortion quality in the playback of the audio to the point of being much less noticeable, if even noticeable at all.

As for Bughead Emperor / PinkHQ?  It is a real PITA to use, takes a lot of waiting, and in the end you do not end up with a 'bit-exact' result.  It sounds good, but the absolute total lack of convenience has consigned it to the nearest bin for me, even if it does "sound better" than some other players. 

Okay, now that a legit ABX comparison is out of the way on a simple sound output comparison, what is next?  Now there is the JPlay Driver audio device using what I assume is a WASAPI protocol (could be ASIO in this use-case, please correct me if I am wrong) that allows you to theoretically load the JPlay Driver logic as a virtual audio device within a third-party program. 

When I attempted to use this option with Foobar, I heard no sonic differences from stock Foobar playback sources.  Same with JRiver.  When I used this option with PotPlayer, it was only available through the MBSE extension (which is why I questioned if it was an ASIO protocol instead of WASAPI) and other similar programs that offer extensibility for ASIO protocol.  When JPlay Driver was used in this way, it underperformed.  The ASIO4ALL Driver was the superior choice and winner versus JPlay Driver and a few other ASIO Drivers in this method of comparisons.

So, JPlay Driver neither flourishes nor shines when used as intended in an extensible way, at least at this current point in its development.  Whether this is on purpose or on accident is TBD.

All that is left is a comparison between <OS> Operating Systems.  This is where things get weird.  JPlay recommends the user to prefer Windows 10 or Windows Server 2019 OS, for no given reasons.  However, when testing these versions of Windows, I was surprised with the mixed results.  Windows 10 sounded so bad, it was almost like I was just listening to PotPlayer in WASAPI bit-exact mode.  I would have tested Windows Server 2019, but the software's harsh trial limitations refused to accept my PC as one contiguous platform despite the fact it is a multi-boot system (funny how it saw it as one contiguous system before, when the first trial was started, and installed at various dates on various partitions.)

When tested on older versions of Windows, the audio was absolutely stunning and marvelous.  I find this to be peculiar, that the "owner" of the software does not even understand which environment best suits their "paid" software.  Makes you wonder if they even bother to listen to any of it at all...

Conclusion:

If there are any doubts as to the veracity of my hardware and software configuration:  Each version of Windows (excluding Server, because Server is a performance nightmare anyways) was absolutely stripped down both in terms of functionality, services, and extensible frameworks.  EVERYTHING is turned off, disabled in Regedit, and double-checked in GUI because yes, I know the GUI trumps the Regedit in Windows.  Fr33thy's A-Z guide amalgamated (every tweak in one file) is the basis for my OS optimization procedure, in addition to some further advanced tweaks discovered through repeated searches.

I have shown with my tests the "one OS fits all" approach works very poorly, if even at all.  So this is one true reason why the ultimate software music playback app eludes us.

RESPECTFULLY:

In the end, JPlay is the least snake oil of the entire lot of audio players.  Sorry, folks.  The API wrapper approach for the Driver makes sense, and works flawlessly when executed within its intended environment.  This is not a review.  This is an Audio quest.