smartLabs tsMuxeR: Transport Stream muxer

[setarip_old]

@rapscallion

Hi!

Blu-ray mux with a h264 @ 19.8 gb + DTS-HD @ 2.9gb
Tsmuxer states completed successfully however at 87%, not 100%. The resulting mux is only 20.8gb when it should be closer to 23gb.

The movie plays completely but I'm wondering why the lower % and smaller file size ??

Is it possible that you selected to use only the core of the DTS audio?

[Ulf]

Originally Posted by Midzuki

We still are allowed to select and copy the text that is written on the CLI window...

That's quite obvious. Exactly what I have done. The question how to capture the information to a file. I'm trying to automate a process where I need info on the number of video frames processed.

[tebasuna51]

Originally Posted by Ulf

I have tried the following:

tsMuxeR.exe "C:\out\MUXOPT.meta" "C:\out" > "C:\out\info.txt"

but redirection doesn't work (and neither does demuxing in this case).

Works for me, demux and info.txt (XP SP3)

[idbirch2]

If you're writing a script and trying to capture TSMuxer output, you could also attach to the STDOUT stream of cmd.exe to read the current output. I wrote an AutoIt script a while ago to remux MKV into TS which does just that which may serve as a good example: http://pastebin.com/EM6Y3q54. Lines 424 - 443 show the method of launching a TSMuxer command and monitoring the output.

[quartex]

scenario: output BD using original usa video and foreign audio tracks and subs.
I noticed that sometimes subtitles don't work wells. In some points they didn't show and after some seconds I see them at super fast speed.
Usually using eac3to to demux sup and then remux using tsmuxer fix this issue. But recently I experienced this problem adding subtitles demuxed with eac3to too.
Anyone know why this happens? thanks

[laz305]

I had tsmuxer installed with mkv2vob and it was crashing when trying to use multiAVCHD. Will this one solve that problem for me?

EDIT: nm I was not ripping my BD first lol

[Ulf]

Originally Posted by tebasuna51

Works for me, demux and info.txt (XP SP3)

You are quite right. I was using "%~dp1" in a script for the output folder. That translates to:

tsMuxeR.exe "C:\out\MUXOPT.meta" "C:\out\" > "C:\out\info.txt"

which doesn't work.

[rapscallion]

Originally Posted by setarip_old

@rapscallion

Hi! Is it possible that you selected to use only the core of the DTS audio?

Hey setarip, I never got a mail re your resonse, so I'm seeing your post for the first time today. No, I didn't do just the core, but if I had, tsmuxer should complete at 100%, not 87%.

The frame count was a match to Megui's log @ 157,725 frames and I've muxed this probably 5 times already with the exact same result. So very puzzled.

I don't see anything in megui's log that would indicate a cause either (video only).

Edit: just out of curiousity, I muxed, to Blu-ray, just the video and it completed @ 100% and the same file size as the video and audio mux. So, it appears that there's something funky with the DTS-HD track that I extracted via eac3to. I'll try demuxing the audio via tsmuxer and see what happens.

Edit_1: Yes, that was it. demuxed the audio via Tsmuxer and then muxed with the video and all was 100%. Weird.

[Ghitulescu]

I am stuck again on the same problem.

I had several episodes I want to put on a single BD instead of several DVDs. It appears that no matter what I do, I either go into one problem or in another.

This case is in theory simple. All streams have a 0ms delay. Yet after muxing to M2TS the delay is set to -80ms and indeed one can sense it on HW players but also on PC.


Muxing with 0ms delay. Apparently everything went ok, because ....


Reloading again the muxed file in tsmuxergui, it falsely indicate a 0ms delay, because one can sense it during play, and of course

the exact value is mentioned by MediaInfo.


Now this is not all. As I mentioned here, it appears that in case where the delay is not 0ms but eg a positive value, the muxing procedure subtracts 80ms (or adds said -80ms, as above) from the real delay (sort of 460ms -> 380ms) and the audio is wrongly placed.

[Ghitulescu]

Originally Posted by Ghitulescu

Why does tsmuxer (used with tsmuxergui) insists in rescaling my subtitles?

Is there any hidden setting I am not aware of?

Reverting to an older version, 1.9.9, appears to cure this symptom, both in "as primary video" and in "720x576" modi.

I am not expecting that the developers will somehow remember this software (tomorrow it be be 5 years since its last update ), but at least I hope for an explanation or a good manufacturing practice.

[SeeMoreDigital]

Originally Posted by Ghitulescu

Reverting to an older version, 1.9.9, appears to cure this symptom, both in "as primary video" and in "720x576" modi.

I am not expecting that the developers will somehow remember this software (tomorrow it be be 5 years since its last update ), but at least I hope for an explanation or a good manufacturing practice.

Actually, version 1.10.6 was released on Monday 11 May 2009

[sreemv]

Any idea why tsmuxer crashes on various/several mkvs with no header stripping - on windows 7 64bit - even the cli version gives the same crash message "tsmuxer.exe stopped working"



Here is the mediainfo on the .x264 freshly enccoded via vdub:



Any help is appreciated!

[tebasuna51]

¿mkvs?
Seems a AVI 36.7 GB with h264 video.

Try remux before to mkv wiht MkvMerge.

And Level 5.0 can be also other problem, use Level 4.1

[sreemv]

Yes, figured it out by experimenting - exactly what you suggested - used mkvmerge to write mkv then in tsmuxer changed the level to 4.1 and all went well! Thanks!

[rapscallion]

Originally Posted by sreemv

Yes, figured it out by experimenting - exactly what you suggested - used mkvmerge to write mkv then in tsmuxer changed the level to 4.1 and all went well! Thanks!

You do realize that it doesn't actually change the level to 4.1, but tells the player that's what the level is ?
Which is not a problem.

[rapscallion]

As you all probably know, versions since 1.8.4b can't display subs in any color, other than white, without a greenish cast/tint.

You can, however, use v 1.8.4b (available here: Click) and substitute the executable from v 1.10.6 (tsmuxer.exe). This way all the updates in 1.10.6 are working with the older simplified gui.

[ramicio]

Is there ANY program out there that doesn't remove overlaps? I thought I could get around it by not using eac3to, but now I see that tsmuxer is doing the same thing, which is royally SCREWING UP the audio. I don't believe overlap is a problem, and most of the time when these programs "fix" this overlap, it ends up messing up the audio. The studios obviously know what they are doing, and I doubt the set-top box players just skip audio samples, so why should these programs act any differently?

[jdobbs]

Originally Posted by ramicio

Is there ANY program out there that doesn't remove overlaps? I thought I could get around it by not using eac3to, but now I see that tsmuxer is doing the same thing, which is royally SCREWING UP the audio. I don't believe overlap is a problem, and most of the time when these programs "fix" this overlap, it ends up messing up the audio. The studios obviously know what they are doing, and I doubt the set-top box players just skip audio samples, so why should these programs act any differently?

??? As I understand it an "overlap" indicates redundant/repetitive audio packets that exist in two different streams (that are being combined). So I guess I don't understand how removing it is "royally SCREWING UP the audio"... I can tell you assuredly that failing to remove it can do so.

Please explain how the audio is being negatively affected.

[ramicio]

To me, it seems like an overlap is when the audio is longer than how these programs calculate the video duration. When this happens I can hear parts of a song skip forward as if a fraction of a second is missing from it. There are a bunch of titles I've copied to my hard drive that get screwed up from this overlap removal because it will do it before it decodes the audio, so it can screw up things like .dtshd which eac3to itself is not one bit aware of, and needs a 3rd party codec to decode. If you are simply ripping a .dtshd track, it's not going to even bother looking at the audio data, it just does a demux, so it is NOT aware of redundant audio data. It introduces corruption of the audio. I can't be any more descriptive than that.

[jdobbs]

I think you have a misunderstanding of what "overlap" is... if it isn't redundant, it isn't overlap. I can tell you that the most likely way eac3to or tsmuxer decides when something is overlapped is when you have two packets falling within with the same presentation time stamp (PTS) range... indicating it is a repeat. A program doesn't have to decode the audio in order to look at the packet or frame headers.