Opens an .ass file, or imports an .ssa file as ASS. ScriptType v4.00 and v4.00+ are supported.
The file encoding can be Unicode (UTF-7/8/16/32, with or without BOM, BE or LE), or non-Unicode. If the encoding is not automatically detected, you'll be asked to select one from the list. The following encodings will be auto-detected: UTF-7 (in most cases), UTF-8 (BOM required), UTF-16, UTF-32, GB-18030 (BOM required). UTF-8 without BOM can be imported but not auto-detected.
End-of-line (EOL) marks can be à la Windows, à la MacOS 9, à la UNIX, U+2028, or any mix of them.
0.0.9.46— U+2029 and U+0085 are also accepted as EOL. (<000D 0085> is accepted as 2 EOLs.)
Endianness doesn't matter. Non-BMP code points (surrogate pairs in UTF-16) are supported too.
On Windows 2000, you need to install GB18030 Support Package if you would like to import a script in GB-18030. The direct link is GBEXTSUP.msi.
Windows XP supports GB-18030 natively, but you may still want to install the above Package, for example, in order to install SimSun-18030 and NSimSun-18030 fonts (SimSun18030.ttc).
If you want to make subtitles in a complex and/or "minor" language, for example in Khmer language (Cambodian), usp10.dll coming with Windows XP (even with SP3) is not enough. Especially, usp10.dll coming with Windows XP SP2 (1.420.2600.2180) is problematic. Usp10.dll version 1.600 (1.0600) or greater is recommended (which will work on XP too). Here's what you can do:
Get MS VOLT 1.3 released in June, 2008 (the above page says. the Date Published is 2008-07-31; the digital signature on the file says 2008-06-05). Direct link is: MSVOLT.exe.
Don't run the exe but simply decompress it using 7-Zip and find the file called VOLT.CAB. Decompress it, and find the file called VOLTSupplementalFiles.exe. Decompress it, and find the file called usp.cab. Decompress it, and usp10.dll, version 1.0626.6001.18000 is there. That's what you need. If the above doesn't work for some reason, you can get usp10.dll 1.0626.6001.18000 here. This version of usp10.dll has the MD5 value CD38307C537D1DB7CEDE6C534261190E.
Make sure that:
in Explorer's Tools menu - Folder Options - View - Advanced settings - Hidden files and folers. Ignore (Recommended) here. usp10.dll is a system file, and if you obey the recommendation, it's hidden and you can't see it. You can't work with a file that you can't see. Obvious.
The easiest way to use it on Windows XP is just putting it in the same folder of the application, for example, ASS_Help3r.exe, VirtualDub.exe, or notepad.exe. If you want to globally replace the "default" usp10.dll in the system folder so that every application will use it, you can use dual-boot. Start the second OS and replace the usp10.dll in the 1st OS, and then restart the 1st OS.
If your PC is not dual-boot and you still want to replace usp10.dll globally, or if your OS is Windows 2000, then read this: Replacing your Uniscribe dll .
[Start] - [Run] - msinfo32 - [OK] and you get system information. Check Software Environments - Loaded Modules - usp10. If it says its Version is "1.0626.6001.18000 (longhorn_rtm.080118-1840)", the up-to-date usp10.dll is working.
See also Uniscribe in Wikipedia.
Windows 7 RC has usp10.dll 1.626.7100.0 in 7100.0.090421-1700_x86fre_client_en-us_retail_ultimate-grc1culfrer_en_dvd.iso\sources\boot.wim\1\Windows\System32\ but it doesn't work on Windows XP, because it depends on _except_handler4_common which Windows XP doesn't have.
The following info is old.
On Windows 2000/XP: If you need to update Uniscribe (USP10.dll or Unicode Scripts Processor), version 1.613.5291 is packed in MSVOLT.exe, MD5 of the usp10.dll being B400FC659A5617D072841E2F69AFDB6E (MSVOLT.exe\VOLT.CAB\VOLTSupplementalFiles.exe\usp.cab\usp10.dll); or it is also available on /Font khmer. You can use 7-Zip to unpack them. See also Microsoft VOLT users community. A newer version, 1.626.5756.0, is bundled with Office 2007 (for instance, as USP10.DLL_0002 in Office 2007 Enterprise\Enterprise.WW\EnterWW.cab), but the differences between those versions are probably trivial.
NOTE: An older version, 1.473.4067, is in VOLTSupplementalFiles.exe, which apparently doesn't have Sinhala support. The default version of USP10.DLL coming with Windows 2000 SP4 or XP SP2 is even older, but they will suffice as long as you don't work with "minor" languages such as Tibetan or Sinhala.
A file to open can be huge. There can be 10,000 or more Dialogues, or a line can be very long (10,000 characters or more). There can be many (~1,000) Styles too, but then AVISynth (VSFilter) starts slowly. Comment lines are loaded too, and not will be discarded when you save the file as another name.
The ASS file is internally converted to UTF-16 LE BOM with \r\n or \n EOLs, and the working copy is always in the temporary subfolder named a3r_temp(Number) in the system's temporary folder (usually, \Documents and Settings\(User Name)\Local Settings\Temp) as a3^something.ext. This temporary file might be useful in case you overwrite the original file in a wrong way, but if that happened, you could just do File - Save as UTF-* to re-save the file that a3r is currently having internally.
The above-mentioned temporary subfolder and the temporary files in it will be automatically deleted when you close the application. Even if it crashes and doesn't end normally, those temporary files will be deleted in the next run. So don't save anything there. (You can run 2 or more instances at once, if you'd like to, as each instance uses a different subfolder for working files.)
Even if you edit the original ASS by another application such as a text editor or a subtitle IDE, the working copy for this application is, by default, not automatically updated. To reload the file(s), hit [F5].
0.0.9.17+: The menu item Open/Auto-Reload on Changes... is like "Auto-reload subtitle files after detecting modification" in Direct VobSub. If you open your script this way, the subpics (including the current video frame) will be automatically refreshed whenever the script is updated. Refreshing may cost about one to a few seconds depending on the complexity of the script.
Same as "Open ASS/SSA" except that only Dialogues with {\K*} or {\k*} are loaded.
Reloads the ASS, if it is currently loaded, refreshing the sub pictures. If ASS and AVI are loaded, both will be reopened.
0.0.9.9+: [Ctrl] + [R] is synonymous.
Closes the script.
Shows information about file(s) currently opened. Reported information includes: LAME Tag, dwStart, AVI file size stored in the RIFF header (many muxers write a wrong number there, but practically there is no problem, so don't worry too much), Interleaving setting (Audio per every how-many Video Frames?), and AVI JUNK (this sometimes contains interesting strings).
NOTE: Older versions may wrongly detect a LAME tag even if it does not exist. This problem was fixed in v0.0.6.2-beta / 0.0.7.4-alpha. In 0.0.7.23 and before, only CBR MP3 is supported and a LAME tag is not detected in VBR MP3 in AVI, even if it exists. Since 0.0.7.24, LAME tags are always detected, both in CBR and VBR/ABR.
By default LAME uses the first MP3 frame to store information such as Encoder Delay, Padding, and Encoder Version. A player that handles a LAME tag will read info from there and tweaks the audio timing using these parameters, which enables sample-accurate (so-called gapless) playback. Such a "LAME-aware" player decodes the MP3 file starting from the second MP3 frame. (The first MP3 frame is not a real thing, but for storing information.)
For a player that doesn't handle a LAME tag, the first MP3 frame looks like just a normal MP3 frame which is decoded as silence.
Audio players often handle the LAME tag, while DirectShow decoders usually don't. In an audio-video file, such as AVI or MKV, this means AV sync confusion. If the decoder handles the LAME tag (there is such a DirectShow filter too), the audio timing will be shifted by about 20 to 50 ms. Obviously, this could be a problem for subtitle-audio sync, especially in karaoke. The real problem is not decoding-side, but encoding-side:
Delay 1 If you convert a WAV to an MP3, the audio will be a little delayed (typically by 10 to 30 ms). This is called Encoder Delay, an intrinsic problem caused by MP3 algorithm. The LAME tag could fix this very problem, but we assume here that our decoder is not LAME-aware (almost all DirectShow decoders are not LAME-aware).
Delay 2 If you use the LAME tag, audio will be delayed even more, by one MP3 frame = 1152 samples, that is 24 ms in 48000 Hz, about 26.1 ms in 44100 Hz, and 32 ms in 36000 Hz. This is because LAME uses the first MP3 frame for its own purpose.
These are two different (although partly related) problems. You might want to at least suppress the LAME tag so that the audio timing will be non-ambiguous, decoder-independent. You could do so very easily. Just use -t switch when encoding with lame.exe. This problem is not only when the LAME MP3 is VBR. CBR and ABR are equally affected.
The safest and cleanest way to fix Encoder Delay would be giving the input WAV a "negative delay" with the same absolute value. This means, deleting first several milliseconds of WAV, using an audio editor, before converting it to MP3. Some muxeres support audio shifting (Track Delay), negative or positive, but still the first method is recommended.
NOTE: On the other hand, some audio players (not movie players) such as foobar2000 even assume that MP3 with a LAME (or compatible) Tag is standard, and MP3 without one is non-standard. (Technically, this is of course a wrong assumption. Depending on a LAME tag is a hack, and not standard.) Such an audio player may more or less act weirdly if MP3 doesn't have a LAME tag. Movie players (MPC, VLC, mplayer, ffplay... and almost all DirectShow MP3 decorder) do not depend on LAME tags at all, so they work okay without one, and conversely they are confused by a LAME tag in a sense that audio is delayed a little against the video.
Simply put, a parameter that confuses AV sync, not because dwStart is evil, but because many players don't support it properly. VirtualDub 1.7.0 warns about non-zero dwStart. VirtualDub 1.6.x just ignores it.
Opens an AVI file.
Image files (.bmp, .jpg) can be opened too, although that is not much useful. Instead just paste an image from Clipboard by the standard [Ctrl]+[V] shortcut, when, for instance, you'd like to use the Color Picker.
Closes the AVI or other image file that has been loaded.
Simple preview to check subtitles on the raw video. 0.0.9.30 and later versions are hopefully so-so.
One good thing is that you can almost always preview the video in real-time against the audio, even if there are complicated subtitle effects. For instance, if you were previewing a 24 fps video with effect which is so complicated that it can be rendered only at 20 fps, a3r would drop 4 video frames per every 24 frames, and forcefully keep sync'ing subs to the audio. So you can always (at least roughly) preview karaoke or other effect that you can't properly preview on VirtualDub. (VirtualDub jitters and almost stops if the ASS has complicated effects.) You could also just play AVI without ASS, but there's no point in doing that (you can just use a normal player like MPC).
AVIStreamRead error, 0x80004005,
when previewing is paused or stopped, but usually automatically recover from the error.AVIStreamGetFrame fails to decompress the video frame properly.
As a result, CreateDIBitmap fails (which was not handled) and
Windows may report a GDI error, or AviSynth may report a VCM error.
(2) Another problem occurs when waveOutUnprepareHeader is called too early and fails as WAVERR_STILLPLAYING
(which was not handled either). This could cause some kind of memory error, and the result is not really predictable.
Windows may report "heap corruption", or AviSynth might report ACM error.
CreateDIBitmap and automatically stops previewing before it gets too late.
The timing to call waveOutUnprepareHeader has been also improved, so the second problem usually doesn't happen at all,
and, even if it does, the error is (more or less) handled.
AVI's dwStart is currently ignored. (perhaps same as other players except WMP).
By default, LAME tag is ignored and treated as a normal MP3 frame, as almost all other DirectShow players do, but you can tell a3r to try to interpret it too (as some audio players do). The interface for it is displayed only when the LAME tag is detected. (Experimental)
NOTE: LAME Tag handling is not tested well. Maybe wrong.
Preview starts/pauses by pressing the [Space] key.
It also starts/pauses by [Enter], and pauses by clicking on a video frame (the left one), or by the key sequence [Alt]+[F] then [A]. The [.] key (period; not [Num .]) rewinds the video. These shortcuts are mainly for compatibility with VD/VDM and MPC.
0.0.7.50—: Right-clicking on the Trackbar also starts/pauses previewing.
0.0.8.0—: Right-clicking anywhere below the Main Editbox also starts/pauses previewing (unless a text selection is made in the Timestamp Editbox).
AVI with a single audio stream in WAV (PCM) or CBR MP3 is supported. AVI with no audio is supported too. Multiaudio is not supported.
EnsureVBRMP3Sync, which makes seeking quite slow
(you cannot start previewing from the middle of the file quickly).
To play AC3 audio, you need to install a proper ACM decoder, such as AC3Filter ACM codec.
Starting from v1.45b (June 7, 2007),
ACM codec is included in the AC3Filter package.
0.0.9.36 uses DirectShow if ACM codec is not available.
NOTE (0.0.9.35 and before): The ACM codec (ac3filter.acm) and DirectShow filter (ac3filter.ax) are different, and AviSynth cannot decompress AC3-in-AVI via VfW without a proper ACM codec. Also note that ac3filter.acm was called vac3.acm before (until v0.3). The current version of the ACM codec is included in ac3filter 1.45b. I'd recommend an older version, vac3.acm (vac3acm_0_3a).
Basically, the preview uses VfW/ACM, not DirectShow. Some video compression format that you can play via DirectShow may not play via VfW. If that happens, make sure that you have a newer ffdshow, go to Start->Programs->ffdshow->VfW conf->Codecs, and enable the decoder needed. As of writing this, ffdshow tryout official beta4, dated 2007-12-06, is available. Similary, some audio format that you can play via DirectShow may not play via ACM.
0.0.9.36—: If ACM cannot decode audio, DirectShow is automatically used. So you can do without ACM codecs for AC3, etc. But VfW and ACM are always faster for the purpose of this application, and they are always more accurate than DirectShow (which is sometimes not frame-accurate).
Never install a so-called Codec Pack even if something doesn't play. Many codec packs are problematic. CCCP is relatively accepted, but its default settings are for ordinary users who prefer easy solutions rather than quality; it can be problematic too anyway.
MP3 in AVI is supposed to have an MPEG Layer-3 Wave Format (MPEGLAYER3WAVEFORMAT) header, whose size is 30 bytes. Said differently, it is a Wave Format Ex (WAVEFORMATEX; wfx) header with cbSize=12: {sizeof(WAVEFORMATEX)=18 bytes} + {extra 12 bytes} = {30 bytes}.
Some AVI muxers — apparently including some versions of Avidemux — write a too short (borked) header for MP3 in AVI. The size of the wfx must be 18 bytes, but those muxers make it 16 bytes, where the cbSize member (2 bytes, its value is supposed to be 12) is missing. The extra 12 bytes are totally missing too.
Saves the currently-loaded ASS as another file, as normalizing or shifting timestamps, partially or totally.
Normalizing: If the video is about 24 (24000/1001) fps, there are 4 or 5 logical timestamps for ASS that means basically the same actual timing. A simple subtitle that logically starts at the timestamp 00:20.11, 00:20.12, 00:20.13, or 00:20.14 all actually starts at 00:20.145 125 (logically here means the timestamp written in the ASS; actually roughly means physically; real physical timing may be affected by hardware limitations or other elements.).
Normalizing means using the largest timestamp among the synonymous logical timestamps (in the above example 00:20.14), so that the error (margin) between the logical timing and actual timing will be minimized.
If the actual event is at 00:20.145 125 and the logical timestamp is 00:20.14, the margin is 5.125 ms.
If time stamps are not normalized but randomly selected, the same command like {\fad(50,0)} doesn't work similarly everywhere. In the above example, 20.11 and 20.14 are synonymous logical timestamps, and yet, if you did {\fad(50,0)} at 00:20.11, the sub on 00:20.145 125 would be near-opaque while if you did {\fad(50,0)} at 00:20.14, the sub on 00:20.145 125 would be near-transparent. Some commands are actually subframe-sensitive. If timestamps are not normalized, you might have to write {\fad(50,0)} in one place and {\fad(80,0)} in another to get the same effect.
Another example is karaoke. Even if you put an empty {\k20} token for each line to preload it before color changing begins, if the timestamp is not normalized, it may actually mean {\k25} for some lines, and {\k21} for other lines, obviously not ideal for strict timing control. K tags are also subframe-sensitive.
The time parameters for \t are relative to the line start time (logical time stamp), so {\t(30, ... } could be meaningless if the margin (error) is too large and the actual frame start is more than 30 ms after the logical timestamp. What you think "30 ms after the line start" might be actually not even after the line start, but before. Allow large margins, and such a confusing situation might happen.
Hence, normalizing is basically a good idea, resulting in better sync'ing between logical timeline in ASS and actual events, which enables you to control effects more systematically.
Over-normalizing: However, it could be risky to normalize too much; for instance, Matroska by default uses 1-ms resolution, so if the margin is, for instance, just 0.01 ms, there might be confusion about the event order: if the sub start time is before the video frame timing, the sub is on that frame; if the sub start time is after the video frame timing, the sub is not on that frame. 0.01 ms is so short that the "before or after?" relationship might go wrong for some unexpected problem, making the sub off by one frame. One of such hard-to-spot problems would be using 23.976 assuming it means 2997/125; (float) 23.976 actually means something like 23.97599983215332.
I'd recommend you to always keep at least 0.5 milliseconds margin (this means, 0.5ms <= actual margin < 10.5 ms). If you are working with someone who confuses 24000/1001 with 2997/125, saying the difference is very little and ignorable, you might want to set margin even bigger to be on the safe side.
Subframe-accuracy Trade-offs
Recommended:
The 0.5 ms margin has another practical meaning. Many tools (e.g. VirtualDub) show timestamp in ms accuracy. Working on such a tool, you have to wonder about the event order if a smaller margin is allowed. For instance, Frame 6 @ 24000/1001 fps is actually 0:00:00.250 250 000, which VirtualDub reports as 00:00.250. If a smaller margin is allowed, the SSA/ASS timestamp for this frame is normalized as 00:00.25, but that is confusing. 00:00.250 reported by VD might be 00.2501, or might be 00.2499. So you can't tell for sure if the sub that starts at 00:00.25 is on that frame or not. This is frustrating and could be a cause of mistakes. Instead, use the SSA/ASS timestamp 00:00.24, and you can clearly show that this sub is on that frame. This means, you are keeping at least 0.5 ms margin.
In other words:
In this case, the result would be accidentally ok without subtracting 10 ms, but for instance, you can't use 00:01.21 to point to the frame 29, which VD reports as 00:01.210, as the actual timing is 00:01.209 541 667. A sub that starts at 00:01.21 is not on this frame, but first appears on frame 30.
Whenever using the max possible timestamp breaks the specified margin, a3r automatically uses the next largest logical timestamp. So, when you let a3r normalize timestamps, it generally makes many timestamps larger, while not changing many other timestamps (=already normalized) and making a few timestamps smaller by 0.01 seconds.
Subframe-accurate Shifting: If you carelessly normalized a Dialogue containing subframe-sensitive commands (such as \fad or \K or \t), that could slightly change the output. You can tell a3r not to normalize such Dialogues, or you can also tell a3r to shift timing as keeping the subframe accuracy as much as possible for such Dialogues.
Note that a method like "just adding 1 second" would never achieve frame-accurate shifting. You need to specify the correct fps. Never confuse 24000/1001, 2997/125 and (float) 23.976... or some Dialogues may not be frame-accurate but off by one. Don't use a float in, for instance, AVS's AssumeFPS. Use a fraction to express the fps, whenever possible.
This will convert the encoding. You can save the file with or without BOM, as LE or BE.
This will convert the file as following, which might be useful when you re-translate an existing ASS on your text editor.
(original) Dialogue: 0,0:00:01.00,0:00:02.00,Style1,,0000,0000,0000,,Line 1 Dialogue: 0,0:00:02.00,0:00:03.00,Style2,,0000,0000,0000,,Line 2 Dialogue: 0,0:00:03.00,0:00:04.00,Style3,,0000,0000,0000,,Line 3 (created new file) Comment: 0,0:00:01.00,0:00:02.00,Style1,,0000,0000,0000,,Line 1 Dialogue: 0,0:00:01.00,0:00:02.00,Style1,,0000,0000,0000,, Comment: 0,0:00:02.00,0:00:03.00,Style2,,0000,0000,0000,,Line 2 Dialogue: 0,0:00:02.00,0:00:03.00,Style2,,0000,0000,0000,, Comment: 0,0:00:03.00,0:00:04.00,Style3,,0000,0000,0000,,Line 3 Dialogue: 0,0:00:03.00,0:00:04.00,Style3,,0000,0000,0000,,
Same as Unix touch command. Changes the time stamps of all the files in the specified folder, recursively.
Save the loaded ASS as a US-ASCII plain text file, so that anyone can read or edit it with any editor. This works only when the conversion is roughly possible, i.e. the original file is basically in English, German, French, etc. Obviously a file in Russian, Chinese, etc. cannot be converted to a US-ASCII file.
ASS commands such as {\i1} are dropped. The ASS drawing line {\p+}... is dropped too.
0.0.7.27+: Karaoke lines (K/k's and t-clip's) are also dropped.
0.0.7.18+: Calculates the CRC-32 of the given file.
0.0.7.18+: Tries to change 4 bytes in a 'JUNK' chunk (padding bytes) of the specified AVI file so that it will have the
desired CRC-32. Experimental. Use it carefully.
The algorithm is taken from:
Martin Stigge, Henryk Plötz, Wolf Müller, Jens-Peter Redlich:
Reversing CRC - Theory and Practice,
HU Berlin Public Report SAR-PR-2006-05
NOTE: In versions 0.0.7.18–22, the 4 bytes from the first top-level 'JUNK' were tweaked. Since 0.0.7.23, the 4 bytes at the very end of the last available 'JUNK' are tweaked.
0.0.7.23+: Pads the end of the AVI file by expanding the trailing 'JUNK' chunk, increasing the filesize by the number of bytes specified. If the trailing 'JUNK' does not exist, it will be created. If the trailing 'JUNK' already exists, it is also possible to "unpad" (truncate) it, decreasing the filesize. Experimental. Use it carefully.
Closes the application.