View Full Version : new submux gui

nick ctrl
19th February 2002, 21:16
Here is a new win32 submux gui. It is fairly simple to use.
just check the about box to have a simple help.

one remark : the output file has the same name as output file with -subs appended to the name.

your comments are welcome.

19th February 2002, 23:36
where? :rolleyes:

21st February 2002, 15:07
You should also test my older gui....

22nd February 2002, 14:03
I download the submux.zip and run the exe file.....

It doesn't work because I don't know what is the submux path !!!!

Which file in .exe i have to put !!!!!

TKS for your help

See U swallow:devil:

nick ctrl
23rd February 2002, 01:18
You have to select the submux.exe which is for example in the dvd2svcd/submux directory if you have installed dvd2svcd.
Otherwise submux is available from dvd2svcd's site.

nick ;)

23rd February 2002, 09:43
Ok thank you man, now is working....

But once i mux the file + sub when i try to red it it i cannot see any subtitle...I play the cd I burn with a standalone player and nothing...I have a pionner DK444 and I cannot choose the option subtitle why ?

Do U have any ideas ?

TKS for your help again..

See U swallow:devil:

nick ctrl
23rd February 2002, 22:35
just go to www.vcdhelp.com to check if your dvd player can handle svcd subs.

if svcd subs doesn't work, try to generate some cvd subs ... it may work better

25th February 2002, 09:17
Is there some kind of bug in subrip or something?
Whatever i do it keeps checking PAL in the svcd designer config(output format) window. If i select NTSC as framerate, click ok and go back, pal is checked again :confused:

So the final output .sub file says
# GENERATED BY SUBRIP 0.97b on 2/25/2002 3:54:39 PM
CONTRAST (0 15 15 15)

Even when i selected NTSC.
I guess it is safe to edit the .sub file and change PAL to NTSC.
But stil....

And your gui says i can select svcd and/or cvd.
Does that mean i can select both so i will have the same subset in SVCD and CVD format on the svcd? (a dvdplayer wont be 'confused'?)

Another Q:
How much extra bits do each subtrack take? I have read somewhere (long time ago) that it is about 50kbit.. so that means i should lower my max bitrate with 50.
But does anyone know the 'real' value?

25th February 2002, 13:05
*I THINK THAT* submux do not use the framerate, but just time (hours:minutes:seconds:centiseconds), so the information in the header is just ignored... More than that, the header GIVES ERRORS, submux says that there are some subs (there are not actually subs, but the header entries) that has been ignored.

So if you edit the .sub file, you can change to PAL or to NTSC or to anything you want or even you can delete that lines; for submux everything will be the same.

And about bitrate, the short answer is that you cannot easily know what the bitrate will be; if you use CBR ath the maximum bitrate allowed, you must make it a little lower (50 seems a good number); if you use VBR and your average bitrate is 200 or so lower than the maximum, probably you can just ignore the subtitles in the maximum bitrate consideration (with very bad luck, perhaps you will have a momentary "stutter" in players with very tight tolerances, and no problem at all in most players)

And the long answer is that the subtitles DO NOT use a "bitrate" that can be easily taken into account... the subtitles are simply images that appear at definite positions into the stream. If in that position the (variable) bitrate is low enough, it will work, if not, the player will "stutter" and very shortly after that it will work again.

If at some point you include a subtitle, submux will take the corresponding .bmp, compress it into an mpeg still and insert it into the stream. If the bmp is big, the mpeg still will take many bytes and the information to be read from the disk at that point (and so the "local bitrate", to give it a name) will be greater. But how much greater, is no easy to answer. And if you use VBR, you do not really know what the bitrate will be at that precise point!

Also, you must take into account that the bitrate is not measured in each byte; the MPEG stream defines a buffer, and the maximum bitrate allowed is in fact the maximum bitrate measured whenever the buffer is filled... so, if the bitrate is higher than allowed in an specific byte but is lower before and after so the information needed fits in the buffer, the "effective" bitrate is low enough to decode the stream... In fact, the bitrate that the standard limits is NOT the "bitrate in a point", but the "bitrate in a buffer". Many people says that a MPEG file is not compliant because this or that tool said that the bitrate was too high, but in fact it is is you take the buffer size into account (that is what TMPGenc et al do to calcultar the bitrate).

The subtitles augment the information at a very precise point (they insert there an "I" frame that has the .bmp's resolution and that is just 2 bit color deep, so there is much smaller than a regular 480x480 true color I frame). To calculate the new "effective" bitrate, you must take the portion of the stream that has the lenght of the buffer, includes the subtitle and represent the shortest time possible; you divide the buffer lenght by the time and that is the maximum bitrate; if it is lower than the maximum specified in the standard, is OK, if not, the stream is non compliant. As you can see, the process is very difficult. If your average bitrate is low enough, you can hope that there will be no problem. For example, let's suppose your average bitrate is 2000 and you use 128 for audio, so the maximum is 2600. If the subtitle goes to a point in which the bitrate is very near 2600, bad luck: it will be non compliant and, if the player has very tight tolerance, it will stutter. But since your average bitrate is much lower than the maximum, you can hope that in every point at which you insert a subtitle, the bitrate will be low enough to not go over maximum. Or that the player will have a tolerance that allows that very little off-spec. Or that the stuttering will be so short that it will be almost imperceptible.

So, my advice: if you use CBR, keep it at least 50 (to say a number) under the maximum (so, for 128 audio, use 2550 as CBR instead of 2600); if you use VBR, you can decrease the maximum bitrate by 50 or, if average is at least 400 below maximum, you can simply ignore the subs and hope everything will be OK, you have a very high probability of that to be true.

25th February 2002, 23:10
Thanks for your big explanation. :)