1. RedFox is offering a Cyber-Monday discount of 20% on all products (except upgrades/renewals), valid until November 30, 2022. If you are entertaining the thought of purchasing one of our products then now is the right time to act!
    Dismiss Notice

CloneBD & TrueHD

Discussion in 'CloneBD' started by HT_Enthusiast, Oct 22, 2017.

  1. HT_Enthusiast

    HT_Enthusiast Active Member

    Want to start off the post with a big thank you to the Well-Known members that have helped answer questions through other's posts over the years, since back in the ClownBD days when you had to run EAC3To/ClownBD/IMGBurn independently.

    I have until recently been using Handbrake to convert my personal media to MKV but have recently noticed the severe loss in visual quality when watching on a large screen (120). I have recently purchased Clone BD as i was impressed with the visual quality in the trial.

    When using CloneBD - I keep the original lossless audio as my receiver and player (Shield TV) support lossless playback. DTS-HD files processed through CloneBD playback flawlessly. However when i attempt to playback files containing TrueHD processed through CloneBD (only the lossless track)- my receiver does not detect the the lossless input and Plex gets confused and tries to transcode when it should be direct-play (Plex even recognizes the mkv contains TrueHD in the details).

    When using Handbrake i have been able to pass-through the audio, and not have any issues with playback of TrueHD. (the same 2 files i'm having an issue with when processed with CloneBD play correctly when processed through handbrake)

    Is there a known issue with the way Clone BD processes TrueHD audio? Any suggestions?
  2. Pete

    Pete Forum Admin Staff Member

    I just played around with it a little - I don't have a Shield, so I can't verify that.
    Playback with PowerDVD with passthrough to my receiver worked fine.
    I tried an MKV made with CloneBD, lossless video and lossless audio (Dolby True HD Atmos, receiver showed "Atmos" in the display).

    I'll see if I can install plex for further testing. But so far no problems have been reported with TrueHD.
  3. SamuriHL

    SamuriHL Well-Known Member

    I don't believe there are any Plex clients other than the shield that can bitstream the audio. I have Plex on every device I own (roku, xbox, ps4, etc) and none of them will do it. I don't have a shield, either, but, I can say that all the MKV's I've created bitstream fine using J River MC.
  4. HT_Enthusiast

    HT_Enthusiast Active Member

    I've tried this with multiple files and it still appears to only occur with the TrueHD audio tracks. I'm not sure how handbrake is passing the audio file through differently than CloneBD.

    Since i was determined to get one working TrueHD file, i processed the same file with CloneBD & Handbrake. Had the same audio trouble with just the CloneBD file.

    So i used MKVToolNix to strip the CloneBD audio file and replace it with the Handbrake audio file as seen below:


    It appears odd that the CloneBD file appears to show 8 channels (in MKVToolNix) when CloneBD itself recognized it as a 5.1 file:


    After replacing the CloneBD audio file with the Handbrake audio file - It is now playing flawlessly, only downside is the extra time/processing involved and it seemed to add .8 GB to the final file (unsure if audio file difference or MKVToolNix overhead).

    Attaching log file in the event that yields any additional information.

    Attached Files:

    Last edited: Oct 26, 2017
  5. Fabian

    Fabian Developer

    We are investigating why a 7.1 marker is written to the .mkv file.
  6. dewd_1969

    dewd_1969 Member

    Interesting. I just assumed it was broken with a Plex or Shield upgrade. One work around I found was to use Plex for KODI on the Shield. It passes the TrueHD on to my receiver without any issue.
  7. Steve55

    Steve55 Well-Known Member

    There tend to be issues with MKV and TrueHD I have experienced, I believe because MKV container can't handle an AC3 core correctly unless it's remuxed. DTS-HD works fine but TrueHD not.

    The .8 GB difference is definitely not just some kind of overhead added by mkvtoolnix. (Maybe it's coincidence that 5.1 plus 2.0 = 7.1)
    Last edited: Nov 13, 2017
  8. HT_Enthusiast

    HT_Enthusiast Active Member

    Any update on the investigation? I'll volunteer to test any potential fixes.
  9. HT_Enthusiast

    HT_Enthusiast Active Member

    What i don't understand is when i use the "passthrough" option with Handbrake they play flawlessly (don't know the technical breakdown of their passthrough vs CloneBD's copy original (lossless) setting) - Will continue to use that workaround until this appears to be fixed in CloneBD for TrueHD
  10. Steve55

    Steve55 Well-Known Member

    It would be good if someone who understands better than me would answer. But I don't think Handbrake is just doing a passthrough, I think it is extracting just the 5.1 track to make a finished 5.1 track. The merging in TrueHD doesn't work like DTS-HD, where one track can play either the core or the complete audio. If you want the AC3 core from TrueHD in a mkv file, it must be saved as a separate track, it can't be combined with the 5.1.
    Last edited: Nov 16, 2017
  11. SamuriHL

    SamuriHL Well-Known Member

    I'm fairly sure that it's because TrueHD on blu-rays does not have an AC3 "core" like DTS-HD has a DTS core. They actually have a separate AC3 track. If you're getting 5.1 from a 7.1 TrueHD track, then it's being converted. I've not had too many issues with TrueHD in MKV containers but I don't add an AC3 track, either, as my equipment is all bitstreaming capable. I always do lossless copy into the MKV container, though.
  12. Pete

    Pete Forum Admin Staff Member

    The upcoming version (no, I don't have a release date) fixes the improper labelling of the track in the container (6 vs. 8 channels).
    Whether that fixes your problem or not remains to be seen, then.
    The information is redundant, as the proper values are in the actual audio stream, so....maybe, maybe no.
    dewd_1969 likes this.
  13. Steve55

    Steve55 Well-Known Member

    Samurai, yes exactly how I understand it and what I was trying to say! DTS has that clever difference thing so that one audio can represent both versions, which TrueHD diesnt have. Thanks!
  14. HT_Enthusiast

    HT_Enthusiast Active Member

    Thanks for the update Pete - Have a happy Thanksgiving!

    I'm wondering if the issue i'm experiencing is related to 7.1 TrueHD files processed through CloneBD can't be passed through to my Onkyo 5.1 receiver (which decodes TrueHD/DTS-HD. Will be interesting to give that a test when it passes through 6 channels to confirm.

    Still interesting that DTS-HD 7.1 will play fine on that receiver and handbrake processed TrueHD files. From the posts above, i'm convinced handbrake must be doing something to the TrueHD audio file instead of leaving it alone like CloneBD does. Thanks for all your help!
  15. dewd_1969

    dewd_1969 Member

    FWIW - I recreated Batman vs Superman with the latest beta and tested. Same deal - Plex converts the audio when playing with the Plex App on my Shield TV. It still works perfectly when playing through the Plex Plugin in Kodi.

    Tomorrow I'll try converting the movie again using MakeMKV and Handbrake.
  16. HT_Enthusiast

    HT_Enthusiast Active Member

    @Pete - I tried the latest beta build released and not seeing any difference with the audio issue i'm experiencing. When placing the lossless MKV into MKVToolNix it's still displaying 8 channels on a 5.1 TrueHD audio track (looks identical to my screenshot in post#4 of this thread). Uploaded the logfile in the event it's useful.

    Usually the difference i see between handbrake's pass-through mkv is the reference removed of the 24 bits per sample - which leads me to believe it's an issue with my receiver (3 year old Onkyo with no firmware updates). The audio file plays fine on my PC through plex - just not Shield to Receiver.

    So i have ordered a Sony STRNDN1080 to rule out an issue with an out-date receiver not being able to decode the audio track properly (Oh darn - an excuse to upgrade my receiver for Atmos/DTS X (y) ) . Will provide an update when I've been able to test on the updated hardware.

    Attached Files:

  17. Pete

    Pete Forum Admin Staff Member

    Ok, this whole thing is pretty confusing, I'll try to lay out the traps that can lead to false assumptions....

    It's hard to tell, what CloneBD actually used in this case to determine the number of channels.
    The BD comes with no less than 4 independent sources of information about any stream:
    1. stream information stored in the clpi files
    2. stream information stored in the mpls files
    3. stream information stored in the PMT of the actual m2ts files
    4. the stream data itself within the m2ts file
    The information taken from the first three sources should be identical (some, not really few, badly authored discs prove an exception to this rule).
    The information available for audio in those three is limited to:
    • actual codec (DTS/DTSHD/TrueHD/AC3/...)
    • sampling frequency
    • a rather coarse, generic classification for "channels": mono, stereo or "more than 2 channels"
    The actual audio data in the stream, finally, has all the missing elements (bit depth, actual number and layout of channels, bit rate, etc...).

    CloneBD normally, at first, displays the immediately available information from the clpi files.
    Then, later while it scans the disc and gathers snapshot images, it will usually parse the streams and replace the information.

    I know for a fact, that CloneBD used to display "5.1" originally, when the clpi file said "more than 2 channels", because at the time, 7.1 simply didn't exist or was at least exceedingly rare.
    But as soon as it starts scanning the m2ts file, the correct information should be shown.

    Now: the data in your cbdlog file really seems to be TrueHD 5.1.
    Does MKVToolNix say anything else (in case of this particular disc)?

    The next question would be, where does MKVToolNix get those details from?
    An MKV has two sources:
    1. Track description entry
    2. again, the actual audio data
    If possible, could you simply "convert" a tiny fraction of that BD to an MKV file (one second of blackness at the beginning should suffice and you wouldn't be hurting any copyright laws) and post that here for analysis?
    ErichV likes this.
  18. HT_Enthusiast

    HT_Enthusiast Active Member

    Pete, I appreciate the information - great insight. I have converted a tiny fraction for you as requested.

    Attached Files:

  19. Pete

    Pete Forum Admin Staff Member

    Thank you.
    You swear, that you made this with CloneBD That thing is supposed to be fixed, but I can confirm, that a) the TrueHD stream is "5.1" and b) in the MKV header it is flagged as "8 channels".
    What I believe is happening, is that your player sees the 8 channel flagging and refuses to pass through the audio to your receiver, because the receiver can only handle 6 channels.

    Just for fun - if you have a hex editor, you can open that MKV you posted and edit file offset hex 269 (decimal 617).
    There's the 8 for 8 channels and change that to 6. Then see if the file plays correctly.

    Or more generically: search for the first occurrence of "9f 81 08" and change it to "9f 81 06", that would work on all files.
    It would be nice to know, if it's just that.
  20. HT_Enthusiast

    HT_Enthusiast Active Member

    I swear i made that with CloneBD - double and triple checked the information icon to confirm.

    I modified the hex code as suggested (found first occurrence of 9f 81 08 and changed 08 to 06 and now when i pull up the test clip in MKVToolNix - it displays at 6 channels instead of 8.

    I followed the same action on the full mkv file which will also now display 6 channels instead of 8 in MKVToolNix. But unfortunately i don't see any difference when attempting to pass-through to my 5.1 receiver (Onkyo HT-R391). I'm still thinking it's a possible issue with the receiver processing 24 bit TrueHD files.