Tsmuxer DON'T work correct....

[fits79]

I try to down-convert truehd and dts-hd into ac3 and dts and simply DON'T DO THAT.
It leave these audio streams as it is nothing convert it to...


Please fix it..


I have try the latest version 2.18.10 64bit.

[ProWo]

I try to down-convert truehd and dts-hd into ac3 and dts and simply DON'T DO THAT.
It leave these audio streams as it is nothing convert it to...

As the name says, Tsmuxer is a muxer, not a converter.
For your conversion you need another application like clever FFmpeg-GUI g.e.

[fits79]

Please BEFORE YOU POST try and read the changelog of the app.

If you have read it you see that at newer versions of the program there is an option that CAN DOWNCONVERT TRUEHD AND DTSHD...


SO....

[ProWo]

Please BEFORE YOU POST try and read the changelog of the app.

If you have read it you see that at newer versions of the program there is an option that CAN DOWNCONVERT TRUEHD AND DTSHD...


SO....

You're partly right; tsmuxer can demux DTS from DTS-HD (tested, working).

But it can't demux AC3 from a regular TrueHD stream. That only works with a TrueHD+AC3 file.

[fits79]

Never i say demux.
Again LEARN TO READ CHANGELOG....
IT CAN CONVERT DTS-HD AND TRUEHD INTO DTS OR AC3.

Just read here:
https://www.videohelp.com/software/tsMuxeR/version-history

[dietboby]

I checked, and there's a latest version; see the changelog. I highlighted an important renaming.

https://github.com/teaching-droid/tsMuxer/releases/tag/v2.18.11

tsMuxeR 2.18.11 Latest
@github-actions github-actions released this 13 minutes ago
 v2.18.11
 5b42a60
Every issue on the tracker of the original project, justdan96/tsMuxer,
has been read through and tested against this version, to see which ones are still there and which
are already gone. This release fixes the ones that are still there. The feature requests have not
been looked at yet. Defects come first.

Fixed
Joining mp4 files kept only the first one. Four files went in, one came out, and tsMuxeR
reported success and exited zero. Nothing in the output said a quarter of the film was missing.
Joining .264 or .mkv files was never affected. Five separate faults were behind it. One of
them could crash while simply reading an mp4. Another made the same command work on one file and
fail on another of a different length. Joining now gives the whole thing.

A file that opened correctly could crash tsMuxeR at random. It happened about twice in a
hundred runs on one ordinary mp4. The buffer for a frame was measured by one piece of code and
filled by another. Only one of them checked, so a bad length wrote past the end of the buffer.

Asking for a different HEVC frame rate did nothing and said it had worked. The rate was
accepted and announced in the log. It was never written into the video. Every rate now lands in
the file. This also fixes muxing HEVC with a changed frame rate producing an unreadable result.

A frame rate written as a fraction was read as its first number. fps=24000/1001 was taken
as 24000, so the disc was built at twenty four thousand frames a second. Only a meta file typed by
hand could reach it, which is exactly what a recipe asks people to write.

--cut-end was described as a trim. It is not. It is the point to stop at, measured from
the start, so --cut-end=30s keeps the first thirty seconds rather than removing the last thirty.
The help now says so. A range that selects nothing used to write an empty file and report success.
It is now refused, with both values named.

An empty output path came back as an unknown exception. A path of nothing but spaces was
accepted outright and muxed as though it were a file name. Both are now refused with a clear
message, and the underlying read past the end of an empty string is gone.

A file whose name does not match what is inside it is now refused. The name is what decides
which reader opens a file. A recording called .mpg is very often a transport stream, and it was
read as a program stream. That gave either a message about the reader's own internals, or for
several combinations a banner and nothing else at all, at exit 0. The message now says what the
file really is and what to rename it to. Correctly named files are unaffected.

A changed HEVC frame rate reached only half of the file. HEVC records its timing twice, and
fps= rewrote one copy and not the other. The file then disagreed with itself: some tools read 25
and others read the original rate from the same file. Both copies are now written.

A source with more than 64 tracks could not be opened. The limit is now 256.

Every mp4 opened leaked memory. About 13 KB per file, and once more for each file of a join.

New
tsMuxeR now says when a disc asks to be read faster than a player has to manage. A Blu-ray
drive only has to supply 48 Mbit/s, or 109 for UHD. A video whose average sits well inside that
can still ask for far more in bursts. That happens when its peak rate was never capped at encoding
time. Such a disc plays perfectly from a hard disk. On a standalone player it may stutter or
refuse to start. Nothing in the output changes. The warning names the rate and the limit.

A track that produced no frames at all now says so. The codec named on a meta line was taken
as fact and never checked against the file, so naming the wrong one was silent. A_AC3 on an H.264
stream wrote nothing and said nothing, and a video codec on an audio file wrote a file of the
expected size holding no frames and reported success. Any track that delivered nothing is now named
at the end of the mux.

The window opens where you last left it. It is put back on a screen that still exists.

Changed
The audio option called "Downconvert" is renamed, because the name can mislead. tsMuxeR is a
muxer and does not convert audio. TRUE-HD, DTS-HD and DD+ carry a plain core inside the HD stream,
and all this option ever did was keep that core and drop the HD part. It has had that name since before this project was
forked, and it suggests something the program has never done. It now reads "Keep the AC-3 core, drop the TRUE-HD part", and the same for DTS-HD and
DD+. It is also only offered where there is a core to keep. Nothing about what it does has changed,
and down-to-ac3 and down-to-dts in a meta file are unchanged.

The help for --maxbitrate no longer describes something it does not do. It said the option
sets the rate the stream is paced to. It does not pace anything, and on its own it changes nothing
at all. Its one real use is to switch on the padding that --minbitrate asks for. For a fixed
rate use --bitrate.

The macOS packaging script no longer depends on where it is run from, and the install
instructions no longer point at an address that has gone.