INTERACT FORUM
More => Old Versions => JRiver Media Center 25 for Windows => Topic started by: Cinelder on June 21, 2019, 07:23:59 pm
-
After updating to MC 25.0.62, if "analyze audio" is checked in the library import configuration (/file/library/library import/configure auto-import/) MC 25.0.62 begins analyzing all audio files (i.e. the entire library) whether or not they've already been analyzed. This is inconvenient - my audio library is very large, and unnecessary - the smartlist "Audio -- Task -- Needs audio analysis is empty. Under previous builds of MC 25, (or if I open MC 24.0.78 and do a library import with the same configuration as MC 25.062) files that are already analyzed are ignored.
-
It's probably analyzing for files that use HDCD decoding. It's a recent change.
https://yabb.jriver.com/interact/index.php/topic,121147.0.html
-
My library as well is currently being re-analyzed after this update.
-
It's probably analyzing for files that use HDCD decoding. It's a recent change.
https://yabb.jriver.com/interact/index.php/topic,121147.0.html
Thanks for the response. I was concerned that checking that audio analysis box / writing that HDCD tag will now change every file in my library with follow on backup and synchronization consequences. I may be flaunting my ignorance, but as far as I know, I never ripped anything from HDCD except as a CD, so I was wondering what's the advantage versus the headache. I searched for HDCDs that I might have ripped, and came up with one - Joni Mitchell's album "Don Juan's Reckless Daughter". I checked the tags - sure enough the HDCD tag field had a value of "-1". I manually did an audio analysis of these files, and lo and behold, the value in the HDCD field turned to "1". I have no idea what else that does, but it does seem that there is some kind of HDCD information in a file ripped as a CD from an HDCD disc. So, I've enabled the check box and let the audio analysis do its HDCD thing on library import
-
Just discovered a pretty bad side effect of the -1 default for files that haven't been analyzed for HDCD, when playing files to MC as a renderer from ANY server, HDCD decoding is ALWAYS applied since the file has not been "Analyzed" and HDCD is a custom header which isn't passed by the DLNA protocol.
The ONLY workaround I can find for now is to set the DLNA server output for MC renderers to L24 (24 bit no header).
Since the files have to be 16 bit to do HDCD processing this defeats it.
It's possible that this only applies to the linux build as a renderer since it was created during the transition from on/off to 1,0,-1. It would be nice if someone with a windows MC acting as a push-to renderer could test this.
Just push a lossless 16 bit file to a MC renderer with the current build and check to see if HDCD processing is on in DSP studio.
-
Just push a lossless 16 bit file to a MC renderer with the current build and check to see if HDCD processing is on in DSP studio.
yes it comes up with "Process HDCD enabled, but bitdepth wrong" in Audio Path
-
Just discovered a pretty bad side effect of the -1 default for files that haven't been analyzed for HDCD, when playing files to MC as a renderer from ANY server, HDCD decoding is ALWAYS applied since the file has not been "Analyzed" and HDCD is a custom header which isn't passed by the DLNA protocol.
Hi Bob.
This was reported (and confirmed by me) here:
https://yabb.jriver.com/interact/index.php/topic,121147.msg837487.html#msg837487
I'll fix it first thing Monday.
-
FWIW, that also appears in Audio Path when connected to a remote library and "convert audio if necessary" is enabled under /Media Network/Audio Conversion". If the box to convert if necessary is left unticked, FLAC files with HDCD info from the remote library are recognized and processed as "Process HDCD", but if the box is ticked and MC converts the audio tp MP3, the entry in the Audio Path also reads "Process HDCD enabled, bitdepth wrong" as above.