Print

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

[bblue]

Somewhere around MC 19.158 to 160 I had made changes to the audio configuration for video files (m2ts, ts, etc) and separately for ISO mounts of (neutralized) BluRay disks which would basically mount the iso image and let MC take it from there.  It was working, for AC3 and DTS soundtracks, but I had to use bitstreaming for one and not the other.  Make sense so far?

I tried to watch some video with MC20 a couple of nights ago and there was no audio at all on any format.  MC would fail with the not so revealing error message "Something went wrong with Playback".  Is there a way for you to possibly add some more information to that error message to at least localize what it thinks is wrong, like bit depth error, sampling rate error, mismatched decoder, etc.?"  That would be a great help to minimize trial and error troubleshooting.

Anyway, Through a lot of trial and error I found that I needed to select my HDMI Nvidia Wasapi output to get any output routed through HDMI (there were other HDMI choices too).  Using bitstreaming I could then get correct audio for AC3 format only.  Got the same error for any BluRay.

My audio input is a Meridian digital control unit and has the smarts for AC3, DTS and several other decoders built-in.  But all the BluRay's are said to be Master DTS at 48k or TrueHD at 96k (according to mediainfo).  I tried different bit depths but nothing makes any difference.  THE only configuration that works for both AC3 and DTS right now is setting MC DSP to output Dolby AC3, and expect the input format 5.1 through JRSS processing.  It works, but means another lossy conversion for both AC3 and DTS.  The TruHD BR's don't work at all, period.

Could this behavior have anything to do with any recent changes in MC?  Or perhaps some limitation to the NVidia HDMI driver?  It seems to behave much the same way on the S/PDIF output, which would seem to take HDMI out of the picture, unless at a driver level the NVidia driver is still somehow involved, or perphaps MC just thinks it is.

I'm almost positive I used to be able to get native BR out to the Meridian via HDMI, but not 100% positive.

Am I missing something?

[fitbrit]

Using nVidia video card going to Onkyo receivers, I'm not having any issues with decoding or bitstreaming and Dolby or DTS formats, including lossless.
I sometimes get the same error message when I forget to change zone, and try to play a video to a DLNA audio only zone.

[bblue]

Fortunately, in this case there's only one playback zone for audio and video.  Audio playback continues with no problem, and AC3 works fine for video with bitstreaming enabled.

But audio from a BR *immediately* produces the "Something went wrong with playback" message when in bitstream mode, which suggests to me that it isn't even a driver or hardware issue, but something else that MC is seeing that makes it think there is an incompatibility.

I'll keep looking.

[6233638]

Not that this helps with your problem, but you shouldn't be bitstreaming with HDMI anyway.
Bitstreaming prevents Video Clock from working, which means that you are compromising video quality for the sake of a light switching on, on your AVR.

[glynor]

Not that this helps with your problem, but you shouldn't be bitstreaming with HDMI anyway.
Bitstreaming prevents Video Clock from working, which means that you are compromising video quality for the sake of a light switching on, on your AVR.

+1

[bblue]

Not that this helps with your problem, but you shouldn't be bitstreaming with HDMI anyway.
Bitstreaming prevents Video Clock from working, which means that you are compromising video quality for the sake of a light switching on, on your AVR.

Do you actually believe that?  First, I can't see any lights from seated position.  However, I CAN hear the lossy re-encode to receive (almost) the original audio source from the video.  I also don't need Video Clock adjustment (except on a very rare occasion like convert 25fps to 24fps or similar), since I can let madVR do all the major pull-down and sequencing changes when necessary and feed the result to my video processor which takes care of everything else.  Net result is 1080p at 24-60fps at the projector.

I want to hear the original audio payload, unmodified, kept entirely in the digital domain when it reaches the speakers (which are also digital), that means bitstreaming to avoid Dolby re-encoding at MC's output.

How else would I accomplish that?

[6233638]

Do you actually believe that?  First, I can't see any lights from seated position.  However, I CAN hear the lossy re-encode to receive (almost) the original audio source from the video.

DTS-HD or TrueHD to LPCM is a lossless process.
The Dolby Digital Encoding option is for S/PDIF connections which can only handle 2 channels of LPCM.

I also don't need Video Clock adjustment (except on a very rare occasion like convert 25fps to 24fps or similar), since I can let madVR do all the major pull-down and sequencing changes when necessary and feed the result to my video processor which takes care of everything else.  Net result is 1080p at 24-60fps at the projector.

Video Cards do not output an exact 100% stable 24/1.001 refresh rate. (or any refresh rate for that matter)
madVR's Smooth Motion feature is for displays which cannot handle 23/24/50Hz signals.

If you are not using Video Clock or Smooth Motion, you will have dropped/repeated video frames or presentation glitches during playback.
Hit CTRL+J during playback to display madVR's stats. (check at the end of a movie for example)

Note: you should reset this at the beginning of playback (CTRL+R) since there are often dropped frames right at the very beginning, which are unrelated to this. Seeking, pausing and resuming, may also introduce dropped frames.

[bblue]

Fortunately, in this case there's only one playback zone for audio and video.  Audio playback continues with no problem, and AC3 works fine for video with bitstreaming enabled.

But audio from a BR *immediately* produces the "Something went wrong with playback" message when in bitstream mode, which suggests to me that it isn't even a driver or hardware issue, but something else that MC is seeing that makes it think there is an incompatibility.

I'll keep looking.

I have found the problem with bitstreaming BR content.  Here are some points:

1. The encoded data on the BR is arranged in two 16 bit 48k or 96k streams on the disk.  Mediainfo occasionally reports them as 24-bit tracks, but when MC correctly shows 16-bit in and out in the Audio Path display it's working fine.  If it shows anything else, it's not working.

2. so far, at least, In every case I've found that the problem has to do with MC seeing a 24 bit input from the disk.

3. The Bitstreaming options are: Dolby Digital (AC3), Dolby Digital+ (E-AC3), Dolby TrueHD, DTS, DTS-HD, DSD, SPDIF, HDMI

4. If you select all of the options in Custom (above), it will select HDMI.

5. If you select HDMI, it will select all the sub options except DSD.

6. If you select S/PDIF it will select just the basic AC3 and DTS subs, and the data stream from the DVD will be seen as 16-bit most of the time.

7. You must also disable the first DSP function Output Format in most cases.

Some of the resulting behavior will vary based on audio driver used.  The above selections seem to control only the manner of processing the stream, via bitstream.

For example, with S/PDIF selected (regardless of the real output mode of the driver) the stream is treated as 16-bit from input to output.  All BR whose main audio is DTS MA will pass through to the AVR for decoding perfectly.  However, NO secondary audio track will play.  All you get is noise from the signal not being able to be properly decoded by the AVR.

But any non-BR AC3 plays just fine, and indicates the proper mode on the AVR.  ... most of the time.  What affects this I don't know.  Some times they work, other times they don't -- with the same config and drivers.


It appears that there is some problem with the selecting the proper bitstream mode for a given playback.  But in all cases, MC should be able to transport the source image, AC3 or DTS (I'm not sure if it can do TrueHD at all), or if it can't, give us a specific error condition and/or select the next set of Audio tracks that it can deal with.

I set up a duplicate system (my audio DAW) with extra S/PDIF (HiFace II) output to another Meridian AVR placed so I could see what it thinks it's receiving.  That helped a lot sorting some of this out, but it still is inconsistent with the Theater system which uses the same type of AVR, and handles all these formats in other software players through the same hardware.  And I can easily switch between compatible sound tracks with no issues.

Can anyone shed light on how these things interact so profoundly, and how to get a correct passthrough for these various formats?  Are these bugs, oversights, or what?  Why must there be (apparently) so many options and oddities such to send the data through untouched?

Thanks for any additional insight or suggestions.

[bblue]

DTS-HD or TrueHD to LPCM is a lossless process.
The Dolby Digital Encoding option is for S/PDIF connections which can only handle 2 channels of LPCM.

Right, but I seem to have very few (L)PCM BR's.  They're either AC3 or DTS-MA, both of which are encodes which I need to transport to the AVR as-is.

While I do have a couple of different drivers to use, the NVidia HDMI driver seems to also enable the S/PDIF output.  The HDMI is stripped off in the video processor and I can select that natively for output (via S/PDIF) to the AVR, or at the AVR select it or S/PDIF directly from the HTPC.  So far as I've seen, they behave identically.  What you're saying, though, suggests that they shouldn't.

Video Cards do not output an exact 100% stable 24/1.001 refresh rate. (or any refresh rate for that matter)
madVR's Smooth Motion feature is for displays which cannot handle 23/24/50Hz signals.

This may all be corrected in the Video Processor.

If you are not using Video Clock or Smooth Motion, you will have dropped/repeated video frames or presentation glitches during playback.
Hit CTRL+J during playback to display madVR's stats. (check at the end of a movie for example)

Much to my wife's chagrin, I do check the stats frequently.  I have not noticed any frame drops or presentation glitches.  Smooth motion is off (I'm pretty sure, will check again tonight).

[glynor]

Right, but I seem to have very few (L)PCM BR's.  They're either AC3 or DTS-MA, both of which are encodes which I need to transport to the AVR as-is.

No, you don't.

LPCM is decoded, lossless audio.  It is a WAV file.  That's what the chip in your AVR does with it, once it receives the AC3 or DTS-MA.  Extracts it from the AC3 or DTS or whatever container and makes it into LPCM.  So, by decoding within MC, you are only using MC's decoders (which are almost certainly smarter, and more resilient, frankly) rather than the $0.30 ASIC chip in your AVR to do it.  Then it is sent as multichannel LPCM across the HDMI.

There is no additional lossy conversion when using MC to decode the audio rather than your AVR.  And you gain the benefit of MC's smarter Volume control, and the video features referenced above.

If you are using SPDIF or some other lower-bandwidth digital connection to transport the audio to your AVR, then Bitstreaming might be preferred (especially in the case of multichannel audio over SPDIF, which must be AC3 compressed, so you don't want to do that twice).  But for HDMI, it doesn't matter.

[6233638]

Right, but I seem to have very few (L)PCM BR's.  They're either AC3 or DTS-MA, both of which are encodes which I need to transport to the AVR as-is.

As Glynor said, LPCM is just decoded/uncompressed audio.
If you disable the bitstreaming and encoding options in Media Center, you get LPCM.
 
Inside the AVR, DTS-HD, AC3 etc. all get decoded to LPCM.
The only difference is that Media Center does the decoding instead of the AVR. Quality is identical.

This may all be corrected in the Video Processor.

No, the video processor has no idea whether the frames it's being sent are repeated, and it can't do anything for dropped frames.
 
Without Video Clock (or an equivalent like ReClock) which requires bitstreaming to be disabled, you cannot get guaranteed 100% smooth video playback from a PC.

[bblue]

No, you don't.

LPCM is decoded, lossless audio.  It is a WAV file.  That's what the chip in your AVR does with it, once it receives the AC3 or DTS-MA.  Extracts it from the AC3 or DTS or whatever container and makes it into LPCM.  So, by decoding within MC, you are only using MC's decoders (which are almost certainly smarter, and more resilient, frankly) rather than the $0.30 ASIC chip in your AVR to do it.  Then it is sent as multichannel LPCM across the HDMI.

There is no additional lossy conversion when using MC to decode the audio rather than your AVR.  And you gain the benefit of MC's smarter Volume control, and the video features referenced above.

If you are using SPDIF or some other lower-bandwidth digital connection to transport the audio to your AVR, then Bitstreaming might be preferred (especially in the case of multichannel audio over SPDIF, which must be AC3 compressed, so you don't want to do that twice).  But for HDMI, it doesn't matter.

Thanks for the comments, guys.

Ok, that makes sense and was originally what I had expected to happen.  But configured that way, and the HDMI output device selected, MC *always* aborts the playback saying that it cannot accommodate 6 channel 24/32-bit and asks if I want to switch it to two channel.  End of path.

So is that saying that the HDMI driver is really not able to accept multichannel LPCM?  Even though in the NVidia docs it says it is.

Following that path a little further,  if the AVR has nothing but coaxial and optical (Toslink) S/PDIF audio in, and the video processor/switch can only output as HDMI to the selected device, or S/PDIF coaxial or Toslink (which is what I've been using to the AVR), then there's really no reason to fiddle with the HTPC HDMI interface anyway, since the multi-channel LPCM can't be accommodated beyond the video processor?

If all that's true, how else besides bitstreaming do you think I'd be able to pass multi-channel to the AVR?  Essentially, a different AVR would be required to handle LPCM over HDMI directly.

[6233638]

Are you using WASAPI output with exclusive mode disabled?
Have you changed the bit-depth for the device properties to something other than automatic?


EDIT: I'm confused. Are you sending HDMI audio to an AVR or not?
Are you just sending it to a video processor(?) which is stripping out the audio signal and sending S/PDIF to your AVR?
 
If it's the latter, the HD formats are probably not supported at all. You would only be able to bitstream DTS/Dolby 5.1, and would have to encode all other formats to Dolby Digital.
It's not that the HDMI output doesn't support multichannel LPCM, it's that your other hardware doesn't accept it.
 
HDMI is two-way, not one-way. You can't output a 6-channel signal if the receiving device doesn't report that it accepts a 6-channel signal.

[bblue]

Are you using WASAPI output with exclusive mode disabled?
Have you changed the bit-depth for the device properties to something other than automatic?

No, No.  I have tried Wasapi, Kernel Streaming and Direct Sound.  Doesn't seem to make much difference.

EDIT: I'm confused. Are you sending HDMI audio to an AVR or not?
Are you just sending it to a video processor(?) which is stripping out the audio signal and sending S/PDIF to your AVR?

Not, and Yes.
 

If it's the latter, the HD formats are probably not supported at all. You would only be able to bitstream DTS/Dolby 5.1, and would have to encode all other formats to Dolby Digital.
It's not that the HDMI output doesn't support multichannel LPCM, it's that your other hardware doesn't accept it.
 
HDMI is two-way, not one-way. You can't output a 6-channel signal if the receiving device doesn't report that it accepts a 6-channel signal.

Ok, that makes sense.  Though I have to wonder why the video processor/switch would say 6 channel wasn't supported, if it was able to pass it on to the selected device.  Though, the selected device (my JVC projector) could in turn be reporting 2 or 0, who knows?

I have never had any problems with other HTPC software getting the right stream through my S/PDIF output, and none of several different DVD/BR players have had a problem with the 5.1 payload via HDMI or S/PDIF.  So since we've come full circle on this, it seems like MC is not handling bitstreaming correctly for these cases.  I can tolerate decoding the first encoding that's on the disk, but don't want any further encoding.

[6233638]

Ok, that makes sense.  Though I have to wonder why the video processor/switch would say 6 channel wasn't supported, if it was able to pass it on to the selected device.

Your receiver can only do 2 channels of LPCM if you're connected via S/PDIF.
S/PDIF can only do up to 6 channels of audio via compressed audio formats. (Dolby Digital 5.1/DTS 5.1)

I have never had any problems with other HTPC software getting the right stream through my S/PDIF output, and none of several different DVD/BR players have had a problem with the 5.1 payload via HDMI or S/PDIF.

You can't send DTS-HD or Dolby TrueHD over S/PDIF.
It sounds like the issue here is that whatever player you were using automatically output the core tracks (the lossy DD5.1/DTS) rather than the HD tracks.
Since you're limited to formats which S/PDIF can handle, select that as your bitstreaming option, not HDMI.
Enable Dolby Digital encoding in the Output Format section to convert everything else to a DD5.1 stream since your setup can't do multichannel LPCM.

[glynor]

Yeah... Oh crap... You're using SPDIF.  As 6233638 indicates, this means you can send a maximum of two uncompressed channels.  For multi-channel audio, it must be compressed to AC3 (or DTS).

Enable Dolby Digital encoding in the Output Format section to convert everything else to a DD5.1 stream since your setup can't do multichannel LPCM.

+1

Only option.  But, of course, then you can't use DTS-MA or TrueHD.  Why aren't you using HDMI?  Is your AVR an older model that doesn't have HDMI inputs (or junky ones that can't handle audio maybe)?

[fitbrit]

Just in case you think these guys are lying, add a third that agrees with them. If your setup is as described, you have never got lossless 5.1, 6.1 or 7.1 sound played through your system via SPDIF, regardless of whichever player you've used in the past.

Additionally, everything works as it is supposed to in MC when it comes to audio on BR - as far as I know. This seems like a definite case of other programs making changes behind your back, and therefore failing to educate you on how audio works when it comes to compression, decoding and limitations of SPDIF vs HDMI.

[kamenoff]

Guys, I was wondering can the JR play Dolby Atmos or the new 3D sound formats. Any info/ advice will be appreciated.

[RoderickGI]

Wow. Ouch. Reading through that discussion my brain was crying out for a data flow diagram which identified (brand/model) components, inputs, outputs, and their capabilities listed. Especially this "video processor/switch" thing.

The best input on my old 1999 Sony AVR is an optical S/PDIF TOSLink, which is bandwidth limited and so I am in the same boat as you BBlue. I did a bunch of research when I set up MC and connected it to my AVR. The conclusion was that to get 5.1 channel from the PC to the AVR, everything has to be encoded to Dolby Digital AC3.

So I guess I am a fourth voice on this side of the discussion.

[6233638]

The best input on my old 1999 Sony AVR is an optical S/PDIF TOSLink, which is bandwidth limited and so I am in the same boat as you BBlue.

You might find that you have analog 5.1 inputs on it, which would let you add a 5.1 soundcard to the PC and listen to the HD formats that way, rather than replace the AVR or convert everything to Dolby Digital.

[glynor]

You might find that you have analog 5.1 inputs on it, which would let you add a 5.1 soundcard to the PC and listen to the HD formats that way, rather than replace the AVR or convert everything to Dolby Digital.

Yep.  If you have analog inputs, that would almost certainly be preferable.

I do exactly that on my old Yamaha in the basement man-cave.

[bblue]

Yeah... Oh crap... You're using SPDIF.  As 6233638 indicates, this means you can send a maximum of two uncompressed channels.  For multi-channel audio, it must be compressed to AC3 (or DTS).
...
Only option.  But, of course, then you can't use DTS-MA or TrueHD.  Why aren't you using HDMI?  Is your AVR an older model that doesn't have HDMI inputs (or junky ones that can't handle audio maybe)?

Yes, the audio system for the Theater is an older (2005-ish) Meridian series with 568v2 controller, and all 5000 series speakers configured as a 7.2 system.  Everything from the controller to speakers is digital (speakers are 96k each).  The controller has only coax and toslink digital in and just a couple of analogs, so no, no HDMI.  If I was to do the whole thing again, I don't think I would go for anything Meridian, as it is way overpriced for what it is/was and rather rigid in configuration.  BUT I don't know how successful I'd be in finding a compatible (with the speakers) all digital controller that could be slipped in place, though I haven't really looked.

So I'm currently stuck with what I have at this point.  Which means using only DTS or AC3 5.1 encoded audio sources on the BR or source video over S/PDIF.  So that's where I was when starting this thread.  Since then I've learned a few things, but I believe there are still issues with MC that make using it with this configuration a lot more unclear and difficult than it needs to be.

1. MC always tries to play the first track on the BR.  If it's not DTS or AC3, it will fail with the usual useless error message.

2. On a failure like #1, there is no way (that I know of) to restart the playback after having selected a different track for audio.  One way is to temporarily set output encoding in DSP or whatever trick might be necessary to get the playback to start in order to access the Streams selection from a right-click in the playback window and select a different audio track.

2a. Couldn't MC be a little smarter about this?  e.g. if bitstreaming S/PDIF option was set, but audio from the source was not encoded, stop and display a message to the user about audio stream incompatibility with current settings, and display a choice of streams?  Let the user select one and then play the movie?

Maybe there's even a better way to accomplish this?  But certainly there must be something better than going around in circles trial and error to find the solution.

3. MC does seem to recall the reset audio track if it was changed from default, and it usually sticks from play to play.  But sometimes for an in-obvious reason the correct track gets reset.

4. As I mentioned earlier, of all the BR's I have (not a huge amount, maybe 50, plus many rentals pass through played just once) I own only two whose #1 audio track is LPCM or TrueHD (or not AC-3 or DTS).  All the rest are using AC-3 or DTS as first tracks.  Rentals are usually played on an HDMI connected Sony BR player (nothing fancy) (but that HDMI is converted to S/PDIF in my video processor) everything just plays, 5.1 no issues.

It's only on BR rips played on MC where the problems pop up.

So is there any solution to this?

[mwillems]

2a. Couldn't MC be a little smarter about this?  e.g. if bitstreaming S/PDIF option was set, but audio from the source was not encoded, stop and display a message to the user about audio stream incompatibility with current settings, and display a choice of streams?  Let the user select one and then play the movie?

Maybe there's even a better way to accomplish this?  But certainly there must be something better than going around in circles trial and error to find the solution.

I don't ever bitstream or output encoded audio, so take this answer with a grain of salt, but it sounds to me like zoneswitch may be an answer to your problem?  Is there any reason you couldn't set up one zone to bitstream, another to encode to dolby digital, and then setup a rule that switched between them based on the source encoding info from the compression tag?

A quick test seemed to work fine here.

[glynor]

So is there any solution to this?

This was already answered, largely.

Enable Bitstreaming.  You might need to use one of the custom setups since you're doing weirdness and extracting it from HDMI (it would be easier just to use SPDIF out of your computer directly, by the way, rather than extracting it).  Either way, the only types you can bitstream are DTS and AC3/DD.

Okay, that done, now go into the Output Format DSP and enable Dolby Digital output encoding.  You may want to use a separate Zone for two-channel music so that it doesn't recompress audio from 2-channel sources (which, in theory, can be sent over SPDIF as LPCM, which would be preferable, but I don't know how this will interact with your weird extractor).

[glynor]

I don't ever bitstream or output encoded audio, so take this answer with a grain of salt, but it sounds to me like zoneswitch may be an answer to your problem?  Is there any reason you couldn't set up one zone to bitstream, another to encode to dolby digital, and then setup a rule that switched between them based on the source encoding info from the compression tag?

A quick test seemed to work fine here.

I don't think this is necessary.  MC's Output Format DSP thing doesn't touch formats that are bitstreamed (remember, the entire DSP is disabled when bitstreaming).  So those will go through "native" no matter what.

You can set the bitstreaming settings manually and pick and choose what formats to bitstream.  As I said above, though, this would be easier if you just used a SPDIF directly from your computer instead of HDMI audio and then extracting it.

I haven't read through this thread with a fine-toothed comb, though, so maybe I'm missing exactly how the audio is getting out of the PC and into the receiver.

[bblue]

mwillems thanks for the suggestion.  It's a little more than I'd want to do because I'm not the only one that might use the system.

Glynor, For all intents and purposes, in this setup you can consider HDMI and S/PDIF interchangeable.  I use both HDMI and S/PDIF output from the PC going to the video processor.  At the VP I can select which to use.  Then both the coaxial and toslink outputs from the VP go to the AVR and there I can select which I want to use.  That seems rather redundant and mostly unnecessary, I know, but I hooked it up that way to debug an obnoxious intermittent that would drop sound when watching a movie, but whenever I would try an troubleshoot it all was working.  It turned out to be a factory cold solder joint on the case mounted RCA jack for the S/PDIF output on the PC.  After fixing that, I just left things as they were.

I think your suggestion of both auto-bitstreaming for S/PDIF and at the same time enabling Dolby output in the DSP output selection would work nicely.  Thanks, I'll give that a try.

However, none of this addresses MC's limited selection of an appropriate audio track in the first place, or its error handling of the wrong type track.  Don't you think those can be improved some?

One reason I want some versatility here (besides getting a better AVR) is that often the DTS tracks (encoded or not) are a different mix that the AC3 version when both are present.  Sometimes substantially different.  The DTS versions are usually mix-exaggerated for maximum Wow and Pow, not necessarily a good, balanced and normalized mix.  I like a choice.

[glynor]

its error handling of the wrong type track.

This won't happen if you configure it the way I've suggested.  The DTS-MA and TrueHD tracks will work.  They'll just be downconverted to AC3 on output, as is required for SPDIF output anyway.

If you really want to select an alternate track (for reasons other than language selection, which is almost certainly an extreme-edge-case, and only applicable to particular videos), I'm pretty sure MC remembers which tracks are selected per video file.  So next time you play a particular file, it should "just work".

MC is designed to be able to play anything (within reason).  The error is an indication that your configuration is incorrect, not that MC chose the incorrect track to play.  Therefore, an error is warranted.

[Sparks67]

Yes, the audio system for the Theater is an older (2005-ish) Meridian series with 568v2 controller, and all 5000 series speakers configured as a 7.2 system.  Everything from the controller to speakers is digital (speakers are 96k each).  The controller has only coax and toslink digital in and just a couple of analogs, so no, no HDMI.  If I was to do the whole thing again, I don't think I would go for anything Meridian, as it is way overpriced for what it is/was and rather rigid in configuration.  BUT I don't know how successful I'd be in finding a compatible (with the speakers) all digital controller that could be slipped in place, though I haven't really looked.

You need a new receiver, that has at least HDMI 1.3a.  If you have an audio card, that has coaxial then you be limited to AC3 5.1.  Your setup reminds me of my Yamaha DSP-A1 before I bought my Denon AVR-5308.
I was restricted to only coaxial through my M-audio card from the PC.   In 2007, I can't remeber we had no HDMI video card that worked, but we could rip to the hard drive. I was doing both formats Bluray and HD-DVD (Xbox 360 player).  So, I bought hdmi cable with DVI for the video card.  Worked fine for video.  My receiver couldn't decode the True-HD or DTS-MA.  There has to be complete Hardware connection with HDMI or you won't hear it.   I upgrade to a Denon AVR-5308 in early 2008 and I could hear it fine now. 


Here is the differences in HDMI versions.   http://denon.custhelp.com/app/answers/detail/a_id/192/~/differences-between-hdmi-versions-1.1,-1.2,-1.3a,-and-1.4a%3F

HDMI 1.3 / 1.3a:
 Higher speed: HDMI 1.3 increases its single-link bandwidth to 340 MHz (10.2 Gbps) to support the demands of future HD display devices, such as higher resolutions, Deep Color and high frame rates. In addition, built into the HDMI 1.3 specification is the technical foundations that will let future versions of HDMI reach significantly higher speeds.

-Deep Color: HDMI 1.3 supports 10-bit, 12-bit and 16-bit (RGB or YCbCr) color depths, up from the 8-bit depths in previous versions of the HDMI specification, for stunning rendering of over one billion colors in unprecedented detail.

-Broader color space: HDMI 1.3 adds support for “x.v.Color™” (which is the consumer name describing the IEC 61966-2-4 xvYCC color standard), which removes current color space limitations and enables the display of any color viewable by the human eye.

-New mini connector: With small portable devices such as HD camcorders and still cameras demanding seamless connectivity to HDTVs, HDMI 1.3 offers a new, smaller form factor connector option.

-Lip Sync: Because consumer electronics devices are using increasingly complex digital signal processing to enhance the clarity and detail of the content, synchronization of video and audio in user devices has become a greater challenge and could potentially require complex end-user adjustments. HDMI 1.3 incorporates automatic audio synching capabilities that allow devices to perform this synchronization automatically with total accuracy.

-New HD lossless audio formats: In addition to HDMI’s current ability to support high-bandwidth uncompressed digital audio and all currently-available compressed formats (such as Dolby® Digital and DTS®), HDMI 1.3 adds additional support for new lossless compressed digital audio formats Dolby TrueHD and DTS-HD Master Audio™.

[RoderickGI]

You might find that you have analog 5.1 inputs on it, which would let you add a 5.1 soundcard to the PC and listen to the HD formats that way, rather than replace the AVR or convert everything to Dolby Digital.

Not wanting to hijack the thread, but yes, that is not a bad idea.

I did consider it as my Sony STR-DA50ES does have 5.1 analogue inputs, but wanted to avoid analogue inputs for the usual reasons. Also I didn't really want to buy a sound card for the HTPC as it would be redundant when I did upgrade to a better AVR, and my ASRock motherboard only has a Realtek ALC898 Audio chip. Maybe that is good enough. I will have to look into it, and maybe give it a try.

Thanks for the suggestion.

[6233638]

However, none of this addresses MC's limited selection of an appropriate audio track in the first place, or its error handling of the wrong type track.  Don't you think those can be improved some?

Media Center automatically plays the "best" track - that is, the track with the highest number of channels and the least amount of compression.
I can understand why someone may want to bitstream a lossy DTS track in preference to something like converting an LPCM or TrueHD track to AC3 though, since it might be higher quality. Perhaps that's something the dev team could comment on.
 
Assuming that you need to use a digital connection and don't have the option of using a 5.1 analog connection, the best possible solution here may be to purchase a sound card which supports DTS Connect. This should be capable of converting everything to DTS rather than AC3.
 

Not wanting to hijack the thread, but yes, that is not a bad idea.
I did consider it as my Sony STR-DA50ES does have 5.1 analogue inputs, but wanted to avoid analogue inputs for the usual reasons. Also I didn't really want to buy a sound card for the HTPC as it would be redundant when I did upgrade to a better AVR, and my ASRock motherboard only has a Realtek ALC898 Audio chip. Maybe that is good enough. I will have to look into it, and maybe give it a try.
Thanks for the suggestion.

My only concern with the on-board audio is that they can be quite susceptible to noise. It works for some people though.
The uncompressed 5.1 from a "bad" soundcard via analog connections may still sound better than a Dolby-compressed S/PDIF connection though.
 
Buying a sound card may be the cheaper option in the short-term, but long-term it may make more sense to put that money towards a new AVR.
Depends when you plan on upgrading, and how important it is to you. I will say that the effects of AC3 compression are quite noticeable to me.

[glynor]

Media Center automatically plays the "best" track - that is, the track with the highest number of channels and the least amount of compression.
I can understand why someone may want to bitstream a lossy DTS track in preference to something like converting an LPCM or TrueHD track to AC3 though, since it might be higher quality. Perhaps that's something the dev team could comment on.

I can see it too, but that's probably silly in all but the rarest of cases.

The TrueHD or DTS-MA are going to be the highest quality sources on the disc, and frankly... I'd trust MC to do a better job recompressing it to AC3 than the studios, most of the time.  At least, no worse, and in some cases, probably better.

If the discs contain an exact duplicate of the soundtrack in AC3 or DTS (which isn't directors commentary or some other nonsense), it probably is going to be an afterthought at best.  I have experience with many of the exact pro encoding suites used in the industry (and I've met a bunch of people who do this exact job, because it is a pion-level job in the industry).  I'm guessing they just feed the same source to an encoder set up to poop out an AC3 track, without much at all in the way of tweaking.  It is very unlikely that special care is taken with them, since they're going to be used by a tiny fraction of the audience (and most of the people who care about audio quality, will be using the high quality track anyway).

So...  I think, best case for older movies, they include the DD track originally created for the DVD release (which might have had special handling, back when it was made), and remaster it for the TrueHD or DTS-MA track.  For anything more recent, it is whatever the encoding suite they're using craps out, when fed the high-quality, 8/9-channel source.

In any case, MC isn't going to do a bad job of converting it to AC3.  Almost certainly an equal-to-or-better job than whatever happened to put the track on the disc.

[glynor]

Also, for the record, if you want to improve your setup to remove this hack, I'd consider:

1. Just using HDMI out and replacing the AVR with a newer model (and a cheaper one) that can take HDMI in and accept 8 channels of pristine LPCM.  MC can do essentially all the other crap the AVR or signal processor can do anyway, and usually does it better, so the AVR or video processor can just be whatever lower-end model gets the basic job done.  Spend money where it counts, on the quality of the analog side of the circuitry.

For everything else possible, at least when coming out of MC, trust MC's DSP to do a better job.  Because it almost certainly does, and if you find a problem, Matt will fix it.  For the hardware guys?  Good luck getting them to fix bugs in their Firmware or, as-likely, a recall on their mass-produced ASICs.

2. Get a high quality multichannel USB sound card or DAC and run analog out from that.  You're still letting MC handle decoding, but then you have more control over the DAC used to decode it (and the analog circuitry used within).  In this case, if you have no other sources, you don't need a receiver at all, just nice high-quality amps.

People have this vision that high-end receivers have these fancy custom-designed decoding engines that are somehow superior to other, cheaper models.  Horse pucky.  The ASICs are a commodity market, and custom developing multi-million-dollar (or billion dollar, sometimes) ASICs is NOT within the wheelhouse of these little boutique audio makers (or even the "big guys").  Even writing custom firmware is not likely for the vast majority of them.  They're buying ASICs from other vendors, and packaging them.

That's NOT to suggest that there aren't any differences in quality between devices.  Far from it!  But, by and large, the "computery" part of these devices are near-enough to the same (or based on one of a handful of commodity chips and firmware reference designs).  The differences are on the analog side, and they do exist there (though price does not equal quality, as is so-often the case).  I don't profess to be an expert on everything they do, and I'm sure a bunch of them do heroic work "adding value" to their products.

But I'm VERY skeptical to see what magic they could do to make a "better" TrueHD or DTS-MA decoder.  How hard is it to decode it to LPCM?  There's a fricking spec.  You just have to do it right.  There are chips you can buy that do it right.  That's what they do.

The "magic" if any exists, happens after the decode step.

And, I've personally seen decoders in AVRs flake out on content that MC could decode without issue.  My Denon (before the amp unit died in it) would not play the AC3 feed from my cable box properly.  It would constantly get "confused" and flick in and out of Dolby Digital mode, making it unwatchable (constant audio drop outs).  MC handles the same exact source and recordings without issue.

[BillT]

The Meridian decoders do two things that no other commercial decoder does - they decode ambisonic UHJ recordings and they do Trifield processing. These are the reasons that I keep using one. I can't see any prospect of JRiver implementing these as they are of interest to only a tiny handful of people and I'd be surprised if there were any other JRiver users interested.

I would be very happy to dump the Meridian processor and not use an external decoder at all, but it's highly unlikely to be possible.

[bblue]

Also, for the record, if you want to improve your setup to remove this hack, I'd consider:

1. Just using HDMI out and replacing the AVR with a newer model (and a cheaper one) that can take HDMI in and accept 8 channels of pristine LPCM.  MC can do essentially all the other crap the AVR or signal processor can do anyway, and usually does it better, so the AVR or video processor can just be whatever lower-end model gets the basic job done.  Spend money where it counts, on the quality of the analog side of the circuitry.

For everything else possible, at least when coming out of MC, trust MC's DSP to do a better job.  Because it almost certainly does, and if you find a problem, Matt will fix it.  For the hardware guys?  Good luck getting them to fix bugs in their Firmware or, as-likely, a recall on their mass-produced ASICs.

2. Get a high quality multichannel USB sound card or DAC and run analog out from that.  You're still letting MC handle decoding, but then you have more control over the DAC used to decode it (and the analog circuitry used within).  In this case, if you have no other sources, you don't need a receiver at all, just nice high-quality amps.

People have this vision that high-end receivers have these fancy custom-designed decoding engines that are somehow superior to other, cheaper models.  Horse pucky.  The ASICs are a commodity market, and custom developing multi-million-dollar (or billion dollar, sometimes) ASICs is NOT within the wheelhouse of these little boutique audio makers (or even the "big guys").  Even writing custom firmware is not likely for the vast majority of them.  They're buying ASICs from other vendors, and packaging them.

That's NOT to suggest that there aren't any differences in quality between devices.  Far from it!  But, by and large, the "computery" part of these devices are near-enough to the same (or based on one of a handful of commodity chips and firmware reference designs).  The differences are on the analog side, and they do exist there (though price does not equal quality, as is so-often the case).  I don't profess to be an expert on everything they do, and I'm sure a bunch of them do heroic work "adding value" to their products.

But I'm VERY skeptical to see what magic they could do to make a "better" TrueHD or DTS-MA decoder.  How hard is it to decode it to LPCM?  There's a fricking spec.  You just have to do it right.  There are chips you can buy that do it right.  That's what they do.

The "magic" if any exists, happens after the decode step.

And, I've personally seen decoders in AVRs flake out on content that MC could decode without issue.  My Denon (before the amp unit died in it) would not play the AC3 feed from my cable box properly.  It would constantly get "confused" and flick in and out of Dolby Digital mode, making it unwatchable (constant audio drop outs).  MC handles the same exact source and recordings without issue.

I guess you haven't been reading all of my post's content.  Here's what you missed:

I don't have any analog in the entire system!  The speakers are powered, fed by 96k single channel (each) digital.  The AVR controller is all digital, and as I recall has but one analog input.  The primary outputs are digital, through there are some secondary analog outs which I don't use.  So that eliminates mutli-channel analog audio cards completely, though I do have a couple that aren't used.

I've looked around at other AVR/processor systems and besides one extremely expensive Meridian, I've found nothing with all 96k digital outputs.  I've trying to avoid any analog because really good D/A conversion (x6) is pricey and not found in plug-in computer cards.  I'd have to start completely over with new speakers, AVR and processing, wiring and all, and that just isn't in the cards.

Other than that, the nicest AVR that looks like it would do everything besides have the digital outs is the Krell Evolution which does audio and video, but all I really need is just the audio side of it all.  It would need to be RS-232 or network controlled from my Crestron system, which eliminates many of them.

Anyone with suggestions?

[bblue]

The Meridian decoders do two things that no other commercial decoder does - they decode ambisonic UHJ recordings and they do Trifield processing. These are the reasons that I keep using one. I can't see any prospect of JRiver implementing these as they are of interest to only a tiny handful of people and I'd be surprised if there were any other JRiver users interested.

I would be very happy to dump the Meridian processor and not use an external decoder at all, but it's highly unlikely to be possible.

Certainly true, and I wouldn't mind getting rid of mine too.  I have no use or need for UHJ decoding or TriField processing.  To me, TriField sounds quite artificial at best.

[bblue]

This won't happen if you configure it the way I've suggested.  The DTS-MA and TrueHD tracks will work.  They'll just be downconverted to AC3 on output, as is required for SPDIF output anyway.

If you really want to select an alternate track (for reasons other than language selection, which is almost certainly an extreme-edge-case, and only applicable to particular videos), I'm pretty sure MC remembers which tracks are selected per video file.  So next time you play a particular file, it should "just work".

Yes, this does work fine.  The unintended side effect of video fps matching shows up frequently (as 62 suggested) on 23 and 25 fps movies, since the videoclock option is defeated during bitstreaming.  For some reason for movies that are at 23.976 fps, madvr sets my display to 23.97142 fps and that uncorrected differential causes occasional frame drops or repeats (usually drops).  If I set madVR to choose 24 by not specifying 23 in its permissions, there's still a differential, slightly larger.  The only way to really correct the video is by not bitstreaming the audio.  So it's really a film by film deal.

MC is designed to be able to play anything (within reason).  The error is an indication that your configuration is incorrect, not that MC chose the incorrect track to play.  Therefore, an error is warranted.

I agree that the error is warranted, but why can't a little more detail about the error be presented?  There's a lot of option interdependency that affects how much of this works, with little to no clear documentation about it.   I've been doing this AV stuff for over ten years with programming, electronics, audio and video in my professional background and still found it incredibly difficult to sort out what affects what, and where the issue *actually* lies because simply no information of the errors was supplied.  Of course, I eventually found the issues and possible solutions after hours of searching and posting on the forums. (Thank you!)  I certainly cannot be alone in this.

--Bill

[6233638]

Sounds like you are stuck encoding everything to Dolby Digital, buying a sound card which can do DTS Connect (live DTS encoding, which would theoretically sound better than DD5.1 encoding), replacing the processor with one which accepts an HDMI input, or finding an output device which can do 6x 24/96 S/PDIF connections.
 
 
Also: It was not clear at all to me that this Meridian box is only a decoder/processor, and then passes on a digital signal to active speakers.
Perhaps if you're familiar with Meridian gear you would have known that, but it sounds like a very unusual setup you have. It's no surprise that Glynor or anyone else would be unaware of this.

[glynor]

You must have analog somewhere, even if it is inside the speaker.

Otherwise, you'd only hear static.

[bblue]

Sounds like you are stuck encoding everything to Dolby Digital, buying a sound card which can do DTS Connect (live DTS encoding, which would theoretically sound better than DD5.1 encoding), replacing the processor with one which accepts an HDMI input, or finding an output device which can do 6x 24/96 S/PDIF connections.

Yeah, lucky me.
 

Also: It was not clear at all to me that this Meridian box is only a decoder/processor, and then passes on a digital signal to active speakers.
Perhaps if you're familiar with Meridian gear you would have known that, but it sounds like a very unusual setup you have. It's no surprise that Glynor or anyone else would be unaware of this.

Meridian calls it a controller, but it's actually filling the role of your typical preamp, with several inputs you can switch between, and with optional audio output.  But Meridian pushes an all-digital path to the speakers in all their high end controllers (that I know of).  It is a lot easier to deal with... no speaker cables to deal with and outboard power amps.  But as we've seen, there are limitations.

[bblue]

You must have analog somewhere, even if it is inside the speaker.

Otherwise, you'd only hear static.

Yup, inside the speaker -- assuming the power amps inside each box are conventional analog, there'd have to be a D/A in there.  I've never looked, though.

[glynor]

assuming the power amps inside each box are conventional analog, there'd have to be a D/A in there.

Sound waves are "analog" by nature (at least as compared to "digital").  They're continuous waves, not stepped.  It has to be converted at some point in the chain.  It has just moved the DA to the speakers.

[bblue]

Sound waves are "analog" by nature (at least as compared to "digital").  They're continuous waves, not stepped.  It has to be converted at some point in the chain.  It has just moved the DA to the speakers.

Yes, I know this.  What I said:

Yup, inside the speaker -- assuming the power amps inside each box are conventional analog, there'd have to be a D/A in there.  I've never looked, though.

[glynor]

Yes, I know this.

I only responded that way because you put the "assuming the power amps inside each box" qualifier.  That's irrelevant.  The nature of sound isn't digital (at least not unless you look at it at the quantum level, where everything gets all crazy anyway).  That's all I meant.

For the record... I can't say I'm a huge fan of this approach (putting the DA in the speaker).  It sounds good for the manufacturer, naturally (the cost increases, and you get lock-in).  But for the user, it sounds like a bad deal (the cost increases and you're locked-in).  And, I imagine that it is technically challenging to handle latency (each digital wire will have different latency and be decoded with slightly different timing).  I imagine you could combat this by including a shared clock in your protocol, but then you're just adding latency to the whole chain...

I don't know.  Sounds like a solution for the manufacturer's coffers.

[mwillems]

I only responded that way because you put the "assuming the power amps inside each box" qualifier.  That's irrelevant.  The nature of sound isn't digital (at least not unless you look at it at the quantum level, where everything gets all crazy anyway).  That's all I meant.

For the record... I can't say I'm a huge fan of this approach (putting the DA in the speaker).  It sounds good for the manufacturer, naturally (the cost increases, and you get lock-in).  But for the user, it sounds like a bad deal (the cost increases and you're locked-in).  And, I imagine that it is technically challenging to handle latency (each digital wire will have different latency and be decoded with slightly different timing).  I imagine you could combat this by including a shared clock in your protocol, but then you're just adding latency to the whole chain...

I don't know.  Sounds like a solution for the manufacturer's coffers.

It's increasingly common to have some kind of digital input on speakers (especially studio monitors).  I think it's because powered speakers are the norm in the prosumer world (if the amps already in the box, why not the DAC too?).  Most of the ones I've seen just take a SPDIF or AES input and daisy chain it to the second speaker so they don't need a processor in front of them at all (for stereo), although they often have an analog input option too.

There are definitely disadvantages to digital inputs on speakers, but (for stereo audio use) the practice has some technical advantages. For example, it's (in my view) the best way to implement a fully active bi-amped speaker with no end-user configuration, and it allows for all kinds of manufacturer DSP optimizations (which are becoming increasingly common on high-end speakers).  The alternative method to achieve those advantages would be to take an analog in, re-digitize it, process it, and then convert back to analog which is necessarily more expensive and has some other obvious problems.  Or you could try to do it all in analog, but that starts getting even more expensive (not just in terms of cost, but also in terms of complexity and wasted sensitivity/performance).

I'll cheerfully grant that those benefits are probably outweighed by the negatives in the multi-channel context though.

[glynor]

It's increasingly common in recent years to have a digital input on speakers (especially studio monitors).

Yep.  I know.  I have some myself.  For stereo-only studio monitors, maybe (though I'd use AES before SPDIF for sure).  I still hook mine up with XLRs, though.

I can see some limited benefits, but... I don't know.  It doesn't seem like the tradeoff is really there.

[mwillems]

Yep.  I know.  I have some myself.  For stereo-only studio monitors, maybe (though I'd use AES before SPDIF for sure).  I still hook mine up with XLRs, though.

I can see some limited benefits, but... I don't know.  It doesn't seem like the tradeoff is really there.

I'm a little biased because I spent substantial time building and setting up active speakers myself, and use JRiver to do some pretty intense DSP optimization.  Because of the "active" part, my speakers don't even work in a basic way without JRiver in front of them.  That involves only being able to use my computer as a source and needing a multichannel DAC, multiple amps, etc.  In some ways the end product is liberating, but in others it can be frustrating (I don't have a convenient way for someone to just "plug their ipod" into my system, for example).

I've often asked myself: what would it take for me to accomplish what I currently have, but situate all of the "action" inside the speaker instead of in JRiver?  The cheapest and easiest way to do it would require a digital input on the back of the speaker and a miniDSP board.  At the end of the day, I'm happy enough with my configuration (and JRiver!) that I wouldn't bother.

But all that makes me more sympathetic to manufacturers trying to market active or heavily DSP-optimized speaker systems; the easiest way to do that by a country mile is to have a digital input on the speaker.

[6233638]

Unless you go down the route of ripping out the crossover and sending 2+ channels per speaker, plus subwoofers, it seemed like active speakers - especially ones with DSP - were the better option these days.

[mwillems]

Unless you go down the route of ripping out the crossover and sending 2+ channels per speaker, plus subwoofers, it seemed like active speakers - especially ones with DSP - were the better option these days.

You'll get no argument from me, but I'm obviously pretty far out on a limb in that direction (having built a pair of washing machine sized speakers that have no internal crossover ).

[tlin1688]

Guys, I was wondering can the JR play Dolby Atmos or the new 3D sound formats. Any info/ advice will be appreciated.

I have seen report on net about this,

"MC20(20.0.17) freezy on ATMOS, when same file played with TMT6, ATMOS played ok."

he also said that in MC20, the TMT6's dll is used.

[Hendrik]

Atmos streams are not supported.