6 hours ago
Hi Selur,
I'm experiencing a problem with TrueHD/Atmos audio extraction in Hybrid 2026.11.07.1 (AppImage) on Fedora Workstation 45.
Source:
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
file. This fails.
When disabling that preference, Hybrid uses its bundled tsMuxeR 3.0.1 (
) to extract the audio track.
However, tsMuxeR produces an
file containing both the AC3 core and TrueHD data.
Hybrid subsequently renames this file to
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:
The important parameter is:
This produces a proper
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:
Successful complete Opus conversion
I subsequently converted the entire extracted TrueHD stream using:
FFmpeg → SoX → opusenc
Opus encoding settings:
Results:
FFprobe confirmed:
A subsequent full decoding test using FFmpeg completed without reported decoding errors:
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
parameter when extracting a combined AC3 + TrueHD stream with tsMuxeR.
Renaming an
file to
does not remove the AC3 core.
Would it be possible for Hybrid to pass
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
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'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
- 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
.ac3When disabling that preference, Hybrid uses its bundled tsMuxeR 3.0.1 (
git-1f5b692However, tsMuxeR produces an
.ac3+thdHybrid subsequently renames this file to
.thdThe 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-coreThe important parameter is:
drop-ac3-coreThis produces a proper
.thdThe 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.1Successful 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
--ignorelengthResults:
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 bytesFFprobe confirmed:
codec_name=opus
sample_rate=48000
channels=8
channel_layout=7.1
duration=10221.927333
size=269626562
bit_rate=211018A subsequent full decoding test using FFmpeg completed without reported decoding errors:
time=02:50:21.92
speed=265x
elapsed=0:00:38.63The 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-coreparameter when extracting a combined AC3 + TrueHD stream with tsMuxeR.
Renaming an
.ac3+thd.thdWould it be possible for Hybrid to pass
drop-ac3-coreThis would allow Hybrid's existing FFmpeg/SoX/opusenc conversion pipeline to process the resulting
.thdI can provide the relevant Hybrid debug log and additional test results if needed.
Thanks for looking into this!
Kind regards
tamo_bln

