Trouble logging in?If you can't remember your password or are having trouble logging in, you will have to reset your password. If you have trouble resetting your password (for example, if you lost access to the original email address), please do not start posting with a new account, as this is against the forum rules. If you create a temporary account, please contact us right away via Forum Support, and send us any information you can about your original account, such as the account name and any email address that may have been associated with it.

Emulated horizontal blur by having a bunch of transparent copies overlaid at various offsets, then moving together.

Fancy effects are not required for subtitles to be enjoyable, do them only if you know how to do them beforehand, or is willing to spend your own time figuring out how to do it. Ultimately those effects are pointless other than showing off your skills.

Since the Aegisub forums seem to be down, I wanted to share a few thoughts on ver 2.1.9 here. Overall, it's still just as good if not better than ever, but there were a couple of changes that left me wondering a bit.

* Minor one: "Select Subtitles" no longer has a beep and or a dialogue box indicating "## lines were added/removed/set from/to selection." Not a huge deal since it still works the same, but it still would be nice to have that info.

* Not-so-minor one: Spellcheck seems to have taken a step in the wrong direction. Mainly because it now parses hyphens (-) as if they were letters and not punctuation marks. (And for some reason, a standalone - always gets flagged by spellcheck in each new script, even if you clicked "Add to Dictionary" for it in another file.) Since typical fansubbed anime involves a lot of non-English words and suffixes, the Custom Dictionary comes in handy to store common honorifics, character names, foods, and other Japanese terms so that they don't come up as misspelled words every time. Pre-2.1.9, one could add names and honorifics such as chan/san/kun/sama to the CD, and spellcheck would recognize (for example) "Azusa" and whatever honorific as separate, valid words.

But now that hyphens get parsed, one has to separately add "Azusa-san," "Azusa-chan," "Azusa-sama," or other combinations, as well as all the variants like "Azusa-chan's", "Azusa-san'll", etc. Same with s-stuttered words: before, SC would see "W-What" as a standalone W (not flagged) and the valid word "What", and not flag it. But now, every new stuttered word shows up as a misspelling. The same also applies to words with -- at the ends of lines to indicate an abrupt cutoff. While "--" can be successfully added to the CD, SC will stop at a line like "I don't know why you--" and suggest that "you--" be "you --". Hyphenated compound words whose components are correctly spelled are also affected.

This change affects me a little more than average because I work with Magical Girl shows where the magical mascots end their lines with verbal tics like -coco or -mil. Pre 2.1.9, SC would not have flagged a line like "Look out-coco!" once "coco" was in the CD, but now every different [word]+[verbal tic] combination has to be manually added/ignored separately.

Overall, the dash-parsing in the new spellcheck takes more time, since depending on one's inherent accuracy, maybe 5-10 false-positive "hyphen issues" show up for every genuine mistake. And it may lead to more errors in final scripts, since people might blindly and impatiently hit "Ignore" or "Add" in [misspelled word]-[something else] or [misspelled word]-- situations, assuming that SC is showing an error because of the hyphen and not noticing the actual mistake. In essence, I haven't observed any benefit in the new way vs. the old way.

Anyway, if this has been brought up elsewhere in the past, I apologize for being redundant. And while I'm not one to criticize the time and effort spent in producing free software, I do hope that these issues can be looked into for future releases.

* Minor one: "Select Subtitles" no longer has a beep and or a dialogue box indicating "## lines were added/removed/set from/to selection." Not a huge deal since it still works the same, but it still would be nice to have that info.

It's now shown in the status bar since it's frequently not very important.

Quote:

Originally Posted by Zalis

* Not-so-minor one: Spellcheck seems to have taken a step in the wrong direction. Mainly because it now parses hyphens (-) as if they were letters and not punctuation marks. (And for some reason, a standalone - always gets flagged by spellcheck in each new script, even if you clicked "Add to Dictionary" for it in another file.) Since typical fansubbed anime involves a lot of non-English words and suffixes, the Custom Dictionary comes in handy to store common honorifics, character names, foods, and other Japanese terms so that they don't come up as misspelled words every time. Pre-2.1.9, one could add names and honorifics such as chan/san/kun/sama to the CD, and spellcheck would recognize (for example) "Azusa" and whatever honorific as separate, valid words.

But now that hyphens get parsed, one has to separately add "Azusa-san," "Azusa-chan," "Azusa-sama," or other combinations, as well as all the variants like "Azusa-chan's", "Azusa-san'll", etc. Same with s-stuttered words: before, SC would see "W-What" as a standalone W (not flagged) and the valid word "What", and not flag it. But now, every new stuttered word shows up as a misspelling. The same also applies to words with -- at the ends of lines to indicate an abrupt cutoff. While "--" can be successfully added to the CD, SC will stop at a line like "I don't know why you--" and suggest that "you--" be "you --". Hyphenated compound words whose components are correctly spelled are also affected.

This change affects me a little more than average because I work with Magical Girl shows where the magical mascots end their lines with verbal tics like -coco or -mil. Pre 2.1.9, SC would not have flagged a line like "Look out-coco!" once "coco" was in the CD, but now every different [word]+[verbal tic] combination has to be manually added/ignored separately.

Overall, the dash-parsing in the new spellcheck takes more time, since depending on one's inherent accuracy, maybe 5-10 false-positive "hyphen issues" show up for every genuine mistake. And it may lead to more errors in final scripts, since people might blindly and impatiently hit "Ignore" or "Add" in [misspelled word]-[something else] or [misspelled word]-- situations, assuming that SC is showing an error because of the hyphen and not noticing the actual mistake. In essence, I haven't observed any benefit in the new way vs. the old way.

Anyway, if this has been brought up elsewhere in the past, I apologize for being redundant. And while I'm not one to criticize the time and effort spent in producing free software, I do hope that these issues can be looked into for future releases.

I don't think the removal of hyphens from the word separator list was an intentional change. There's no hyphens in the English dictionary we ship, so it's never actually useful to treat them as a letter.

In the end, all of the word separation stuff ought to be per-language and not a concern of the application using the spell checker library. Ugh.

Oh, and the forum is very much up. (The URL is http://forum.aegisub.org/.) However I have been very lazy recently and not been going through the moderation queue, so new users' posts won't have been published for a week or thereabout. (And the moderation is in place to pick out the one or two posts from legitimate new users, from the upwards 2000 spam posts every week.)

It helps if you use an encode that's easier on the CPU, like Xvid instead of H264. Be wary of re-encoding possibly not being perfectly frame-accurate, though (leading to stuff being mistimed if you do the work on the re-encode and then apply it to the original without checking).

For HD stuff, I generally make a low bitrate work raw to use in Aegisub when I need to seek a lot, like when fixing scene timing errors. --tune fastdecode and lowering --keyint are handy for this.

If the work raw has the same number of frames as the normal encode and is muxed at the same frame rate (or uses the same timecodes file for vfr), the subtitle timing should be frame exact between the two. And if you're reencoding from the normal raw to make the work raw rather than using the same avs to make both, just make sure you use a frame accurate source filter and avoid frame rate conversions other than AssumeFPS().

It helps if you use an encode that's easier on the CPU, like Xvid instead of H264. Be wary of re-encoding possibly not being perfectly frame-accurate, though (leading to stuff being mistimed if you do the work on the re-encode and then apply it to the original without checking).

The Problem with ure frame-accuracy certainly comes from using Xivd, with b-frames, in a avi container as "workraw". Avi can't handle b-frames. This manifests itself in a small seeking-error. Nothing you notice on watching or scrouping through an avi with an vid-stream containing b-frames. But a big problem if you want to something frame-accurate on souch a source. Soluiton: Do you "workraw" without b-frames.

And, even if you not should do this, use something in an avi as raw: go raw to lossless > loosless to workraw > loosless to finalencode.

The Problem with ure frame-accuracy certainly comes from using Xivd, with b-frames, in a avi container as "workraw". Avi can't handle b-frames. This manifests itself in a small seeking-error. Nothing you notice on watching or scrouping through an avi with an vid-stream containing b-frames. But a big problem if you want to something frame-accurate on souch a source. Soluiton: Do you "workraw" without b-frames.

And, even if you not should do this, use something in an avi as raw: go raw to lossless > loosless to workraw > loosless to finalencode.

Actually, I've never used B-frames for my timing raws and still ran into the issue with some sources. It seems that whatever way I re-encode those particular files, there's a frame mismatch or two somewhere. No VFR that I know of, and I use FFMS2 as source filter. In any case, it's not a big deal since I just get keyframe files straight from the encoder now.

Location: Somewhere over the rainbow, in a house dropped on an ugly, old woman.

Not sure if this is possible, or if this is the place to ask, but I'll ask anyway...

What I want to do, is cut the OP lyrics from one fansubbed anime episode, and paste it into another episode. Essentially, adding OP lyric subtitles to the next episode. The only problem is that in each episode, the time the OP song starts and ends is different.

Is there a way to automatically or easily re-time the start and end times of a block of OP song text in aegisub? Or perhaps is there another program that would work better?

The OP fansub lyrics that I want to transfer over has the works - English, Romaji, and Kanji; the latter two lighting up as each kanji symbol is pronounced. It's a nifty package that I want to apply to the other episodes, and so far, the only way I see to do it is to retime each line manually.

If there is no easy way to add all of it, I'll just add the English translation text, and forget the romaji and kanji. Does my question make sense?