INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: JimH on May 14, 2013, 09:29:14 am
-
We've made a change to simplify how the WASAPI audio output mode is selected. Below is a summary. Most people should now be able to select WASAPI and be finished. Both modes use the latest improvements for audio bitdepth handling, DSD bitstreaming support, etc.
------------------ From the wiki topic called Audio Output Modes (http://wiki.jriver.com/index.php/Audio_Output_Modes) ------------------
WASAPI Modes
There are two main ways to communicate using WASAPI. Both deliver the same audio data and will sound the same. One may work better with specific hardware.
Terminology Changes IN 18.0.183 and Above
WASAPI is now just WASAPI. In the options (next item below the selection) you can check "Disable event style..." to get the output mode previously called "WASAPI", used mainly with older hardware. In other words, WASAPI now defaults to Event Style.
Versions prior to 18.0.183
WASAPI output mode pushes data from Media Center to the sound device. It works with nearly all hardware.
WASAPI Event Style lets a sound device pull data from Media Center. This method is not supported by all hardware, but is recommended when supported.
If you have problems ...
1. Try toggling event style off and on (in the audio output options).
2. Try manually picking a bitdepth. This could help if a driver says "yes, that bitdepth will play" but then does the wrong thing with it.
This is in Audio Output Mode Settings, as in the attached picture.
-
Please try 18.0.187.
http://yabb.jriver.com/interact/index.php?topic=80682.msg549221#msg549221
-
Please try 18.0.187, uploading now. It will be there in about two minutes.
.187 solved my video playback issues while using WASAPI. Thanks a lot for the quick fix!
-
Please try 18.0.187.
http://yabb.jriver.com/interact/index.php?topic=80682.msg549221#msg549221
Fixed Wasapi problem for the M2Tech Young dac Jim, thanks for the quick response.
.187 broke a Windows 8 audio optimisation script I use, but that's my problem to sort!
thanks. :)
-
Event style never worked with my 'New' Bifrost using the current [2nd generation] drivers for Windows. Only 'Wasapi' worked. If you use ASIO then you must be using [ASIO4ALL]..... am I correct? If not could you please tell me how you are using your current ASIO?
The reference to 'Older Hardware' in the initial post is really not completely accurate. My hardware is new but is dependent on a poorly written driver from Cmedia.
I have the Bifrost as well, I ended up using the Realtek native driver for S/PID. The Cmedia driver didnt work. Win 7, ASUS HTPC
-
Odd ASIO dosnt work with my Bifrost, on a ASUS AT310 HTPC
I am running on a ThinkPad T400s. Settings screens attached. I am using NO DSP addons.
-
I have the Bifrost as well, I ended up using the Realtek native driver for S/PID. The Cmedia driver didnt work. Win 7, ASUS HTPC
As FAIK you shouldn't need a 'driver' for s/pdif just an interface.....(I stand to be corrected). I have both first and second generation drivers for Windows (USB for Bifrost) and the second generation has changed from the first with regards to Win7. Neither worked for me in a Win8 environment - even trying to install with legacy for Win7. Regardless I would try to stay with a USB connection if possible - even though the guys at Schiit seem to think that S/PDIF is a better interface.
Victor
-
I did a head to head and I though the S/PID sounded ever so slightly smoother ? But this march to digital audiophilden has lead to several "was I dreaming" conclusions sooo..... just my opinion
-
Mine works only on WASAPI with event disabled on 16 or 24 bit in 32 package.
-
This method [EVENT] is not supported by all hardware, but is recommended when supported.
Event Mode is great, but why the default based on your statements?
-
My JRiver just got upgraded to 18.0.189
But now I am unable to use the output format wasapi..
when I set at wasapi - I have this fluttering noise at the background....
I think I wanna to roll back to the previous version..
it is possible.
-
to add-on..
after several attempt... can only use Direct Sound..
and I am using Schiit USB driver on win7..
-
My JRiver just got upgraded to 18.0.189
But now I am unable to use the output format wasapi..
when I set at wasapi - I have this fluttering noise at the background....
I think I wanna to roll back to the previous version..
it is possible.
Please select 'WASAPI', then try different bitdepths (start with 24-bit) in Options > Audio > Output mode settings...
My guess is that the automatic bitdepth selection isn't working with your hardware for some reason.
Thanks, and please let us know what you find.
-
I too am unable to get 24 bit playback with the new version. The (padded) output has a fluttering sound.
I am using an HDMI output from my laptop (Windows 7) to a NAD M51 DAC.
How can I roll back to the old version while this is being fixed?
-
I too am unable to get playback with the new version.
I am using an HDMI output from my laptop to a NAD M51 DAC.
How can I roll back to the old version while this is being fixed?
Welcome.
Please try my advice one post up and let us know what you find.
Thanks.
-
Thank you for your support.
My laptop is running Windows 7. I am using the HDMI output to my NAD M51 DAC.
With J River 18.0.189 I have checked WASAPI, and I have checked Disable event style. The bitdepth is set to Automatic.
I can play 44.1kHz 16bit FLAC files; however, tools is indicating no changes are being made yet the output is 44.1kHz 24bit (padded) using WASAPI (direct connection).
When I try to play a 24bit FLAC file I get a fluttering sound.
This update is not working for me.
Thank you again for your support.
-
Thank you for your support.
My laptop is running Windows 7. I am using the HDMI output to my NAD M51 DAC.
With J River 18.0.189 I have checked WASAPI, and I have checked Disable event style. The bitdepth is set to Automatic.
The default is to use event style.
Please try with the box 'Disable event style' unchecked.
Does that fix the flutter?
-
Thank you again for your support.
With the Disable event style unchecked I get the following error:
Something went wrong with playback.
Details:
Playback could not be started on the 'WASAPI' using the format '192kHz 24bit 2ch'.
This output format may not be supported by your hardware. You can use DSP Studio to change the output to a compatible format.
Also, make sure that your system has a valid sound playback device and that it is properly configured in playback options.
I get the same error message when I try to play a 44.1kHz 16bit 2ch FLAC file.
-
@razzzor
What happens if you manually select a bit-depth (try 24-bit or 24-bit padded) in Options > Audio > Output mode settings?
Also, sorry for this problem. The automatic configuration is working for most hardware, but it appears that it's a problem on some devices. Hopefully we can figure out why with some help.
-
If you're having problems with WASAPI (and WASAPI used to work), there are two things to try:
1) Toggling the 'Disable event style' checkbox in Options > Audio > Output mode settings...
2) Manually picking a bitdepth in Options > Audio > Output mode settings...
#1 might be necessary if you had to use 'WASAPI' instead of 'WASAPI - Event Style' with the old naming scheme.
#2 might be necessary if a driver says "yes, that bitdepth will play" but then does the wrong thing with the bitdepth.
If you could report your hardware and results, it might help us make this more automatic for users in the future.
Thanks.
-
My hardware is a Toshiba Qosmio X500-067 laptop and a NAD M-51 DAC. I am using HDMI.
I have the Output Mode set to WASAPI. I am trying to play 24 bit FLAC files.
(i) Output Mode Setting: Disable event style Checked and 24 bit integer selected I get an error message with no playback
(ii) Output Mode Setting: Disable event style Checked and 24 bit integer (in a 32 bit package) selected I get playback with fluttering
(iii) Output Mode Setting: Disable event style Unchecked and 24 bit integer selected I get a playback error message
(iv) Output Mode Setting: Disable event style Unchecked and 24 bit integer (in a 32 bit package) selected I get a playback error message.
With the Disable event style checked and the bitdepth set to automatic I am able to play are 16bit 44.1kHz 2ch files, but J River is outputting these files as 24bit, yet J River is saying the file path is direct and no changes are being made.
Thank you again for your support.
-
Using Windows 7 System Restore I was able to roll back my system to May 19th (three days ago). J River version 18.0.175 is working fine. The latest build does not work for me. I am not sure if it because I am using HDMI or because of my DAC (NAD M51). Please let me know if you fix this problem.
-
I split the discussion on Gungnir / Schiit Drivers to a new thread:
http://yabb.jriver.com/interact/index.php?topic=80835.0
-
If you have problems, make sure you have the latest build. It's currently 18.0.189 (http://yabb.jriver.com/interact/index.php?topic=80785.0).
-
Not having any problems, but I was reading the updated WASAPI page on the wiki, and noticed this:
The default buffering value for WASAPI (post 18.0.183) is 50ms.
On my system, Buffering is still set to "100 milliseconds (recommended)" - I assume that you simply left settings as they were if WASAPI was previously in use.
Is the "recommended" setting based on some sort of hardware detection, or does the text need updating?
-
Your previous settings won't be overwritten.
-
Your previous settings won't be overwritten.
That's what I assumed - but shouldn't it be listed as "50 milliseconds (recommended)" if that is the new default - or is the "recommended" comment based on some kind of hardware/driver detection?
-
The update made every track sound heavily distorted. I tried finding the settings mentioned, but WASAPI did not exist, nor did "Event Style". It was broken by this update. I tried downloading ...187, but it did the same thing. I had to go back to the first one I downloaded.(.. 175). I cannot find any reference to WASAPI at all in any menu. The update had the bitrate and bits at 44.1k and 64!!! You need to fix that
-
WASAPI is in the second item in the Audio settings. Unless you're on XP.
-
WASAPI is in the second item in the Audio settings. Unless you're on XP.
Yep still using XP on this machine. This machine has been dedicated to my audio system for quite a while. Motherboard was updated to i3 but no reason to change the OS. It has an Asus Essence STX audiophile sound card. I have Win 7 Pro 64 bit on another machine, which has a different purpose, but I actually prefer XP. Hopefully, you will make it compatible, otherwise I can't upgrade. I just want to play my 192/24 FLAC files on my very high end audio system (4 way 24 dB electronic crossover, phase perfect, 18" subwoofers on both sides, ScanSpeak drivers etc..). I don't play mp3s at all, BTW. All the players seem to cater mostly to people who use mp3s, lol.
-
I have problems after the update to version 18.0.189
Wasapi settings:
Device: Musical Fidelity M1 DAC 24/96
Disable event Style - unchecked
Bitdepth: automatic
1. from internet radio (1.fm blues radio)
- not bitperfect (it was bitperfect before the update)
Audio Path
input: 44.1khz 2ch from source format MP3
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI (not using enough bits to output the input directly)
2. from CD rip
- bitperfect
Audio Path: Direct
input: 44.1khz 16bit 2ch from source format WAV
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI (direct connection)
----------------
After the update the sound quality isn't the same anymore.
From the internet radio source it's not bitperfect, it's a pain to listen to, and from CD sound source the music is 'slowlier' with lesser dynamic, with distortion, seems like something happened with the WASAPI driver or the path.
Question 1: What can I do to restore the very good sound quality that I had before? (without reinstall the earlier version?)
Question 2: How can I stop the automatic update to the latest new version in the future?
Thanks for your support.
-
Try checking and unchecking the event style option.
Try explicitly setting the bitrate.
Thank you for the details. It's helpful.
-
I had previously used WASAPI - Event Style, but after updating to the latest version the output mode set itself back to ASIO. This caused me problems (no playback), and although I found this thread and fixed it quickly, I assume it's a bug that it changed to ASIO in the first place?!
-
Try checking and unchecking the event style option.
Try explicitly setting the bitrate.
Thanks, but I tried these before without success.
Now I reinstalled version 18.0.175 and all my problem has gone.
Audio Path
input: 44.1khz 2ch from source format MP3
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI Event-style (direct connection)
It's bitperfect now and this strange message disappeared:
(not using enough bits to output the input directly)
Thanks for your support
-
Hi, been a JRiver user for about 18 months, and love it. I am not very techie, but have noticed that recently I may not be bitperfect. I am not sure. My noir skin is no longer blue, and I have the following message:
(http://img.photobucket.com/albums/v336/walkman666/JRiverss.png)
I use a violectric v800 DAC (no resampling done), and have JRiver set to Wasapi with no changes being made. Perhaps this new message about "not using enough bits to output the input directly" is moot...?
Okay, so I went ahead and downgraded to version 18.0.180, a version that is pre-"New Wasapi, "and now am blue and bitperfect again:
(http://img.photobucket.com/albums/v336/walkman666/JRiverss-2.png)
I'd prefer to be the latest version and have bitperfect output again. Any help would be appreciated. thx!
-
JimH suggested that I repost this in this thread.
I am new to DSD, so please take this post accordingly.
I was using version 18.0.174 with KERNEL STREAMING with DoP and local DSD (64/128) content was working.
I updated to 18.0.189 and KERNEL STREAMING with local DSD (64/128) playback stopped. It gives me an error message "Something went wrong with playback. ... You can use DSP Studio to change the output to a compatible format. ...".
I am able to playback local DSD content with WASAPI(32-bit/Exclusive) on 18.0.189 (but no longer with Kernel Streaming).
Should KERNEL STREAMING work with DSD in 18.0.189 ?
-
I have problems after the update to version 18.0.189
Wasapi settings:
Device: Musical Fidelity M1 DAC 24/96
Disable event Style - unchecked
Bitdepth: automatic
1. from internet radio (1.fm blues radio)
- not bitperfect (it was bitperfect before the update)
Audio Path
input: 44.1khz 2ch from source format MP3
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI (not using enough bits to output the input directly)
2. from CD rip
- bitperfect
Audio Path: Direct
input: 44.1khz 16bit 2ch from source format WAV
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI (direct connection)
----------------
After the update the sound quality isn't the same anymore.
From the internet radio source it's not bitperfect, it's a pain to listen to, and from CD sound source the music is 'slowlier' with lesser dynamic, with distortion, seems like something happened with the WASAPI driver or the path.
Question 1: What can I do to restore the very good sound quality that I had before? (without reinstall the earlier version?)
Question 2: How can I stop the automatic update to the latest new version in the future?
Thanks for your support.
I have problems after the update to version 18.0.189
Wasapi settings:
Device: Soundmax
Disable event Style - unchecked
Bitdepth: automatic
1. from internet radio (radio extra MP3 STREAM 320 KBS)
- not bitperfect (it was bitperfect before the update)
Audio Path
input: 44.1khz 2ch from source format MP3
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI (not using enough bits to output the input directly)
I confirm to me same problems.
-
Thanks, but I tried these before without success.
Now I reinstalled version 18.0.175 and all my problem has gone.
Audio Path
input: 44.1khz 2ch from source format MP3
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI Event-style (direct connection)
It's bitperfect now and this strange message disappeared:
(not using enough bits to output the input directly)
Thanks for your support
Now I reinstalled version 18.0.175 and all my problem has gone.
Audio Path
input: 44.1khz 2ch from source format MP3
changes: No changes are beeing made
output: 44.1khz 24bit 2ch using WASAPI Event-style (direct connection)
It's bitperfect now and this strange message disappeared:
(not using enough bits to output the input directly)
I confirm same problems.
-
We've made a change to simplify how the WASAPI audio output mode is selected. Below is a summary. Most people should now be able to select WASAPI and be finished. Both modes use the latest improvements for audio bitdepth handling, DSD bitstreaming support, etc.
------------------ From the wiki topic called Audio Output Modes (http://wiki.jriver.com/index.php/Audio_Output_Modes) ------------------
WASAPI Modes
There are two main ways to communicate using WASAPI. Both deliver the same audio data and will sound the same. One may work better with specific hardware.
Terminology Changes IN 18.0.183 and Above
WASAPI is now just WASAPI. In the options (next item below the selection) you can check "Disable event style..." to get the output mode previously called "WASAPI", used mainly with older hardware. In other words, WASAPI now defaults to Event Style.
Versions prior to 18.0.183
WASAPI output mode pushes data from Media Center to the sound device. It works with nearly all hardware.
WASAPI Event Style lets a sound device pull data from Media Center. This method is not supported by all hardware, but is recommended when supported.
If you have problems ...
1. Try toggling event style off and on (in the audio output options).
2. Try manually picking a bitdepth. This could help if a driver says "yes, that bitdepth will play" but then does the wrong thing with it.
This is in Audio Output Mode Settings, as in the attached picture.
Confused. As JimH has clearly stated, unless I'm missing something, nothing has changed. Just which setting is default, and a naming convention. Seems to me like people who never used WASAPI are trying for first time, or trolling?
-
Confused. As JimH has clearly stated, unless I'm missing something, nothing has changed. Just which setting is default, and a naming convention. Seems to me like people who never used WASAPI are trying for first time, or trolling?
There are a few things that seem to have happened:
- People previously using WASAPI may have had their audio output changed to ASIO - at least some people have been reporting that.
- If people were intentionally using WASAPI, rather than WASAPI Event because their hardware doesn't support it, they seem to have been set to WASAPI Event after the update.
- The bit-depth options were moved from DSP to the output mode settings, and switched to a new method of auto-detection. Some output modes (Kernel Streaming?) now have no way to reduce bit-depth if their hardware doesn't support it. Auto-detection may not be working correctly on some systems either.
- According to the Wiki, the buffer was reduced from 100ms by default, to 50ms. I saw no change, as I was previously using WASAPI Event, but people previously using WASAPI may now set to 50ms. (note: 100ms is still listed as "recommended" on my system, rather than 50ms though - the text needs updating) Some people are reporting issues that sound like they have been caused by this. Unfortunately, I don't know what can be done for people that have already updated, but it is important that the previous value is retained.
- Exclusive access may have been disabled, or not be enabled by default on some systems? Some people have definitely been reporting that problem too. As I understand it, with exclusive access disabled, the output format must match the Windows Control Panel settings. Perhaps the issue is that they had disabled exclusive output manually, but were only using 16-bit before, and now auto has configured them to a 24-bit output, which breaks playback
.
I don't know how Media Center detects/reacts to a failure state, but it seems like it will often fail in a way that doesn't allow music to play.
1. Can Media Center read the Control Panel output settings? It seems that if Exclusive mode is disabled, it should automatically set the output format to match, and inform the user of this change.
For example:
Playback was unable to start with the selected output format: 44.1kHz, 16-bit Integer, 2 channels, because WASAPI Exclusive Mode is disabled.
This requires Media Center's output to match your system settings, which are currently: 96kHz, 24-bit Integer, 6 Channel.
Click OK to continue with these settings, or Cancel to stop playback.
2. Event Style seems like it should be changed from a checkbox, to a drop-down menu like bit-depth. By default it should be on automatic, with the option to force it on or off.
If playback fails with Event Style, it should be disabled rather than not allowing audio to play.
3. If bit-depth has been set incorrectly, Media Center should prompt the user and configure it to Automatic. The best outcome for this would be to switch to Automatic output temporarily and continue to play music, prompting the user with something like:
Playback was unable to start using the selected output format: 192kHz, 32-bit Floating-Point, 2 channels.
Media Center has now automatically configured your output settings: 192kHz, 24-bit (padded), 2 channels.
Click OK to continue using these settings, or Cancel to stop playback.
Currently, if I set bit-depth incorrectly (as a test I used 32-bit Integer) the error is incorrect, and it tells me the format of the track, rather than the output format it was trying to use:
(http://www.abload.de/img/errorr8u5q.png)
-
Confused. As JimH has clearly stated, unless I'm missing something, nothing has changed. Just which setting is default, and a naming convention. Seems to me like people who never used WASAPI are trying for first time, or trolling?
My first MC18 was version 18.0.100. I have a Musical Fidelity M1 Dac it's an asynchronous device which means it pulls data from Media Center.
I use Windows 7 (64-bit) so I had to choose WASAPI Event Style to get the best sound quality from my DAC. It worked faultless, I had bitperfect from every source.
Using the new version 18.0.189 something happened with WASAPI (event style), it's not bitperfect anymore, and I hear a degradation in sound quality.
I got a new message "not using enough bits to output the input directly". This message came with this new version and as I understand the only change was the new bitdepth function with automatic and manual state. I tried both but I didn't get bitperfect, only that new message.
When someone call people with problem trolls it's not fair.
-
Fair enough, "trolls" is probably a bit much. ;D Maybe this has to do with the 24bit setting he posted about.
good luck
My first MC18 was version 18.0.100. I have a Musical Fidelity M1 Dac it's an asynchronous device which means it pulls data from Media Center.
I use Windows 7 (64-bit) so I had to choose WASAPI Event Style to get the best sound quality from my DAC. It worked faultless, I had bitperfect from every source.
Using the new version 18.0.189 something happened with WASAPI (event style), it's not bitperfect anymore, and I hear a degradation in sound quality.
I got a new message "not using enough bits to output the input directly". This message came with this new version and as I understand the only change was the new bitdepth function with automatic and manual state. I tried both but I didn't get bitperfect, only that new message.
When someone call people with problem trolls it's not fair.
-
I use Windows 7 (64-bit) so I had to choose WASAPI Event Style to get the best sound quality from my DAC. It worked faultless, I had bitperfect from every source.
Using the new version 18.0.189 something happened with WASAPI (event style), it's not bitperfect anymore, and I hear a degradation in sound quality.
I got a new message "not using enough bits to output the input directly". This message came with this new version and as I understand the only change was the new bitdepth function with automatic and manual state. I tried both but I didn't get bitperfect, only that new message.
The difference is that what is considered to be "bit-perfect" has changed with this update.
An MP3 file does not have a specific bit-depth, even if the source was 16-bit; it is floating point data and processed as 64-bit audio inside Media Center (http://wiki.jriver.com/index.php/Audio_Bitdepth#Bitdepth_of_Lossy_Formats).
So it is not possible for any hardware available today to offer "bit-perfect" MP3 output - we are only just beginning to see hardware which accepts a 32-bit input.
Perhaps there should be some indicator in the OSD to show that the audio is being decoded to 64-bit, or the "not using enough bits" message should be removed from lossy formats.
Nothing has changed with regards to audio quality though - only what is considered to be "bit-perfect".
-
I have the same problem too:
quoted my post from:
http://yabb.jriver.com/interact/index.php?topic=80785.msg550474#msg550474
================
DoP over Ethernet to Logitech Touch Failed on v189 (success on v175)
I can play DoP over Ehternet to Logitech Squeezebox Touch (EDO plugin) to Myteck Stereo 192-DSD on version 175 with the following setting:
installed Whitebear v2.5.0.3212 (no setting required)
on J River 175:
Wasapi Event Style with "Default" output mode setting
Bitreaming mode: Custom -> DoP 1.0
Enable Media Server --> also enable DoPE under advance setting
The above works fine and I can play iso, dsf, dff file through network to Touch to Mytek and lit up the dsd light. However, after upgrading to version 189 last night, the wasapi event style disappeared and what ever I did for the setup (either same as version 175 or tried other possible settings), it fails to send DoP to Touch to Mytek. Just white noise. It seems it's not bit perfect for the whole path so that DoP wav sounds with white noise.
(p.s. I don't want to manually set bit depth to 24bit since my music collection has 16 & 24bit and I don't want to use 24bit with my 16bit music files.)
Please correct the problem as soon as possible.
Thanks.
-
However, after upgrading to version 189 last night, the wasapi event style disappeared and what ever I did for the setup (either same as version 175 or tried other possible settings), it fails to send DoP to Touch to Mytek. Just white noise. It seems it's not bit perfect for the whole path so that DoP wav sounds with white noise.
WASAPI Event Style is still there - Event Style is now just a part of the WASAPI Output Mode Settings. I wish I could be of more help with your DoP problem though.
p.s. I don't want to manually set bit depth to 24bit since my music collection has 16 & 24bit and I don't want to use 24bit with my 16bit music files.
You really should be outputting the maximum bit-depth that your hardware supports at all times for the best audio quality.
-
From the first post, what was formerly called "WASAPI Event Style" (which most people used) is now called just WASAPI. The non Event Style WASAPI can be set by checking the "Disable Event Style" setting in the second section of the Audio settings.
Terminology Changes IN 18.0.183 and Above
WASAPI is now just WASAPI. In the options (next item below the selection) you can check "Disable event style..." to get the output mode previously called "WASAPI", used mainly with older hardware. In other words, WASAPI now defaults to Event Style.
-
Thanks JimH. Understood on the new Wasapi Event and Non-Event Wasapi settings. After toggling this check box, and setting the bitdepth explicitly, I and some others are still getting the message "not using enough bits to output the input directly."
I went back to .189., set for Wasapi (new event style), set bitdepth to "24 bits integer" (please let me know if that is incorrect for my newish violectric v800 dac), and see the blue bitperfect indicator for an HDTracks download, and still see the "not using enough bits to output the input directly" for other files (most of my music is ripped CDs at a compressed rate of 256).
Is there something else we should be doing to re-restore the bitperfect indication? Or, is this message accurate based on more technical specificity as indicated by hifi_Man.
The difference is that what is considered to be "bit-perfect" has changed with this update.
An MP3 file does not have a specific bit-depth, even if the source was 16-bit; it is floating point data and processed as 64-bit audio inside Media Center (http://wiki.jriver.com/index.php/Audio_Bitdepth#Bitdepth_of_Lossy_Formats).
So it is not possible for any hardware available today to offer "bit-perfect" MP3 output - we are only just beginning to see hardware which accepts a 32-bit input.
Perhaps there should be some indicator in the OSD to show that the audio is being decoded to 64-bit, or the "not using enough bits" message should be removed from lossy formats.
Nothing has changed with regards to audio quality though - only what is considered to be "bit-perfect".
-
... the "not using enough bits" message should be removed from lossy formats.
I agree that this would help in eliminating a source of confusion, and the 'bit perfect' indicator once again be made to light up in such circumstances.
-
I agree that this would help in eliminating a source of confusion, and the 'bit perfect' indicator once again be made to light up in such circumstances.
less is more, also about confusion... ;D ;)
-
I agree that this would help in eliminating a source of confusion, and the 'bit perfect' indicator once again be made to light up in such circumstances.
It was just a bug.
Next build:
Fixed: Audio Path could incorrectly account for the output bitdepth in the last few builds causing it to incorrectly say 'not using enough bits to output the input directly'.
Sorry for the trouble.
-
On the subject of bit-depth, my new DAC turned up today, and I noticed something interesting:
Media Center is outputting 32-bit via ASIO (and I guess the driver truncates it to 24-bit) so when I start playback, or when tracks change, the 24-bit indicator lights up - but if I have all DSP plugins disabled, the indicator drops down to 16-bit after about half a second of playback with 16-bit lossless files. So that's something else which confirms that Media Center is doing absolutely nothing other than adding zeros when outputting a 24-bit signal with 16-bit files. (not that I doubted it for a second)
-
Sorry for the trouble.
Hardly trouble, in the grand scheme of things :D
In fact, for such a major change, it's been relatively painless. For me and, I suspect, the vast majority of users, the change was barely noticeable had our attention not been drawn to it.
-
If you are experiencing problems due to the changes discussed in this thread, please try the new build (18.0.191) from the top of this board. Post in this thread if any problems remain:
http://yabb.jriver.com/interact/index.php?topic=81000.0
Thanks.