More > JRiver Media Center 22 for Windows
Bit-perfect problem found, proposed fix
mwillems:
--- Quote from: GreenMan on July 31, 2016, 05:27:40 pm ---I documented my test conditions so JRiver and other users could replicate. I invite all to try my test.
Is it possible that MC was tested to be bit-perfect with 24-bit WAV file input and 24-bit WASAPI exclusive output at one point in time, and that a bug has crept in since then? How do you capture 24-bit WASAPI exclusive output to a file for an objective comparison with the 24-bit WAV file input?
--- End quote ---
This article may be of interest, as it shows an easy objective test for establishing bit perfection of an output, which you could use to determine if anything has changed (he even appears to be using the same sound device as you):
http://www.computeraudiophile.com/content/520-fun-digital-audio-%96-bit-perfect-audibility-testing/
When the article was written, the test showed bit perfect output from JRiver, if anything's changed the test described in the article would likely show it.
Hendrik:
Thanks for the link mwillems, I remembered that there was such a thing from a few years back, but couldn't remember quite where..
Using some sort of loopback setup is probably even better for testing, as used in that article, as it gives you more control and includes even more components that ordinary playback would use.
GreenMan:
I have read that article by Mitchco before. One problem is that he used the ASIO interface to the Lynx Hilo for loopback. My experience with Lynx Hilo drivers after his article came out is that WASAPI exclusive sounds better than ASIO. As I said, the ASIO driver supports shared audio from multiple apps, so it has a mixer within that sounds like it has some distortion. The other problem is that Mitchco tested an older version of MC, while I tested the latest version.
When testing with a FLAC file, it is important to decode it to WAV outside of MC. That way, we are doing an apples-to-apples comparison. Also, please use the exact WAV file I suggested for subjective testing, as it could be higher in fidelity than the FLAC file you are using.
The chain I tested is from a two's complement WAV file, to one's complement floating-point representation, to two's complement WASAPI. It would be easy for a software developer to not achieve bit-perfect all the way through. Its all about the details. Does JRiver use scaler multiplication and division for the conversions from floating-point? On the surface, this may appear to be the same math.
Asking again, how do you capture 24-bit WASAPI exclusive output to a file for an objective comparison with the 24-bit WAV file input?
I suggest that other MC users try to replicate my test condition and report what they hear.
mwillems:
--- Quote from: GreenMan on July 31, 2016, 06:55:53 pm ---I have read that article by Mitchco before. One problem is that he used the ASIO interface to the Lynx Hilo for loopback. My experience with Lynx Hilo drivers after his article came out is that WASAPI exclusive sounds better than ASIO. As I said, the ASIO driver supports shared audio from multiple apps, so it has a mixer within that sounds like it has some distortion. The other problem is that Mitchco tested an older version of MC, while I tested the latest version.
When testing with a FLAC file, it is important to decode it to WAV outside of MC. That way, we are doing an apples-to-apples comparison. Also, please use the exact WAV file I suggested for subjective testing, as it could be higher in fidelity than the FLAC file you are using.
The chain I tested is from a two's complement WAV file, to one's complement floating-point representation, to two's complement WASAPI. It would be easy for a software developer to not achieve bit-perfect all the way through. Its all about the details. Does JRiver use scaler multiplication and division for the conversions from floating-point? On the surface, this may appear to be the same math.
Asking again, how do you capture 24-bit WASAPI exclusive output to a file for an objective comparison with the 24-bit WAV file input?
I suggest that other MC users try to replicate my test condition and report what they hear.
--- End quote ---
Have you considered that it might be more profitable for you to replicate Mitch's objective test (his methodology isn't in any way limited to ASIO) to see if there is actually a difference than to invite others to confirm your subjective one? Audacity readily accepts inputs from a variety of sources, and there are other loopback solutions as well. If you're stumped on a software solution you could literally run an spdif cable from the output of your hilo to the input. You have the tools at your disposal, and it would be trivial to test and satisfy yourself.
Why invite others to confirm your subjective results when there's an easy objective method available to you, and when the devs have already said they performed tests (in response to your query) and found that the output was bit perfect?
blgentry:
--- Quote from: GreenMan on July 31, 2016, 06:55:53 pm ---When testing with a FLAC file, it is important to decode it to WAV outside of MC. That way, we are doing an apples-to-apples comparison.
--- End quote ---
That doesn't make sense to me. You're implying that MC's code does not decode FLAC into PCM correctly. Is that what you are saying? Because MC eventually turns all non-bitstreamed music files into PCM: WAV, FLAC, MP3, etc. All end up as PCM.
Brian.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version