INTERACT FORUM

deleted

Hi there,

Thanks to @SamuriHL, I recently found a way to get HDR to HDR tonemapping to work with JRVR and besides the issue that had prevented it from working until now, I also found a few other issues with HDR passthrough, so I thought I'd report them all in one post. All my testing was done with the latest version of MC 32 at the time of posting this (build 49).

1) The biggest one is that HDR to HDR tonemapping in JRVR doesn't work if you don't first enable the OS HDR before starting playback with JRiver. I think Hendrik might already be aware of that bug, so please confirm if that's the case. It would be nice to resolve this quickly, because in the meantime we have to manually switch between SDR and HDR at OS level to get a correct picture in both SDR and HDR, especially when using a 3D LUT, as the LUT is disabled in HDR. If you don't enable HDR at the OS level, JRVR doesn't send the metadata to the display, so you can't disable the display tonemapping and let JRVR handle all the tonemapping.

2) While there is an HDR10+ option in the JRVR HDR settings and while HDR10+ metadata is detected, JRVR only partially interprets the HDR10+ metadata. For example, if you play this HDR10+ test clip made by Florian Hoech (https://ff.de/hdr10plus-metadata-test/), JRVR correctly adjusts brightness according to the metadata, but doesn't react to the contrast metadata. It's better than the Oppo 203, which doesn't react to any HDR10+ metadata, and it's different from the Dune, that reacts to both metadata but raises brightness instead of lowering it. Ideally, my understanding is that in that clip, the HDR10+ metadata should 1) play the content normally then 2) increase the contrast then 3) decrease the brightness. Please take a look and validate. It might be necessary to check with Florian and ascertain what the correct behaviour should be, but in any case there should be some change in the contrast metadata secton (it's very visible on the Dune) and there is none with JRVR, which only reacts to the brightness data.

3) DV Metadata is not detected when playing a DV title ripped to BD Folder, whether you use full menus or title playback. It only works with a DV file. Unless there is a technical reason for this, please could you correct this so that we get the DV metadata with BD Folders?

4) Not a bug but a suggestion, there doesn't seem to be any option in the JRVR HDR settings to enable/disable DV metadata processing, unlike with HDR10+ data. Given that, as far as I know, JRVR is unable to process the FEL, it migh be a good idea to provide an option to enable/disable DV metadata processing, so that if JRVR doesn't process correctly the titles that need the FEL to play correctly due to poor DV mastering, we can fall back to HDR10 instead, as I'd rather have JRVR dynamic HDR to HDR tonemapping all the time than wrong DV processing in these cases (possibly up to a few hundred titles currently). I wasn't able to test this as I didn't have the time to rip one of my DV discs to file, but unless JRVR only uses the MEL and never takes the RPU into account when discarding the FEL, it will cause issues in some titles, for example brightness fluctuations in the opening sequence of Saving Private Ryan or one frame red flashes in the opening credits of Halloween (there are many others, but these two are easy to test and VERY visible, I spotted them right away without looking for them).

5) JRVR with HDR passthrough drops frames depending on the nVidia driver. I've already reported this and discussed this with Hendrik in another thread. This happens with the latest nVidia driver, it happened at some point in the past, was resolved, then started again. I had to go back to 546.65 to get HDR passthrough to play without frame drops. Whenever this happens with JRVR, it either doesn't happen with madVR, or it can be resolved by playing with the fine-tuning rendering settings available in madVR (CPU/GPU queues, frames presented in advance, etc). In the other thread (in the MC31 forum), Hendrik said that he was thinking of offering more settings to potentially address this if I remember correctly, any progress in this area? Although it's not directly a JRVR issue as it's caused by the driver and a temporary workaround can be to go back to the last known working driver, this isn't a long term solution. I see that quite a few people are posting about issues in HDR passthrough with JRVR, both here and in other forums, so it's not just my rig.

Not a bug but praise: the HDR to HDR tonemapping works great and really helps on my display (peak 1,000nits) with high nits content, especially demo material such as the 10,000nits demo clips in the S&M UHD Bluray test discs. With such a high nits peak, it helps less often with real content as most content is mastered to 1,000nits, but I'm sure it still helps in the brightest titles. I need to do more testing, but at least with the S&M 10,000nits demo material (even the 2,000nits HDR10 version) the difference is siginificant, so if bug #1 and #2 could be resolved, it would definitely be my prefered way to watch HDR content on my display. I can imaging how helpful it would be with lower nits displays, for example projectors or even older OLEDs with less than 600-800nits. Given that JRVR has, unlike madVR , also resolved in MC32 all the brightness stability issue that I reported in MC31, it's a great option to have, so thanks for all the good work!

Thanks for listening and taking the above into consideration or providing info if I got anything wrong. I'll post back some more info when I've had a chance to do more testing with DV files or if I find anything else as I do more testing.

I'm just getting done fixing everything. It's taken me 9 hours to fix and I'm not even sure if it worked. I fixed everything once and then backed up in JRiver, shut down JRiver, reopened it, and all the playlists were deleted again. I had to refix everything a second time which took me four hours. Please help

I speed read all of the above and didn't catch this being mentioned...

The work you're doing on these playlists... Is it being carried out on an MC client by any chance?

The only work I do on my playlists is in JRemote and JRiver MC 32.

Thank you. Sorry I didn't understand the first time. Turning DSD bitsreaming on solved the problem, and after testing, all file types now play at the correct bitrate automatically. Really appreciate your help!

No, setting Output Encoding to DSD encodes everything including PCM to DSD and you're even converting DSD to DSD too. All conversions involving DSD is a lossy conversion. So it's best to avoid that unless that's what you want to do.

Anyways you should set Output Encoding back to None in this case. In MC's Options > Audio below the Audio Device section there's a Bitstreaming option, and it should be set to DSD. If it says None then that means DSD bitstreaming isn't enabled and there's your problem. Here's an image with the option highlighted in a red box (taken from Windows but the option is there regardless of OS).

Thanks for all that info! Yes, the DAC supports native DSD

Well, it specifically has to support DoP (DSD-over-PCM) so it works on macOS, besides native DSD which macOS doesn't actually support. It's a bit complicated compared to Windows (and Linux). Since the Output Encoding option for DoP seems to work you can just ignore that part.

Thanks for all that info! Yes, the DAC supports native DSD, and has worked no problem with other DSD capable audio players. It is connected directly via USB to the Mac. I already had system volume at max and MC volume disabled. Setting MC volume at max gives the same behavior so I figured having it disabled was simpler. I had already poked around in the forums and heard about disabling Integer mode as a possible fix, but that didn't seem to make a difference for me when I tested it earlier today.   

I've now set Midi setup to max, and also set Output Encoding to DSD in DoP, I think that's what you meant by making DSD bistreaming enabled, yes? That does get DSD playback working natively on the DAC, sorry, I should've mentioned I'd tried that earlier. But if I set it that way, all my PCM files seem to get upsampled to DSD instead of playing at their native 24/96, 24/192, etc., bit rates. Is there a set-it and forget-it option where I can just switch between all my various formats without having to dig around in sub-menus and adjust parameters before playing certain types of tracks? I guess I could also go back to just playing DSD with a different program, but it would be nice to launch one app and have everything play as it should. MC is so powerful and has so many features, seems like it can do anything, if a user can just figure it out

Thanks again!

CoreAudio is the driver and part of macOS, it can't be turned off. I meant make sure it's not set to the (Default) (CoreAudio) as that can cause issues. But looking at the images it looks like that's fine and set to the HD-DAC1.

How's the HD-DAC1 connected to the Mac? USB? I've looked at the manual and it doesn't mention if the HD-DAC1 supports DSD via DoP, which is required for macOS as native DSD output isn't possible. I'll assume it does, hopefully.

Generally there's a few things required to get DSD playback working on macOS.

1) Open the MIDI Audio Setup app and set the output to your DAC and set it to the highest bit-depth and sample rate. This is required by a lot of DACs to get DSD output working.
2) Make sure DSD bitstreaming is enabled under MC's Options > Audio. This is needed otherwise you'll see this behavior of converting DSD to PCM and outputting that.
3) Make sure both system volume and MC's volume is set to 100% otherwise it won't work or you'll hear just noise.
4) Use USB or DLNA (maybe ethernet too, not sure if that works on macOS). It won't work if it's connected via HDMI though.

If all else fails, you can try unchecking the integer mode option (which is in the second screenshot you posted above).

I would definitely agree that the scrollbar thumbs in particular do not behave like other images. But...

...that doesn't mean you cannot get a perfectly rounded ends, as demonstrated in the attached pic showing the default and mouse-over appearance (this is yet another thumb variation I have in addition to the two shown in my prior posts).

It is definitely not a crap-shoot… you just have to know how to apply certain tricks and use the right image parameters.

I think we solved part of the issue.

I wasn't aware that there is a Library folder in my user folder, because it's actually hidden (as it's supposed to, I've learned from a Google search).
I managed to access it, and indeed there "J River/Media Center 32" was present, meaning that the remove command probably didn't delete it (which is weird in itself).
After having deleted the Media Center folder manually and reinstalling MC 32, finally the Media Center window popped up asking me for my license.

However, after restoring my license, the program instantly crashed again.
I replicated the process (removing Media Center 32 from ~Library/Application Support/J River and afterwards from the bin, reinstalled MC 32, restored the license) and it still crashes (crash report attached).
Again, permissions are all in order, antivirus is disabled, and connections are allowed through Firewall.