Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

A user recently reported that they felt our subtitle sizing was too large for text-based SSA subtitles.

Here's a comparison between MC and MPC-HC playing the same clip at 1080p (resized by 50% so it fits better here):


I don't think there's really a "right" answer on this one, but let me explain our subtitle sizing logic and we can discuss if there are any improvements that could be made.

The sizing works like this:
1) Use 9.5% of the height of the video for a normal text subtitle (this does not include black bars, unless the bars are baked into the video)
2) If the user sets the size setting, scale that 9.5% by the user setting
3) If the subtitle file uses varying sizes, pick the median size and scale all the titles relative to that

As an example of #3, the video above uses these sizes:
20, 28, 30, 40, 40, 50, 50, 50, 50

These might be point sizes or something, but they don't mean too much to us since we're rendering at varying sizes and always have pixel-perfect rendering (as opposed to MPC-HC that scales the subtitles with the video, at least that I can tell).

So we pick 40 as the normal mark (that's the median) and scale a 50 (what is shown in the screenshot) by 1.25.

The result is that the subtitle above uses 11.875% of the height of the video for each character (9.5% * 100% user setting * 125% for SSA specifier).

Is there anything that should be changed in that logic?  Should the 9.5% thing change as the video changes size?  Should it consider width as well as height?  Any other tips?

Thanks for any help.

[Neco]

I'm always a fan of compromise where possible.  I think giving us more options might be helpful?

I know that overloading the user with a bazillion options is not always a good idea,  but we have so many in so many places already.  It is kind of a staple of MC that it is so customizable?

Since I am the user in question,  I will give my opinion on the matter as well.
IMHO the font size is too large.   To get a similar font size as shown on the MPC-HC image,  I would have to tell MC to scale to 50%  -  but I have no idea how that will impact my other files which might display at "ok" sizes.  Likewise the SSA styling in question calls for multiple font sizes (I think they are indeed point sizes for what its worth).   So fonts that already appear much smaller than the normal sized  dialogue get rendered even smaller.

This might be passable on a large screen,  but what happens when you stream to a DLNA device like a mobile phone or tablet?    You can barely read the text because it takes you extra time to focus and by then the text duration may be up.


I propose shrinking the size MC uses now by a modest 25% as a compromise.   In addition if you gave MC logic to think for itself and handle text that would appear much smaller, a little differently and not shrink it so much that might also work well in tandem with the 25% reduction already proposed.

 Alternatively, giving us strict options on respecting the subtitle sizing (with a warning when we enable saying rendering may not be pixel perfect)  would also be a preferred solution on my part..   As the case is right now,  I am so dissatisfied with MC's internal subtitle engine that I spent a week tweaking everything I could possibly imagine until I finally discovered I could get Haali Renderer to work (thus providing the same output as MPC-HC)  and that is how I will likely leave it, until  MC's subtitle engine is improved and hopefully, over time comes to some sort of parody with MPC-HC / Xy-Vsfilter.

Unfortunately we're still stick with the internal engine on DLNA rendering it seems.   So this is still an important issue.

[glynor]

This doesn't help much with how to base your calculation, but...

I feel like MC's subtitles are a tad too big, generally, as well.  Maybe that's because I have a 60" Plasma only 10-12 or so feet from my couch, of course, but... They'd still be legible quite a bit smaller, and they cover a good amount of the video real estate, generally.

They don't need to be the minimum size that'd be acceptable for my crazy Plasma setup, but they could stand to be a touch smaller, globally.  In your screenshot above, I think MPC-HC is too small for comfort on a TV across the room, while MC is too large.  Somewhere in the middle.

Maybe the easiest way to tweak it is to lower that global 9.5% a touch.  Try 8.5 or 9.0 and see what you get.

[jmone]

...and I like how MC does it now (even only 100" screen) but then again I now have reading glasses    I guess there is no "one best answer" to this except a default that users can change.

[glynor]

...and I like how MC does it now (even only 100" screen) but then again I now have reading glasses    I guess there is no "one best answer" to this except a default that users can change.

[6233638]

I think I'm in a somewhat unique position, because back when I started ripping my Blu-rays to MKV there was no support for PGS subtitles in MPC-HC (the player I was using until MC18) so I ripped the video, converted the audio to FLAC (no lossless playback back then either) extracted the PGS subtitles to a .sup file, because I was sure there would be a way to view them at some point (I don't think eac3to supported putting them into an MKV at the time? I forget) ...and then OCR'ed them. 

This means I have about 25 or so films which have external .sup files for the PGS subtitles, and SRT subtitles inside the MKV file. (p.s. Is there any chance of you adding support for external PGS subtitles so I don't have to remux them?)

The SRT subtitles are huge compared to the PGS subtitles for all of the films I have tried so far.

PGS:


SRT:


Having the option to go that big is great, but 25% smaller than they currently are sounds about right to have as the default.

I'm also finding that PGS subtitles seem to be getting cropped off slightly at the bottom, and with italic SRT subtitles, the left edge is getting cut off with some letters.

Positioning seems like it could be a bit "smarter" too, especially when you can only adjust height in 5% steps. With the PGS subtitles, they are positioned so that multi-line subtitles are evenly split above and below the letterboxing. It seems like this is something that could also be achieved in MC18, and handled even better than PGS because you would have the ability to scale them and retain that alignment.

You could also have the option to render subtitles as large as they can be, while still fitting inside the letterboxing so they don't overlap the image. (I liked this when I had a projector, because the text is still huge)

[jmone]

I should say I'm really easy to pleased on subs as I'm not fussy on how they are presented - so to me MC is fine now but.... on balance I really only need them for "forced subs" and all my content is BD anyway.  "One day" when we get optional real BD Menu support it will solve my only sub issue on being able to easily find the forced sub streams that are not flagged as such.

[glynor]

and with italic SRT subtitles, the left edge is getting cut off with some letters.

I've seen this too.

[Neco]

This doesn't help much with how to base your calculation, but...

I feel like MC's subtitles are a tad too big, generally, as well.  Maybe that's because I have a 60" Plasma only 10-12 or so feet from my couch, of course, but... They'd still be legible quite a bit smaller, and they cover a good amount of the video real estate, generally.

They don't need to be the minimum size that'd be acceptable for my crazy Plasma setup, but they could stand to be a touch smaller, globally.  In your screenshot above, I think MPC-HC is too small for comfort on a TV across the room, while MC is too large.  Somewhere in the middle.

Maybe the easiest way to tweak it is to lower that global 9.5% a touch.  Try 8.5 or 9.0 and see what you get.

Actually the default MPC size is quite legible on TV screens.   I have a small handheld so I will take some full size (1080p) pictures and post links to them later on.   Then people could view them on a large screen or large monitor from a distance and see what they think.

[6233638]

On the subject of how text-based subtitles are rendered, something else I would like to suggest is reducing the brightness of text-based subtitles that aren't specifying certain colors. Pure white is often too bright - I prefer 92%. It's bright enough that it doesn't look dim, but it takes the edge off it.

Current / 92%

[Matt]

Another possibility would be to honor the SSA size differently.

If it says "50 point" in the SSA, we could say that works out to 60 pixels on the 800 pixel tall video (you would insert the actual source height here), which is 7.5% of the height.

Since our default height is 9.5% (or whatever we agree that it should be), we could translate SSA of 50 point for that video to 79% size scale (7.5% / 9.5%).  

In other words, we'd try to honor the font size of the SSA instead of taking the median font size and scaling based on that.

Would that be better?

[Neco]

I think that would work pretty well, and would also work nicely within the context of  maintaining updates specifically for ASS/SSA files.

Overall I think the goal for SSA should be  "as transparent as possible" compatability vs what other renderers are displaying.  Which shouldn't upset too many people, as you would assume if they are using ASS/SSA they either subbed it themselves, or know that the subs are implicitly  going to be styled in some manner because of the chosen subtitle format.   And if it really bothers them,  I guess have a tickbox to treat them the same as unformatted text?

[6233638]

Another possibility would be to honor the SSA size differently.

If it says "50 point" in the SSA, we could say that works out to 60 pixels on the 800 pixel tall video (you would insert the actual source height here), which is 7.5% of the height.

Wow, that sounds like a really stupid way to be handling subtitles - not what you are doing, but to have a specification that allows the size to be specified in "points". A point has a physical size - it's 1/72 of an inch. (thanks, America)

So without knowing the size of the display, a "point" is meaningless. If you assume the standard Windows DPI of 96, then 50pt text should be 67 pixels tall, not 60.

Why on earth would they not have them specified either as a percentage of the video height, or as a fixed pixel value at 100% scale. Or is the intent that 1pt = 1px?

Is there a "standard editor" for these files? Perhaps you should use whatever they are doing for scale.

[Neco]

Well, we're assuming its point.  Plenty of stuff on PC's works in points though.  There's nothing stupid about it if you are using it properly.
But that is all pretty moot in this case.

I believe  Aegisub is regarded as the standard bearer for  Substation Alpha and Advanced Substation Alpha.    It's actually an extremely capable and complex program.  I don't understand half of what it does.

http://www.aegisub.org/

Here's a good example of formatting a bunch of text on the screen at once
http://static.aegisub.org/img/screenshots/osx/typesetting-2ebe5ead.png

I don't remember if I gave you a link to this or not Matt,  but it may have been from an older site.

http://docs.aegisub.org/3.0/ASS_Tags/

This is supposed to document every tag supported.  According to the document,  the Font Size is set in  "Script pixels", which is actually  Points @ 72 DPI.   In addition there is a "Font Scale" tag as well.

Font size
\fs<size>
Set the size of the font. The size specified is the height in script pixels, so at font size 40 one line of text is 40 pixels tall. (Technical note: it's really typographic (desktop publishing) points, not script pixels, but since the rendering is always done at 72 DPI (as per the de facto standard), one point ends up being exactly equal to one script resolution pixel.)

[6233638]

Looks like we have our answer. I did spend some time looking around to see if there was some sort of documentation that specified it, but couldn't see anything more than it being specified in points.

It seems that they are assuming 1px = 1pt, which is only true at 72 DPI. I don't see why they wouldn't have just specified it in pixels to begin with.

[Hendrik]

I concur that SSA size should be taken as-is, and not scaled by anything, otherwise people will complain eventually.

[Matt]

Thanks for the help everyone. 

Next build:
Changed: Text subtitles use a slightly smaller default size (size is customizable in Options > Video).
Changed: SSA subtitles honor the font size specified in the SSA style block more exactly.
Changed: When text is both outlined and drop shadowed, it will look better.

Screenshot:

[CountryBumkin]

Great!.
Now if you could just interrupt fo rme what the subtitle is saying ....

[Neco]

That's a big improvement for sure.  Thanks for giving this some attention.

[Neco]

Just some feedback from my bro, who I showed the screens.

Said it looks better, although he kind of agreed with me about the outline still being too thin.   But his major complaint was definitely the text size as well.  He said he's noticed on some scenes where they  throw up signs to translate stuff, it was so large the text would overlap,  and sometimes long dialogue would take up 3 lines and stuff like that.    I think his thing is overall he is looking for consistency and doesn't want to have to tweak stuff every time he watches a file.   So these changes are a lot better in his eyes too.

I'd be interested to hear your thoughts on other issues that are present in the test file, and what can be done to better support them.   You can PM me if you want, or we could continue in this thread if that's OK.

[Matt]

I'd be interested to hear your thoughts on other issues that are present in the test file, and what can be done to better support them.   You can PM me if you want, or we could continue in this thread if that's OK.

You might pick the most important remaining issue and start a thread.

To set your expectations, we might be able to solve one issue, like this size issue, a week for the next month.

Thanks.

[Neco]

Sure, I will start a thread in the future.

I didn't understand what you meant by  "a week for the next month" though?

I think you are saying,  it will take some time or several releases between changes and will not always have a high priority?