Muxman and Scenarist colours

[MomoNyo]

I'm trying to add some subs to a DVD here using MaestroSBT to generate Scenarist subs and MuxMan to mux the subs, video and audio all together.

Regardless of what tweaking I try with the sst file, I can't get the subtitles to display the correct colours. The bitmaps generated by MaestroSBT have the correct colours (white text, black outline, grey antialias, red background), but even when I try changing the colors and contrast entries in the sst file, I can't get the outline to display. It's hard to tell, but I think the antialias is appearing OK.

I've also tried the Subtitles Creator tool to generate Scenarist subs direct from an SRT (although it doesn't support antialiasing) and even with it's output there is still no outline.

I've given up on using SUP format for the subs as all my attempts ended up with butt-ugly subs. So I'm really hoping I can crack this Scenarist problem.

I'm guessing it may have to do with the default colours that MuxMan uses when it imports Scenarist subtitles (AFAIK in Scenarist you get asked for the colour conversion values when creating a project).

[stickboy]

Muxman always uses its own default set of colors.

You can use IfoEdit to edit the subtitle colors on the IFO file that Muxman generates.

[MomoNyo]

Originally posted by stickboy
Muxman always uses its own default set of colors.
Are these listed anywhere? I've gone through the MuxMan threads but couldn't find them. I can get the font face to display correctly by editing the sst file, just really want to get the outline to show.

As for editing with IfoEdit, assuming I need to change 4 colours (outline, antialias, font and background) to match my bitmaps, are these always the first four colour values in the IFO? If so in what order do they appear?

UPDATE

Well, I've noticed that no matter what I set the Color Keys to in MaestroSBT (which determines the colours rendered in the bitmaps), it still writes the same color values into the sst file (3 2 1 1).

After much screwing around I worked out the numbers and corresponding colours in MuxMan (in my case 3 9 4 2 equals a black outline, grey antialias, white text and red background) but the vob output still refuses to display the font outline. And with white text you really need an outline. Changing the font colour to another colour (like yellow) doesn't work either as the colour is patchy (as if it's adding white antialiasing).

[Mirx]

I'm suffering exactly the same problem. After trying and trying and trying, I think I finally found something when looking at the scripting part of Muxman.

I think it has something to to with this statement:

Any color in the bitmap that does not match Pa, E1, or E2 will be coded as BG.
rules specify how to compare the color values, and may be "<", "=", ">", "&", or "x" as in Scenarist, along with "<=", "!=", and ">=". Supported synonyms are "and" for "&", "=<" for "<=", "<>" for "!=", and "=>" for ">=".

I think Muxman might be reading the E1 and E2 values in wrong, this will cause the compare to fail, hence it will see it as BG which has a transparancy of 0.

If I look at the save script I do see all the correct values there, so white-blue-black, but I just don't know if the reference is right for the compare rule.

Would setting the compare to Color 3(E2)=000000 = = x instead of Color 3(E2)=000000 = = & make any difference?

I will try swapping the values around to see if I can get it to work.

Also, is there anywhere in the VOB itself I can see the values of a subtitle track. I've gone through it with VobEdit, but can;t seem to find the references Muxman makes, like transparancy, and which clut color it uses.

[mpucoder]

There are a lot of sub ripping programs that just don't get the values right. And I made allowance for one (SubRip) in the sst import, but it's time that things got fixed. Muxman reacts the same as Scenarist to the conversion rules, and even though there is a rule for BG, what do you think all the colors that do not match become?

Anyway, for most situations the conversion rules should be = = =
The color and rule 000000 = = & will not match anything.
Scenarist default colors are white (ffffff) for BG, black (000000) for Pa, red (ff0000) for E1, and blue (0000ff) for E2. So if the bitmap has these colors (and SubRip does not) the rules are:
Color 1(Pa)=000000 = = =
Color 2(E1)=ff0000 = = =
Color 3(E2)=0000ff = = =

In order to see what is in the vob you have to look inside the subpicture units themselves. The values are stored in a series of commands that follow the pixel data, so there is no fixed offset.

edit: note also that SubRip and others get the names of the colors wrong, and the order of the colors in the color and contr statements wrong. Probably because Scenarist used confusing names. In Scenarist color 4 is BG, but has the pixel value of 0, color 3 is PA, but has the pixel value of 1, etc.
Muxman reverses that so that the color number and pixel value are the same.

[Mirx]

Of E1 and E2, which should be the outline?

I'll generate 2 sets of new BMP's, with E1 and E2 switched, as I'm not sure which is which, and post them along with the script code and muxing results later today.

[Mirx]

After some more testing, I can only come to the conclusion that's a Muxman problem.

Black, Red, Blue, White

BMP:

Black center (PA), red anti-alias (E1), blue outline (E2), and white background (BG)

http://img101.echo.cx/my.php?image=zrbw00012jt.png

Muxman generated script:

File=.\zrbw_0001.bmp
Start=00:01:24:22 (2122)
Forced Start=No
Time Code=PAL
Duration=00:00:01:01
Origin=0,0
Display Area=0,2,719,574
Color 1(Pa)=000000 = = & Black, like the input. So .bmp is read correctly.
Color 2(E1)=ff0000 = = & Red, like the input. So .bmp is read correctly.
Color 3(E2)=0000ff = = & Blue, like the input. So .bmp is read correctly.
Color=3 2 1 1 CLUT mapping, so doesn’t matter.
Contr=15 15 15 0 Transparancy is set to 15 for everything except background.

Results:

Output will only show the outlining.

This is also mapped to CLUT index 3. This means the blue outline matches E2, and that it’s the only colour that is accepted. This is because it will AND ff and ff which doesn’t give a 00 output. For the other values it will AND 00 and 00, which gives a 00 output, which will make the statement false. Hence PA and E1 aren’t mapped.

If I set background transparency to 15, PA and E1 will also be background, which supports the above conclusion, because any mapping that fails is considered background.(like you also stated here and in the mxp examples on yur website)

If I set commands to = = =, then all mappings work, and the output is correct.

Black, Blue, Red, White

BMP:

Black center (PA), blue anti-alias (E1), red outline (E2), and white background (BG)

http://img101.echo.cx/my.php?image=zbrw00017ta.png

Muxman generated script:

File=.\zbrw_0001.bmp
Start=00:01:24:22 (2122)
Forced Start=No
Time Code=PAL
Duration=00:00:01:01
Origin=0,0
Display Area=0,2,719,574
Color 1(Pa)=000000 = = & Black, like the input. So .bmp is read correctly.
Color 2(E1)=0000ff = = & Blue, like the input. So .bmp is read correctly.
Color 3(E2)=ff0000 = = & Red, like the input. So .bmp is read correctly.
Color=3 2 1 1 CLUT mapping, so doesn’t matter.
Contr=15 15 15 0 Transparancy is set to 15 for everything except background.

Results:

Output will only show the E1. Again this is due to the generated Muxman rules.

Conclusion:

Muxman generates the rules as = = &, while they should be = = =. Hence subtitle mapping will go wrong. This can be reversed manually by saving the project, replacing = = & with = = =. But this shouldn't be an manual action.

Also I've noticed that muxman does read the values correctly from the .bmp, no matter in what order you import them, it's just that the rules get generated wrong.

[mpucoder]

You are right, those rules will eliminate 2 colors. But what is the original script. Is it .scp or a .sst?
If you are not sure where the information comes from originally look in the muxman log (by default c:\muxman.log) for the line "Opened script file ..." and/or "Opened sub 1 file ...". Then examine that file.

[Mirx]

I'm importing a MaestroBST generated .sst.

These are the format lines from the .sst

st_format 2
Display_Start non_forced
TV_Type PAL
Tape_Type NON_DROP
Pixel_Area (0 573)
Directory .
Subtitle final_80
Display_Area (0 2 719 575)
Contrast (15 15 15 0)

#
# Palette entries:
#
# 01 : RGB(255,255,255)
# 02 : RGB(127,127,127)
# 03 : RGB( 0, 0, 0)
#

PA (0 0 0 - - - )
E1 (255 0 0 - - - )
E2 (0 0 255 - - - )
BG (255 255 255 - - - )


SP_NUMBER START END FILE_NAME
Color (3 2 1 1)

Is there anything in here I should swap around/alter then, to get the Muxman commands to generate correctly?

Normally scenarist has no problems whatsoever with .sst files generated in this way.

[mpucoder]

Looks like there is a problem. Muxman is supposed to treat the minus sign as an equals sign, but the last one is not translating correctly.

[Mirx]

I tried changing the rules in the .sst instead of - - -

= = = gives me = = & on muxman import
x x x gives me x x & on muxman import
>= >= >= gives me >= >= > on muxman import
!= != != gives me != != & on muxman import

I'm adding a custom subtitle track to a existing disc.
For me it doesn't matter that much anymore, as I now found that the .sup files ripped by VObEdit and my MaestroSBT generated .sst have E1 and PA inverted, so I need to alter the .mxp file to compensate the CLUT mappings anyway.

[mpucoder]

version 0.14d fixes the parsing of MaestroSBT sst files. The problem was the blank following the last rule. On sst files used for testing there was no blank, which caused the closing parenthesis to become part of the last rule's string. To fix that the parser removed the last character of the string. Of course with the blank there that's not necessary, and the equal sign got removed.
Anyway, fix should be online at Muxman homepage (http://www.mpucoder.com/Muxman/) by the time you read this.

[Mirx]

Now that's some fast support. :D I'm almost used to it from Dimad, but it's far from the "standard".

So props for the fast fix. :thanks:

[Mirx]

Just tested it. Works like a charm.

As for color mapping, I can now just change that in the .sst, which removes the need to play around with the .mxp files.

Again, thanks for the quick fix.