Some questions about ASS File Format Guide

[MIRIMIRIM]

1. special ! header in section Script Info: According to my understanding, it meaning key can repeat compared to metadata key-value, but what is the difference from parsing comment lines starting with semicolon
2. Start/End hour can be in the range [0, 595]: Is this a typo or an implementation difference, because the maximum value Aegisub can input is 9
3. Encoding MUST always be set to 1: In fact, I agree with this point of view, but sometimes some people use Encoding to allow GDI fallback to a relatively readable font. For example, Simplified Chinese users can use 128 to fallback to MS Gothic instead of SimSun if they are watching the Japanese part of the subtitles

[TheOneric]

1. Correct, functional headers and normal metadata headers should only be specified once with the correct value, but ! may appear multiple times.
   ; comments are used by generators/editors and often stripped and replaced on resave; e.g. Aegisub will discard any ; lines when loading a file and then later add its own on saving. If ; comments were used for custom metadata, all added metadata would be lost just by resaving the file from an editor. ! headers on the other hand are preserved.

2. Any current renderer has no issues with timestamps up to 596 hours and from my testing muxers (ffmpeg and mkvtoolnix) also appear to handle multi-digit hours well.
   I was not aware of Aegisub limiting timestamps like this before; thanks for bringing this up! As it turns out old libass (9beeecc 2015) also rejected multi-digit hours. That said, there seems to be no real reason for keeping this limit around and Don’t truncate parsed times >=10h arch1t3cht/Aegisub#104 partially fixes this in Aegisub.
   Do you know of any more programs which fail to handle multi-digit hours? If not, I’ll just add a note about this to the guide which will hopefully soon become irrelevant.

3. Using Encoding/\fe to get a particular fallback font is a terrible idea and in practice not portable and thus broken. For one regardless of whether \fe is involved or not, fallbacks fonts are always a bit iffy as it relies on no better match being present on the system (e.g. a subber may have a modified variant of the actually specified font installed). Then fallback selection also can depend on the system’s configured locale as seen e.g. in Take track language into account when performing font fallback #550 (comment) . Furthermore, even if the locale matches and the same fonts are installed, fallback logic depends on the system font provider and thus will differ depending on the OS and player configuration.
   To top it of, fallback fonts are not (always) recognised by font collector tools and often not attached to the published mkv, making it straight up impossible to reproduce the desired outcome on a system without the intended fonts.
   And for \fe specifically, libass currently doesn’t support it at all (see Support \fe aka font Encoding in Style #662) and MPC-HC ISR and xy-VSFilter also handle this property a bit differently.
   While unfortunately some exiting releases do abuse fallback semantics and \fe, this really should not be done and no new such files created. As the guide already says, if you want a particular font, just specify its actual name via FontName/\fn.
   (tangentially related: see also \h fallback messes up positioning #42 for another issue, which is hard to fix because fallback expectations are involved)

[moi15moi]

3. To top it of, fallback fonts are not (always) recognised by font collector tools

Actually, Aegisub FontCollector doesn't even care about the Encoding, so it cannot detect the real used font if the encoding isn't 1.
I don't know any FontCollector that care about it. Probably because libass doesn't emulate it, so pretty much "no one" knows how it exactly works.

[MIRIMIRIM]

1. Correct, functional headers and normal metadata headers should only be specified once with the correct value, but may appear multiple times.
   comments are used by generators/editors and often stripped and replaced on resave; e.g. Aegisub will discard any lines when loading a file and then later add its own on saving. If comments were used for custom metadata, all added metadata would be lost just by resaving the file from an editor. headers on the other hand are preserved.!``;``;``;``!
2. Any current renderer has no issues with timestamps up to 596 hours and from my testing muxers (ffmpeg and mkvtoolnix) also appear to handle multi-digit hours well.
   I was not aware of Aegisub limiting timestamps like this before; thanks for bringing this up! As it turns out old libass (9beeecc 2015) also rejected multi-digit hours. That said, there seems to be no real reason for keeping this limit around and Don’t truncate parsed times >=10h arch1t3cht/Aegisub#104 partially fixes this in Aegisub.
   Do you know of any more programs which fail to handle multi-digit hours? If not, I’ll just add a note about this to the guide which will hopefully soon become irrelevant.
3. Using / to get a particular fallback font is a terrible idea and in practice not portable and thus broken. For one regardless of whether is involved or not, fallbacks fonts are always a bit iffy as it relies on no better match being present on the system (e.g. a subber may have a modified variant of the actually specified font installed). Then fallback selection also can depend on the system’s configured locale as seen e.g. in Encoding``\fe``\feTake track language into account when performing font fallback #550 (comment) . Furthermore, even if the locale matches and the same fonts are installed, fallback logic depends on the system font provider and thus will differ depending on the OS and player configuration.
   To top it of, fallback fonts are not (always) recognised by font collector tools and often not attached to the published mkv, making it straight up impossible to reproduce the desired outcome on a system without the intended fonts.
   And for specifically, libass currently doesn’t support it at all \fe(see Support \fe aka font Encoding in Style #662) and MPC-HC ISR and xy-VSFilter also handle this property a bit differently.
   While unfortunately some exiting releases do abuse fallback semantics and , this really should not be done and no new such files created. As the guide already says, if you want a particular font, just specify its actual name via /.\fe``FontName``\fn
   (tangentially related: see also \h fallback messes up positioning #42 for another issue, which is hard to fix because fallback expectations are involved)

2. Kainote also behaves similarly to Aegisub. BTW, why is the upper limit 596?
3. \h really bad. After reading this issue, I learned that libass will fallback to U+0020 (but I don’t know if this conversion still exists now). When using CJK font, I recommend using U+3000 with fscx instead of \h, U+2003 maybe an option for Latin fonts

[TheOneric]

2. Kainote also behaves similarly to Aegisub. BTW, why is the upper limit 596?

Thanks! Welp, guess Kainote could up its limit then too.
EDIT: it seems Kainote’s parsing code already accepts multi-digit hours and the only limits I spotted were for negative times. If the input boxes don’t allow entering multi-digit hours, it appears to fortunately be only an UI issue unlike with Aegisub.

The 595 limit for hours comes from classic VSFilters (and in some parts libass to emulate this) handling timestamps internally as a 32-bit number denoting milliseconds. Everything < 596h can be represented with this, but between 566h and 567h the value overflows 32 bits.

3. \h really bad. I learned that libass will fallback to U+0020 (but I don’t know if this conversion still exists now)

libass git master no longer sometimes subsitutes \h with a regular space U+0020. Apart from older libass doing this substitution, there’s nothing special about \h and the remaining problem in #42 is just about the sample subs using a font without \h and expecting a very particular fallback. Which is hard to impossible to solve and subs should never rely on font fallback (which is the same with \fe fallback).
I guess if there’s an advantage to {\fscx150} {\fscx}it’s almost every font having a glyph for U+0020, but in comparison less fonts having a glyph for \h.

[MIRIMIRIM]

3. \h really bad. I learned that libass will fallback to U+0020 (but I don’t know if this conversion still exists now)

libass git master no longer sometimes subsitutes \h with a regular space U+0020. Apart from older libass doing this substitution, there’s nothing special about \h and the remaining problem in #42 is just about the sample subs using a font without \h and expecting a very particular fallback. Which is hard to impossible to solve and subs should never rely on font fallback (which is the same with \fe fallback). I guess if there’s an advantage to {\fscx150} {\fscx}it’s almost every font having a glyph for U+0020, but in comparison less fonts having a glyph for \h.

But U+0020 at the beginning of the line will not be rendered… Such as after \N
BTW, override tags do not declare values as equivalent to default values, is this behavior correct or is it just a fallback that should be avoided? Some are counterintuitive, e.g. \b=\b0

[TheOneric]

But U+0020 at the beginning of the line will not be rendered… Such as after \N

Yep, but as long as the font actually has a glyph for \h (U+00A0), there is no problem with using \h. Just never rely on fallback glyphs.

BTW, override tags do not declare values as equivalent to default values, is this behavior correct or is it just a fallback that should be avoided?

\b is not the same as \b0. It resets boldness to what was declared in the Style’s Bold field.
Many other tags (e.g. \fscx) do the same when called with no arguments. This is established ASS behaviour and I’m not aware of any issues with it (for tags which support this, of the top of my head most should).

[MIRIMIRIM]

BTW, override tags do not declare values as equivalent to default values, is this behavior correct or is it just a fallback that should be avoided?

\b is not the same as \b0. It resets boldness to what was declared in the Style’s Bold field. Many other tags (e.g. \fscx) do the same when called with no arguments. This is established ASS behaviour and I’m not aware of any issues with it (for tags which support this, of the top of my head most should).

I understand, logically it is initialized to style.