[BUG] Hybrid 2026.11.07.1 – TrueHD/Atmos extraction fails when converting Blu-ray audio to

[tamo_bln]

Hi Selur,

I'm experiencing a problem with TrueHD/Atmos audio extraction in Hybrid 2026.11.07.1 (AppImage) on Fedora Workstation 45.

Source:

• Blu-ray source
  
• Playlist:
  
  00005.mpls
• Audio track ID:
  
  4353
• Audio format: Dolby TrueHD + Dolby Atmos
  
• Channels: 7.1
  
• Sample rate: 48 kHz
  

Intended output:

• Video: SVT-AV1
  
• Audio: Opus 7.1, 256 kbit/s
  
• No subtitles
  

Problem
When enabling Config → Input → Extraction → Prefer ffmpeg for extraction from transport streams, Hybrid attempts to extract the TrueHD audio stream using FFmpeg with stream copy into an

.ac3

file. This fails.

When disabling that preference, Hybrid uses its bundled tsMuxeR 3.0.1 (

git-1f5b692

) to extract the audio track.

However, tsMuxeR produces an

.ac3+thd

file containing both the AC3 core and TrueHD data.

Hybrid subsequently renames this file to

.thd

without removing the AC3 core. This was confirmed by comparing SHA-256 hashes before and after renaming.
The resulting file cannot be processed correctly by the subsequent FFmpeg/SoX/opusenc audio conversion pipeline.

The option Audio → Misc → Automatic TrueHD to ac3 was disabled.

Successful manual workaround
I tested the bundled tsMuxeR executable directly using the following meta file:

MUXOPT --no-hdmv-descriptors --new-audio-pes --demux --vbr --vbv-len=500 A_AC3, "/path/to/BDMV/PLAYLIST/00005.mpls", track=4353, drop-ac3-core

The important parameter is:

drop-ac3-core

This produces a proper

.thd

file without the embedded AC3 core.

The complete extraction succeeded with exit code 0 and produced a TrueHD file of approximately 4.0 GB.

FFprobe identified the extracted stream as:

codec_name=truehd profile=Dolby TrueHD + Dolby Atmos sample_rate=48000 channels=8 channel_layout=7.1

Successful complete Opus conversion
I subsequently converted the entire extracted TrueHD stream using:
FFmpeg → SoX → opusenc
Opus encoding settings:

--bitrate 256 --comp 10 --framesize 20 --expect-loss 0 --max-delay 1000 --ignorelength

Results:

Input:       48 kHz, 8 channels Output:      Opus 7.1 Duration:    02:50:21.94 Runtime:     00:05:33 Speed:       30.7x realtime Output size: 269626562 bytes

FFprobe confirmed:

codec_name=opus sample_rate=48000 channels=8 channel_layout=7.1 duration=10221.927333 size=269626562 bit_rate=211018

A subsequent full decoding test using FFmpeg completed without reported decoding errors:

time=02:50:21.92 speed=265x elapsed=0:00:38.63

The manual workflow therefore successfully extracts, converts and decodes the complete audio stream.
The actual channel mapping has not yet been independently verified.

Suspected cause
Hybrid appears to be missing the

drop-ac3-core

parameter when extracting a combined AC3 + TrueHD stream with tsMuxeR.

Renaming an

.ac3+thd

file to

.thd

does not remove the AC3 core.

Would it be possible for Hybrid to pass

drop-ac3-core

to tsMuxeR when extracting a TrueHD stream intended for further audio encoding?

This would allow Hybrid's existing FFmpeg/SoX/opusenc conversion pipeline to process the resulting

.thd

stream correctly.

I can provide the relevant Hybrid debug log and additional test results if needed.

Thanks for looking into this!

Kind regards

tamo_bln