Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TheLion]

what I don't quite understand is that JRiver advertises it's audio engine as being "of audiophile quality" and with state of the art 64bit processing/ASIO.... This suggests that the final output with this engine is better than using most other media players like simple WMP with appropriate plugins. You - yourself - open this can of worms that the audio engine and your engineering decisions make a difference. So why is it suddenly hard to believe that another engine with other decisions involved sounds different? Following the same line of argument your 64bit processing, ASIO support, buffering options,... make no difference at all because the output bitstream is/should be identical to what WMP, iTunes,... outputs...Is it not? 

[JimH]

I don't think we're claiming that only MC can deliver audiophile quality.  I do think we have a significant lead in this area.

I'm not aware of iTunes being able to deliver a bit perfect stream.  Maybe with third party software.

WMP should be capable of delivering a bit perfect stream with ASIO or WASAPI.  Foobar is also excellent.

I don't think a player that requires plug-ins for best quality should be said to be audiophile quality.

It's also a problem that WMP won't play ALAC files and iTunes won't play WM Lossess.  FLAC support should also be expected.

The 64 bit internal data path means that DSP effects can be applied without loss of quality.  The precision so far exceeds human hearing abilities that any loss in rounding is irrelevant.  It's multiple orders of magnitude different.

MC's support for audiophile hardware is unsurpassed.

MC's support of high sample rate recordings like those from HDTracks is unsurpassed.

MC supports DSD (Super Audio CD format) with the right equipment and driver.

More here:
http://wiki.jriver.com/index.php/Audiophile_Info

In total, no other player has gone to these lengths to support the audiophile community.  And we're not stopping there.   We will continue to listen to these customers and provide the features and tools that they need.  We will, however, apply our own knowledge of engineering.

[Matt]

Jim's answer is good.

A little note is that I'm not aware of how to use WMP for ASIO or WASAPI exclusive.

[Matt]

There are two camps with regards to audio quality:
A) The original is perfect, and all processing is bad processing
B) Good sound is the goal, and sometimes processing can help
[edit -- after thinking more, there's also a C) Processing can be good, but I want to do it in my external hardware because, well, it was expensive]

I'm in B.  I don't believe the original engineer was magic, and my speakers and ears certainly aren't the same.

For this camp, 64-bit processing is wonderful.

If you're in A, 64-bit processing is irrelevant (unless you want volume).

There are still lots of other important features to consider like format support, gapless, user interface, audio output modes, stability, etc.  I'll ignore these for now.

For the people that only want A, and think it's possible to have still better audio quality, I see two main claims:

1) Timing matters

The best interfaces (ASIO, WASAPI Event Style) work like this: they periodically call and ask for data.  The _only_ timing that can matter is how fast you can fulfill this request.  I believe Media Center has the most efficient buffer fill that can be implemented on a computer (a no-lock circle buffer with no additional processing).  In other words, there's no room for improvement here.


2) Other processing (background threads in the player, OS background processes, etc.) hurts audio quality

This is a more slippery claim.  I've heard machines where moving the mouse cursor was audible on the sound card, or where CPU or GPU usage caused playback hiccups (especially with USB interfaces).  Hard drives can also cause audible noise on poorly shielded outputs.

However, with good hardware this simply doesn't happen.  But since it does with bad hardware, it's hard to dismiss completely.

So how much of the CPU usage is from audio playback?  On my machine, even doing 7.1 JRSS, Room Correction, Bass Management, and Parametric Equalization, audio playback never takes more than 1% of the CPU.  With no processing for 2.0 output, it's at least twice as fast.  Even if this were twice as fast again (JRiver has a well optimized audio chain, so this isn't realistic), why would 0.25% be better than 0.5% CPU?

It's possible we could push further down this road (a mode that blacks the screen, hides the cursor, disable system services, etc.), but it's also possible it's a rabbit hole that's best avoided.

[JimH]

1) Timing

The best interfaces (ASIO, WASAPI Event Style) work like this: they periodically call and ask for data.  The _only_ timing that can matter is how fast you can fulfill this request.  I believe Media Center has the most efficient buffer fill that can be implemented on a computer (a no-lock circle buffer with no additional processing).  In other words, there's no room for improvement here.

I am in complete agreement on this.  The timing of how bits are delivered to a DAC or receiver is irrelevant since the devices draw from a buffer on their own schedule.  

It's similar to the situation where cars go speeding past you, but then you all stop at the red light together.  The timing of the cars' arrival at the red light has no relationship to the timing of the light turning green again.

[jmone]

There are two camps with regards to audio quality:
A) The original is perfect, and all processing is bad processing
B) Good sound is the goal, and sometimes processing can help

I think that is broadly correct.
Camp A:  Wants to keep the source as is, and importantly wants confirmation from the player of such status.  For them transparency is the goal of their AV Equipment with modification then done to the actual listening environment itself (see Lion's post on dedicated rooms with specialised acoustic treatments etc).
Camp B:  More than happy to apply processing to source to suite the listeners individual preference in the existing listening environment. 

No one Camp is more right that the other and both are valid (but mutually exclusive) options.

In the end it showed that we certainly couldn't tell the two options apart - although we where guessing alot and the placebo effect was the only thing we proved! ;-)

...and I think this is where rigorous ABX testing of many mfr "audiophile" claims tend to expose a Perception Bias over actual differences in many cases.  The issue is of course that there is not a black and white distinction and there will be alot of products that sit in the grey area between a change that we can all appreciate and pure snake oil (I saw a claim that swapping the dials on your av equipment with wooden ones held reduced micro vibrations for example).

On another matter - I was able to distinguish between sync. and async. mode of my audio interface doing the same double blind procedure each and every time (async being "fuller, warmer", and sync. "clearer, more aggressive"). 

So the bit I don't understand is that if the Player (MC for example) is just filling a DAC's buffer how can it affect the DAC's output as long as the buffer never unexpectedly empties.  Is there some other communication done between the Player and the DAC on this timing as otherwise I don't get it.  Of course a good sample size ABX test would confirm the effect but I'm interested in the why as well.

[JimH]

I've split a couple of audiophile discussion threads:

Bitperfect streams sound different

and

Audiophile Plumbing

Since these topics can be so controversial and generate so much discussion, please consider starting new threads on what you feel is important.

This thread, as it currently stands, is a good statement of where JRiver stands and what we believe is important for high quality audio.

Thanks.