Selur's Little Message Board - Hybrid 2026.11.07.1 – TrueHD/Atmos extraction fails when converting Blu-ray audio to

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:

Code:
00005.mpls
Audio track ID:

Code:
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

Code:
.ac3

file. This fails.

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

Code:
git-1f5b692

) to extract the audio track.

However, tsMuxeR produces an

Code:
.ac3+thd

file containing both the AC3 core and TrueHD data.

Hybrid subsequently renames this file to

Code:
.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:

Code:
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:

Code:
drop-ac3-core

This produces a proper

Code:
.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:

Code:
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:

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

Results:

Code:
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:

Code:
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:

Code:
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

Code:
drop-ac3-core

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

Renaming an

Code:
.ac3+thd

file to

Code:
.thd

does not remove the AC3 core.

Would it be possible for Hybrid to pass

Code:
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

Code:
.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

I'll look at it.

Cu Selur

Thank you for looking into this

tamo_bln

Uploaded a new dev which hopefully fixes it.

Cu Selur

Hi Selur,

thank you very much for being so quick with a fix.

I will download the latest dev version and will run a test then.

tamo_bln