mencoder.exe has encountered a problem and needs to close

For some reason, every time I attempt to convert an MKV fansub to AVI using my All-To-AVI program, partway through the process I get this:

'mencoder.exe has encountered a problem and needs to close'

Running fansubs which are already in AVI through the program (to make certain they will work on a DVD player) still works normally. I have adopted a policy of not making any changes to my list of programs as long as things are working in a satisfactory way, so I don't see how anything I have done could be behind this problem. It just started happening sometime in the past week. Microsoft advises me to download the latest version of Mplayer/Mencoder for Win32, but like I said I am leery of adding or removing programs when I'm not certain that I know what I'm doing (and I'm not). They make no promises, only saying that it 'might' fix the problem. Also, the new program comes at a fee, and I am unhappy at being expected to pay to fix a problem which I don't think I was responsible for. Somewhere there was a mention of a free trial version, but I'm having trouble finding it again. Does Devil Doll or anyone else have any advice for me?
Thanks

AllToAVI is still a SourceForge project but hasn't had a new release since 2007 - is this what you're using? ↗Mencoder is still a project under GNU license and as such freeware - if that's part of AllToAVI then who is trying to charge you for anything? (mplayer is not to be confused with mplayer2, the commercial player by Microsoft.)

This error message sounds exceptionally vague, and I can understand that you hesitate to upgrade anything without knowing what's going on. But that's exactly why I'm not using these out-of-the-box-can-do-everything-without-thinking solutions - when they fail, you're screwed. There are various discussions in the web about this error message but what I've seen of them is vague as well, from changing some configuration settings of the invoking program (your AllToAVI tool) to cleaning up the registry (by installing another tool for doing that of course...), but with so little diagnostic information about the cause of the problem this would be a pure guessing game.

If every MKV container makes the program fail then it looks like this tool has issues with MKV in general; to check this you might check whether it can handle a rather old MKV container (i. e. an MKV file you downloaded years ago, not necessarily for an ancient anime); I know other programs (good old VirtualDubMod comes to mind) claiming to support MKV but actually handling only a small subset of it, and more recent releases may have made use of more MKV features than older ones. If only a subset of MKV containers were failing then we could inspect them with Mediainfo to find out what's the difference. Then again, this would be what the developer of that software should do, and I'm not sure if this information would actually be helpful for you; if you need to upgrade anyway you probably won't be interested in understanding what the old version wasn't able to do.

I don't know how you installed your AllToAVI tool. Was mplayer/mencoder an integral part of it (so that you perhaps don't even know how to replace that part), or was installing mplayer/mencoder a requirement prior to installing AllToAVI (in which case upgrading that part should be relatively easy, the latest version appears to be from 2010-05-30 so it's still under maintenance and an upgrade every 1-2 years won't hurt)?

I'm still converting MKV to AVI with a somehow cryptic but reliable method that gives me more information and full control in case of any problem. It's probably not that elegant but I use it for years now and it never let me down. If you're interested in the gory details, just say so. (5 tools and the XviD codec required, plus a certain amount of manual work for each file conversion.) There are times when I wonder whether I should try your method... but using a tool that's out of maintenance since 2007 and then expect it to be able to handle 2010 data with a significant amount of intelligence sounds not that encouraging to me. (Don't get me wrong: The tools I'm using are much older, my AVI container creator is even out of maintenance since 2003, but each of them has to do just one relatively simple task, and it's me who glues everything together, not a software.)

Then again, just today I did some search for stand-alone players supporting HD resolution, MKV and H.264, resulting in some device for under $250 claiming to support all that. (No explicit mentioning of SSA subtitles though, but before purchasing anything like that I'd certainly make some test DVD and let that play in the shop, at the risk of testing not enough formats... ↗MP4 containers would be one thing to check as well, that's what some fansubs are creating as "IPod compatible" format recently.) Even Blu-Ray players are on the verge of being affordable these days, so checking which formats they can handle might be a project for the near future. Sony Playstation 3 claims to be able to play MKV containers and H.264 video streams but they still require some conversion of the transport stream as I've been reading.

Thanks for taking the time and trouble to write this detailed reply. I dug up an old MKV fansub of Gallery Fake, which must have been sitting around in my IOMEGA harddrive for several years, and attempted a conversion to AVI. To my surprise, the conversion went all the way to 100% without any mencoder problems. The converted episode seems to play just fine.

I'm pretty sure that mplayer/mencoder must be an integral part of AllToAVI. I don't remember being required to install any software to assist it. When it began malfunctioning the thought that went through my head was 'what the hell is this mencoder thing?'

About the 'cryptic but reliable method', I guess I would say that if all else fails, I would be interested. 'Reliable' is always nice.

Here's the MediaInfo report on the Gallery Fake episode (still in MKV form):

General #0 Complete name : C:Documents and SettingsOwnerMy Documents[MUJI]GalleryFake_14_5631544A.mkv Format : Matroska File size : 170 MiB PlayTime : 24mn 30s Bit rate : 970 Kbps Movie name : Gallery Fake - Episode 14 - Beyond the Passage Encoded date : UTC 2008-02-02 10:00:50 Writing application : mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:40:07 Writing library : libebml v0.7.7 + libmatroska v0.8.1 Cover : C017000D.TTF

Video #0 Codec : MPEG-4 AVC Codec/Info : MPEG4 ISO advanced profile PlayTime : 24mn 28s Width : 704 pixels Height : 400 pixels Aspect ratio : 16/9 Frame rate : 23.976 fps Language : Japanese

Audio #0 Codec : A_AAC Channel(s) : 2 channels Sampling rate : 48 KHz Language : Japanese

Text #0 Codec : ASS Codec/Info : Advanced Sub Station Alpha Language : English

Chapters #0 Language : English 1 : 00:00:00.000 Opening 2 : 00:01:30.007 Part A 3 : 00:12:28.039 Part B 4 : 00:22:29.932 Ending 5 : 00:24:00.022 Preview


Here's the data on a recent fansub which has failed to convert at least twice due to mencoder problems:


General #0 Complete name : C:Documents and SettingsOwnerMy Documents[FFFpeeps] Shinryaku! Ika Musume 03 720p6E3A0F11.mkv Format : Matroska File size : 299 MiB PlayTime : 24mn 14s Bit rate : 1725 Kbps Encoded date : UTC 2010-10-20 22:40:45 Writing application : mkvmerge v2.0.2 ('You're My Flame') built on Jul 3 2007 05:59:18 Writing library : libebml v0.7.7 + libmatroska v0.8.1 Cover : adobeheitistd-regular.otf / bellcentennialstd-namenum.otf / blackout.ttf / chinacat_0_pl.ttf / crccghkm_0.ttc / hgrpp1.ttc / ihatecomicsans.ttf / kozgopr6n-bold.otf / kozgopr6n-medium.otf / kozgopro-heavy.otf / kozgopro-medium.otf / mikachanall.ttc / segoepr.ttf / ulove.ttf

Video #0 Codec : MPEG-4 AVC Codec/Info : MPEG4 ISO advanced profile PlayTime : 24mn 12s Width : 1280 pixels Height : 720 pixels Aspect ratio : 16/9 Frame rate : 23.976 fps Title : Video Language : Japanese

Audio #0 Codec : A_AAC Channel(s) : 2 channels Sampling rate : 48 KHz Title : Audio Language : Japanese

Text #0 Codec : ASS Codec/Info : Advanced Sub Station Alpha Title : Subtitles Language : English

Chapters #0 1 : 00:00:00.000 Opening 2 : 00:01:39.474 Part A 3 : 00:08:04.442 Part B 4 : 00:14:40.463 Part C 5 : 00:22:19.505 Ending 6 : 00:23:50.471 Preview

Thanks again for your trouble.

Two apparent differences between these containers:

• The newer one has various fonts of different file types for the subtitles (so that they are displayed as intended even if you don't have these fonts installed on your PC) whereas the older one contains only one TrueType font. I remember a tool of mine (MKVextractGUI) having problems even with TrueType fonts in MKV containers (and replaced my tool by some newer one recently), so that would be my first candidate for linking the problem to.
• The attribute tag names such as "Language" vs. "Audio Language" of Matroska components (i. e. streams) are different between both files.

Ever since I learned how to use AllToAVI it has gone without saying that I needed to specify '0 Eng' for subtitles, or else I would get no subtitles at all by default. After reading your post the thought occured to me that maybe doing this was now conflicting with a more complex way that modern MKV fansubs handled subtitles--maybe even in default mode I would now get some subtitles. So, I tried running the FFFPeeps Shinryaku fansub through AllToAVI without selecting 0 Eng. But it didn't work, the usual mencoder problem occured withing a minute.

I used the search device to track down mencoder and got these results:

MENCODER.EXE-069F8DDA.pf in folder C:/WINDOWS/Prefetch

mencoder.exe in folder C:/Program Files/AllToAVI/bin

I looked through my BitTorrent files and wondered why episode 1 of Shinryaku, which I had downloaded in MKV mode from HorribleSubs, had converted without trouble a couple of weeks ago. I re-downloaded the MKV version to see if it would convert successfully a second time. To my surprise, it did. Here's the data:

General #0 Complete name : C:Documents and SettingsOwnerMy Documents[HorribleSubs] Shinryaku! Ika Musume - 01 720p.mkv Format : Matroska File size : 277 MiB PlayTime : 23mn 54s Bit rate : 1620 Kbps Encoded date : UTC 2010-10-09 19:34:43 Writing application : mkvmerge v4.0.0 ('The Stars were mine') built on Jun 6 2010 16:18:42 Writing library : libebml v1.0.0 + libmatroska v1.0.0 Cover : Mercurius-Medium.otf

Video #0 Codec : MPEG-4 AVC Codec/Info : MPEG4 ISO advanced profile PlayTime : 23mn 43s Width : 1280 pixels Height : 720 pixels Aspect ratio : 16/9 Frame rate : 23.810 fps

Audio #0 Codec : A_AAC Channel(s) : 2 channels Sampling rate : 44 KHz

Text #0 Codec : ASS Codec/Info : Advanced Sub Station Alpha



Maybe it's not all MKV fansubs that no longer convert, just some of them. If the HorribleSubs version of Shinryaku episode 1 worked, maybe episode 3 would as well (I found episode 2 in AVI). I downloaded that one as well, and yes, it worked as well. Something about HorribleSubs doesn't cause mencoder problems.
Thanks again.

Edited on 10/25/2010 12:10 PM.

This link shows a query result for video conversion tools by some video helper community, with parameters "MKV to AVI" and "encoder AVI/WMV". It does list AllToAVI as first entry but highlights "no longer developed", indicating this might not be the best choice with a long-term perspective.

Of the alternatives, I have seen the name of HandBrake mentioned in several places with positive comments but this might be too large a tool for my taste.

http://mkv2avi.deanbg.com/ would be closer to what I'm looking for (a compromise between usability and flexibility and still under maintenance). I downloaded this one (it requires AviSynth which I had already installed and use in my own procedure as well) and tried to let it convert your MKV file; it was an interesting experiment to see which set of tools this one is using but as this program ignored the subtitles (despite explicitly detecting them in its MKV container analysis phase; the program claims to "support subtitles" but can't handle SSA which are used in all fansubs these days) it turned out to be unusable for our particular purpose. Sadly this is what I expected: One deficit alone can kick out such a monolith from the list of possible solutions (while the only thing missing is one additional library plus one additional line to invoke it in the AviSynth script generated on the fly by this tool). The GUI as such looked nice even though it failed to explain many of its settings.

My method successfully converted your file. Splitting the container plus installing the fonts took about one minute, Audio conversion took about one minute, video compression (resizing 1280x720 to 704x396, adding subtitles, XviD/1-pass encoding to 999 kb/s i. e. 200 MB file size) took 18 minutes for this episode (on a PC with Q8200/2,33GHz quad core cpu). Add about 2 minutes of manual handling to that (some file selection dialogs, setting XviD quality and video resizing values, plus copying the MKV file's name into a text file for the AviSynth script), part of which would have to be done only once when converting a whole series.

"Writing library : libebml v1.0.0 + libmatroska v1.0.0 Cover : Mercurius-Medium.otf" - Horrible subs used more recent libraries to create the MKV container, and they use only one font file, the latter still being a potential reason for the difference (maybe this was limited in earlier MKV implementations?)

It is looking like adopting your system would be what's best for me.

Well, then let's begin. First step: Enabling you to split any MKV container into streams and save these as separate files (in order to process them further by other tools in some later stage). For this you need two software components:

• MKVtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows, installation program, latest version 4.3.0 from September 2010). Download and install it into any directory of your choice. (This will create an entry in your Windows configuration, i. e. appear in the list of all installed software; from there you can uninstall it again if you want.) You won't execute these (command-line) programs directly but they have to be there in order to be used by some other program:
• MKVExtractGUI-2 (http://sourceforge.net/projects/mkvextractgui-2/, ZIP archive, latest version 2.2.1 from September 2010). Download this archive, extract its content (one program file MKVExtractGUI2.exe, one text file), then copy the program file into the same directory where MKVtoolnix has been installed. (This program doesn't modify anything in your system and can be deleted manually anytime.) This is a simple graphic user interface over some subset of the MKVtoolnix components, only for splitting a MKV container (MKVtoolnix can do much more such as creating MKV files but we don't need that here).

I downloaded MKVtoolnix--the 'installer' rather than '7zip archive' version. I then downloaded MKVExtractGUI-2. Is putting them both in 'My Documents' the same thing as in the same 'directory'? I opened up the MKVExtractGUI-2.2.1zip file and was urged to purchase a WinRAR license--does that have anything to do with what we are trying to accomplish? Apparently a 40 day trial period is underway. I 'closed' that message and selected 'Extract to the specified folder' for the 'application' and 'text document' files. I see that a folder entitled MKVExtractGUI-2.2.1 has been created to house them. I clicked on the fancy MKVExtractGUI-2 thumbnail, selected 'Open', and got an error message: "MKVExtractGUI-2.2.1 ("Resurrection") Put me in MKVtoolnix dir, please!" I could just click on 'OK' and this would be done for me, but it sounded like I might be duplicating a step from the MKVtoolnix download. Maybe what I need to do first is complete the MKVtoolnix setup process. This went quickly, and what I got at the end was 'mkvmerge GUI v4.3.0 ('escape from the island')' (whatever that means). Anyway, I am running short on time and will need to finish this later.
Thanks again for your help!

Edited on 10/26/2010 11:26 AM.

I assumed you have some tool for extracting ZIP archives; apparently your system is using WinRAR for this purpose, some other tool like WinZIP would have done the trick as well. (I usually prefer archives over installation programs because the latter may do things in my Windows installation that I don't even become aware of, such as creating dependencies amongst different software products or polluting the system registry, and I like to know what I've done in case anything turns out to be broken afterwards; in the case of MKVtoolnix the available archive format would have been ".7z" which I didn't know whether you can handle that - actually you can, with WinRAR.)

mkvmerge GUI v4.3.0 (a graphic user interface over MKVtoolnix programs to create MKV containers) isn't exactly part of what we're trying to accomplish. But Matroska is aiming at container creators first and foremost, and so this GUI (under the file name mmg.exe) has made it into the MKVtoolnix package while the split-only GUI named MKVextractGUI-2 has not (thus we have to install the latter separately). At least the start of this merge GUI indicates that the first part of the installation appears to have been successful.

I dislike the way how Windows (program manager, start menu, desktop etc.) hides actual directory path names by fancy icons; in our particular situation the directory names are essential as the MKVextractGUI-2 assumes to be copied into the MKVtoolnix directory (which has to exist beforehand so yes, you had to complete that first) in order to find the MKVtoolnix programs (without you having to configure their path into the GUI program). Its not the downloaded files that need to be in the same directory, it's their content (after extraction resp. installation); the downloaded files themselves can be deleted after the process (I move them into some directory structure named "archives" where I can easily check which versions of which software I have installed, what their creation date was i. e. when I did that installation, and burning them on some DVD gives my next PC the complete set of downloads I need to put it in the same state as its predecessor instead of me searching the web for all those files again).
When I installed MKVtoolnix the first thing I was asked was the directory path where this product should be installed to. This is the path where the file "mkvextractgui2.exe" (which you extracted from the ZIP archive) needs to be copied/moved to in order to find its required MKVtoolnix environment. If you don't remember this path you can search for the file "mmg.exe" (or maybe even look into the attributes of the icon for this program).

After we've through with splitting MKV containers the next step will be converting audio streams to MP3 (or whatever audio format you DVD player can support best but let's start with a safe bet), so you might want to check whether you already have some tool for that or need to install one. (Reusing programs you're already familiar with might make the whole process easier for you, and the fewer tools you need to install the less you have to learn about using them. That's the inherent trade-off between installing lots of tiny, easy-to-use tools exactly appropriate for the task and installing a few ultra-flexible can-do-anything tools with myriads of configuration settings - if you actually use the latter ones for lots of different tasks they can be the better alternative as you have to learn using them only once.)

It looks like I guessed wrong when I chose between the 'installer' and '7zip archive' versions of MKVtoolnix; I hope the choice doesn't come back to haunt me. I went back to 'put me in MKVtoolnix dir, please!' and clicked 'OK'. A list of MKVtoolnix-unicode options appeared and I got the feeling that I had no idea what, if anything, to do with them: http://www.bunkus.org/videotools/mkvtoolnix/win32/

I performed a search for mmg.exe and got these results:
mmg.exe (in folder) C:/Documents and Settings/Owner/My Documents/MKVtoolnix
mmg.exe (in folder) C:/Program Files/MKVtoolnix
MMG.EXE-03E952C0.pf (in folder) C:WINDOWS/Prefetch

BTW, As I look through my list of programs I see that WinRAR is listed there. I know I've heard of WinRAR before, and if programs are listed in the order I acquired them, then I must have had it for some time because there are four programs, plus MKVtoolnix, listed afterwards. But trying to activate it brings up the reminder that I have a temporary trial version and ought to buy a license. Also, I've got something called 'Haali Media Splitter', if that makes any difference to what we're doing.

If you can run mmg.exe and have MKVtoolnix listed in your installed software list then the first step ought to have worked. Which method of installation you chose is not that important as long as it leads to the desired result. (The fact that the download page offers both methods indicates that both roads lead to Rome.)

C:/Program Files/MKVtoolnix looks like the directory where you apparently installed MKVtoolnix to, so this would be where mkvextractgui2.exe has to be moved to. Only after this operation the "put me in MKVtoolnix dir" message of mkvextractgui2.exe will vanish and this GUI will become usable (as the actual data manipulation is done by MKVtoolnix, the GUI does nothing but displaying fancy graphics, handling mouse events and invoking external programs whose location it needs to know for this purpose).

The Haali splitter (which is probably necessary for playing MKV containers on your PC) is kind of a prerequisite for the whole idea we're following, which I didn't state explicitly so far. Let me make up for this: The goal is to make every video file that you can already watch on your PC convertible to a file you can play on your standalone DVD player. (And you can take that literally as we will in fact be using the same mechanism as the video player program at some point.) Which means: Your PC has to already support the container type (MKV) as well as the video codec (H.264) and the audio codec (might be AAC, AC3, OggVorbis or whatever). This implies that the software enabling your PC to do that must have been installed beforehand - which I assumed as a given. And Haali is in fact one ingredient for this prerequisite as it is one system component that on the fly splits MKV and MP4 containers into streams and forwards these streams to the corresponding codecs which then forward their output (decompressed video, audio + subtitles) to the video player program. As we're currently trying to permanently split MKV containers into separate files one might think we won't need that feature but as you will see soon enough we will be relying on this "dynamic split" concept later (as it makes certain things much easier).

I am an extremely ignorant computer person, so it took me awhile (and several re-readings of your posts) to conclude that what I needed to do was 'send' MKVExtractGUI2.exe to 'Local Disk (C:)', because that's where 'Program Files' are located. I was unnerved by the message 'These files are hidden' which lay inside Program Files, and implied that I shouldn't make the slightest change; but I noticed that the short list of sample files which appeared when I left my mouse on it included AllToAVI, so these weren't entirely files critical to basic computer operation after all. So I moved MKVExtractGUI2.exe inside as well. Then I attempted to actvate MKVExtractGUI2.exe (from 'My Documents', since I can't enter Program Files). But to my dismay I still get the message "Put me in MKVtoolnix dir, please!". Maybe the copy of Extract back at My Documents is still useless while, if I could figure out how to activate it, the one in Program Files would work properly. But I suspect that just placing Extract in Program Files isn't the same thing as adding it to the directory of Merge. The thought occured to me that maybe I should be moving Extract to 'Downloaded Program Files', which lies within C:/Windows, but I won't try that yet. I am unfamiliar with the concept of 'directories', and maybe that's why I'm doing something wrong.

"Directories" and their synonym "folders" are a concept of building hierarchies on any storage device you can imagine; ↗Wikipedia can explain that better than me.

Sending "MKVExtractGUI2.exe" to "C:/Program Files/" (which is a directory "Program Files" inside the root directory on this hard disk) is not the same as sending it to "C:/Program Files/MKVtoolnix/" (which is a directory "MKVtoolnix" inside a directory "Program Files" inside the root directory of this hard disk). Its the exact position within the tree of directories that's relevant here, so you have to move "MKVExtractGUI2.exe" one directory level lower, i. e. inside the "MKVtoolnix" folder (the same place where "mmg.exe" already exists). You were able to install a program into "Program Files", i. e. create something there (C:/Program Files/MKVtoolnix/mmg.exe, for example), so why would you be denied read access when you apparently have write access? And you need to activate MKVExtractGUI2.exe from inside "C:/Program Files/MKVtoolnix/"; any copy residing elsewhere will never be working (as it won't be able to find MKVtoolnix).

When you're doing file operations (such as "Send"), are you using the Windows Explorer? You could select a MKV file there, then open the context menu (i. e. right mouse click), select "Open with", navigate to C:/Program Files/MKVtoolnix/", and select "MKVExtractGUI2.exe" (after you managed to copy the program file there); once you did that you'll get an additional entry "MKVExtractGUI2" in the context menu for MKV files and don't have to repeat that navigation part for other files of this type. Don't forget to uncheck the checkbox "always open with" in this dialog, or else a double-click on a MKV container will always invoke MKVExtractGUI2.exe instead of your video player program (which is probably not what you want... but fear not, it can be undone if it happens).

I guess I was afraid to fool around with a file with such an ominous warning unless you reassured me that it was OK and I hadn't done anything wrong up to that point (I confused can't go in there with possibly shouldn't). However, now I muster my courage, enter 'Program Files' and drag and drop MKVExtractGUI2.exe into MKNtoolnix. Now I enter MKVtoolnix, find Extract inside, and attempt to open it. This time I get a screen entitled MKVExtractGUI v.2.2.1.0 "Resurrection" with blanks for 'Input File' and 'Output Dir' and a big box for 'tracks' (somehow this reminds me of 'DVD Audio Ripper 4').

I select the FFFPeeps Shinryaku fansub as the 'Input File', and C:/Documents and Settings/Owner/My Documents appears by default as the 'Output Dir'. I'm inclined to push the 'extract' button at the bottom of the screen, except an hourglass icon has appeared above my mouse and isn't going away. At the very bottom the message 'executing mkvinfo...' is being displayed.

BTW, I tried to watch some of the MKV fansubs which refuse to convert to AVI on my PC, and I notice that a common problem seems to be that I get a gray colored screen, which is broken up into a grid of small square shaped sections. Occasionally a handful of these square shaped sections, scattered at random across the screen, do show me part of the video image, but I'm only getting a brief peep at a tiny part of the entire image for a fraction of a second. However, the subtitles work just fine and are displayed atop the gray background.

OK, the 'executing mkvinfo' step has been completed and a list has appeared of Tracks 1, 2, and 3, something like a dozen 'attachments', and 'Chapters: 6'.

Sorry it has taken me so long to get this far.

Edited on 10/27/2010 04:37 PM.

No need to apologize. It's your system, you have to handle the procedure, so we will go at your pace, and I will try to insert encouraging comments whenever possible. There's a lot of new stuff for you to experience, I'm well aware of this. You now learned what "move file X into directory Y" means; you will see later that at some stage you'll have to do a similar step for another tool.

The grey screen you mention looks like a video that was compressed with some video codec which your PC doesn't support correctly. As long as you can't even play a video stream on your PC it's very unlikely that you'll be able to convert it because the conversion requires the same amount of knowledge about this video's format as playing it; the subtitles in MKV are still a separate stream and interpreted by a separate mechanism so that's quite normal that they work while the video does not. That's part of why I formulated our goal in this particular way: When you have solved the problem of playing the video you'll most likely have enabled your PC to convert this file as well, by making the conversion process as similar to the playing process as possible (at one stage we'll actually simulate the video player program for this very purpose).

Except for mkvinfo being surprisingly slow (I get almost no delay in this situation), everything appears to work, which is good news. So let's begin to make use of this tool. But before this, some words about work concepts.
Do you have any directory that you consider your "work area", i. e. where you put temporary results of any kind? It might be "My Documents" or "My Music" or "My Videos" for you (for me it's "C:/temp/"). As the MKVextractGUI2 is now fully functional, we can extract some of the streams inside the MKV container into separate files; just be sure you know where you put them. If you're not sure where to put these files then enabling the check-box "Source Dir" in MKVextractGUI2, i. e. use the same directory as the one with the MKV file, might be good for your first experiments.
(Unless this would mean that the files we will be creating would "pollute" some directory you consider "final results only". I keep anime archive and temporary work area on separate hard disks, so I would copy the MKV file into my work area before starting to convert it, create all temporary files during one conversion task in this same directory, move the final conversion result to my anime archive or burn it onto a DVD-RW, and finally delete all remaining files in my work area, the last step no sooner than when I know the conversion was successful, i. e. have watched the file on my DVD player, because I might have to redo one of the steps in certain cases and then want to reuse the temporary files from other steps to speed up the process.)

Regarding those many "Attachments" in the MKV container (these are ↗Computer font files, their exact format will most likely not matter for our purpose), let's ignore them for the time being. We might need to return to them later but if that's the case then we will have to do something that requires a little more explanation (plus a tool we didn't install yet), and I want you to be able to see their effect before dealing with them.
The "Chapters" component in the MKV container (which allows the user to directly jump to certain positions within the episode, much like a menu of commercial video DVDs) is of no practical use for our purpose (AVI files can't contain this kind of information) so we will ignore this one as well.

As mentioned above, we well need to extract at least two tracks: The subtitles and the audio stream. (For fansubs like Shinryaku you'll usually find one audio stream and one subtitle stream only so let's not bother with more complex cases at this point in time already...)
Do that now for Shinryaku: In MKVextractGUI2,

1. open the Shinryaku MKV file,
2. select the check-boxes at the left side for audio and subtitle stream (I'm intentionally not telling you their track numbers as the order of the tracks may be different in other MKV files, you need to be able to identify the appropriate streams yourself),
3. click on "Extract".

I guess the closest thing I have to a 'work area' would be the 'Trans' folder, which AllToAVI created to hold fansubs which had undergone (or were undergoing) the transformation to AVI. I consider these incomplete, since they needed a second 'sprucing up' ('Conversion') stage before they were ready to be burned to a DVD. So, I checked 'Source Dir' on MKVExtract, which I notice makes the 'Output Dir' box unusable.

Today, once I selected the Shinryaku fansub the list of tracks, attachments, etc, appeared almost instantaneously. Maybe it was slow yesterday because I was running several different programs simultaneously. Audio and subtitles would clearly be tracks 2 and 3. The message 'extracted ok' has appeared at the bottom of the MKVExtract screen. Where exactly the extracted tracks are is unclear, but I go to 'My Documents' and am relieved to find them there. So far so good.

I have downloaded 'Switch'. Do I need any of the 'Related programs and extras', like 'WavePad Audio Editor' or 'RecordPad Sound Recording Software'? The Switch ad was odd; you could readily download it for free, yet you are asked to purchase it as well.

Edited on 10/28/2010 11:40 AM.

None of the "related programs" is necessary, Switch alone is sufficient for your purpose. Switch has a "Pro" version that can be purchased; the free version doesn't support some advanced features (such as the "↗Joint Stereo" variant of MP3 where both stereo channels can be merged together, resulting in a slightly better compression factor due to eliminating some redundant information; using normal MP3 stereo is almost as good so no need to purchase the Pro version for this feature alone).

You sound as if you already installed Switch (the location of its installation doesn't matter this time), so we're progressed further than I expected.

Switch, like the extract GUI, has a check-box "Output to same folder as source files", which you might want to select.

If you have Switch up and running, the next step would be: Convert the extracted audio stream to MP3. The Switch default settings (including the "Encoder Options" for MP3) are fine for your purpose, so you just need to

1. start Switch,
2. "add file" for the Shinryaku AAC audio stream file you created before,
3. set "MP3" as "output format" (unless that's the default setting already which I don't remember), and
4. click on the big "convert" button.

I couldn't remember whether audio was track 2 or 3, so I thought I'd see if I could open the extracted track 2 (with the orange lightning bolt icon) with something like Media Player Classic. I guess the fact that it was marked with that icon might have tipped me off that I was on the right track (an unintentional pun there). The option 'Convert With Switch Sound File Converter' was at the top of the track menu, and I selected it, so I think I did it the same way you do, even on the first try. The conversion seems to be a success; the mp3 version of the track plays just fine on Media Player Classic.

Now that we have a converted audio stream, a quick interlude to make a plan for the next steps.

We'll have to do a few more things to get our AVI container:

• We need to be able to read the video stream (that's still in the MKV container as it didn't make sense to extract it, you'll soon see why),
• we need to be able to overwrite this video stream with subtitles (as AVI cannot contain subtitle streams, so we have to permanently modify the video content),
• we need to be able to compress the modified video stream with a codec that your DVD player supports (XviD), and finally
• we need to merge the modified video stream plus the converted MP3 audio stream into an AVI container.

1. ask you for a language of your choice (which is not really important for us, you'll probably select English),
2. asks for accepting the GNU license (which you need to do),
3. asks for configuring the installation type (leave it as it is, the default setting is okay for our purpose),
4. asks for selecting an installation directory (the default setting is okay but you may choose whatever path you like), and finally
5. offers an "install" button (clicking on which begins the actual installation).

Avisynth_258.exe has been downloaded and installed successfully. I'll need to re-read your detailed explanation once or twice before I 'get' everything, though.

Fine. Take your time with reading, and perhaps read the whole thread once more when we're finished with everything. Some steps might be easier to understand after you've seen the results they allowed us to get.

Now what does AviSynth actually do for us? It reads a script file and executes the commands given there, which results in creating a data stream in the form of... a "synthetic" AVI container (hence the name of the tool). We don't have to open the script file with AviSynth; instead, Avisynth will be activated by Windows every time when anyone opens a file with the extension "*.avs", and AviSynth will get control over the process of reading this file, thus being able to "fake" its content by actually computing it on the fly.
So we'll write a script and "open" this script by any application that can read AVI containers, as AviSynth will send data in this format as if the script file were an AVI container itself. One of these programs might be... your video player! Just to check whether AviSynth works correctly of course, as it's the easiest way of making the AviSynth output visible to you. (And of course your video player program "knows" how to read AVI containers - it just passes their content to the splitter...)

By now we have split up the task "transform anything to AVI/XviD/MP3 with subtitles" into four parts:

1. Extract audio and subtitles from the container (mkvtoolnix, MKVextractGUI2)
2. Convert the audio stream to MP3 (Switch)
3. Read the video and transform it into uncompressed data (splitter + codecs, i. e. making maximum use of the PC's available video abilities, AviSynth only working as interface)
4. Create an AVI container with the video being compressed and subtitled plus the MP3 audio stream (tool yet to be installed, will look and feel much like AllToAVI except that it only does "uncompressed standard format to AVI" and as such is independent from the original video file)

• open the text editor of your choice,
• write one line (see below for the format of this line), and
• save it to a file whose name must have the extension "*.avs".

DirectShowSource ("[FFFpeeps] Shinryaku! Ika Musume 03 [720p][6E3A0F11].mkv",audio=no)

"DirectShowSource" is the AviSynth function sending the MKV file to the splitter and receiving whatever uncompressed data streams the codecs will return after doing their job; "audio=no" means we don't want the audio stream (which we need in MP3 format anyway and had to convert it separately already). That's it. We don't have a file select box available in this script language therefore we need to write down the file name explicitly.

Note that we could get the audio if we wanted, so if the container were less easy to split than MKV we could have taken the uncompressed audio stream from here (regardless of its original format in the MKV container, even a format our audio converter Switch doesn't know!), save this audio stream to disk (using the one last program we don't have installed yet), and convert it to MP3 (using Switch). If you ever see a video file with a fancy file name extension ("*.mp4" or "*.wmv" being likely candidates), this would be the method dealing with its container format (as there might not exist an "extract" tool for some of these formats; in the case of Microsoft formats this is inhibited by their patents, so "playing" these videos through the splitter/codec combo is the only way to access the streams).
The one reason why we needed the MKV splitting stuff is that AviSynth won't give us the subtitle stream (as it can't be part of an AVI container). Also, had we installed AviSynth first and decided to run everything from there it would also have put the "cultural shock" of writing the script file at the beginning of the process; I wanted you to get some sense of achievement right from the start for which MKVextractGUI2 and Switch looked most appropriate.
The set of tools we're installing right now allows for more than one method of handling our task. This is the true strength of this method: If one way fails the other might still work, and if one tool would need to be replaced (which is unlikely because each of them does a fairly simple job) you don't have to learn everything again from scratch, the procedure as a whole will remain mostly intact.

Typing the exact name of the MKV file may look bothersome and error-prone. There are two ways to avoid this:

1. Select the file name in your file manager, "copy" it into the clipboard, and "paste" it into your text editor.
2. Rename the MKV file to a simple, constant name such as "video.mkv", and use one constant script for all conversion operations (which is fine as long as you do one conversion after the other instead of several of these in parallel).

1. Write the script as given above, and save it into a file "Shinryaku03.avs".
2. Open the file "Shinryaku03.avs" with a video player of your choice (Media Player Classic is fine).

I am confused. Would the 'text editor' that I need to use to save the script be a word processor program, like Microsoft Word (which I have)? But saving the script there, as a document, automatically adds the suffix '.doc', which I would think would keep '.avs' from being recognized by AviSynth. And I can't open a document with Media Player Classic, can I?

I thought maybe what I needed to do was rename the FFFPeeps Shinryaku file as 'Shinryaku03.avs', but doing that brings up the warning "If you change a file name extension, the file may become unusable". To be safe, I made a second copy of that file/fansub, then went ahead with changing the title. The icon promptly changed to the AviSynth one, a folder with a strip of film draped over it! I must be doing something right. I attempted to open it, and noticed that the recommended program is 'Notepad', and the thought occured to me that maybe this is the text editor where the script needs to go. It took several minutes, and I got a supercomplicated batch of computer language stuff which makes no sense at all to me; the entire episode broken down into text, I guess. I then tried to open the retitled fansub with Media Player Classic, but got the usual 'mencoder problem' message.

So I guess the problem is that the script isn't 'readable' by AviSynth since I haven't put it where it belongs.

After thinking for awhile about what I might have done wrong, I 'sent' the Word document with the script to 'Program Files' and placed it in the AviSynth folder, then tried to open Shinryaku03.avs with Media Player Classic. But there is still a gray screen and before long I get the mesage "Media Player Classic has encountered a problem and needs to close". Could it be that the script document needs to go in the 'Docs' ('Documents'?) folder within AviSynth? No, that is not allowed.

Some encouragement first: Using Notepad for writing a text file was the right idea (much better than Word which would by default add some text formatting stuff that we don't want in our script). Making a backup of the MKV container was good as well, as we still need this one under its original name (with the "*.mkv') extension; this name is the one we're about to write into the script after all, and if you rename the MKV file then the script won't be able to find it.

There are files of different content types (such as videos, music, Word documents and whatnot). Windows believes that the user isn't able to understand the difference between these formats and would accidentally use inappropriate programs for manipulating files they're not meant to be able to handle. So it tries to "protect" you from doing something wrong, and the warning message about renaming files was part of this.
You've seen the icon of the file changing when you renamed it. Why did that happen? Because Windows has a table of file name extensions each of which are assigned one particular program that will be started when you double-click or "open" a file of this extension. That's the "default program for this file type". For *.avs scripts this is AviSynth; for *.doc documents this is Microsoft Word; for *.txt files this might be Notepad on your PC; for *.mkv containers it's your video player program. So by renaming the MKV file to *.avs you told Windows that a script is inside, not a video - but this wasn't true. Consequently, neither Notepad nor Avisynth were able to understand the content of this file.

You've "successfully" opened a MKV container with Notepad (though this wasn't exactly what we wanted to do), so you've experienced opening a file with a program different from the "default program" already, which is good (as you'll later use the same method to open the script with your video player). Your method of opening a file with a different program was correct. The location of the file isn't the problem either; instead, it was just the wrong file for this operation. A MKV container doesn't change its content just because you renamed it - it is still a video file, not a script (even though Windows wouldn't be able to know this, hence its warning!).
So what went wrong? We don't want to open the MKV file (regardless under which current file name) with Notepad, as Notepad can't read videos. We want to create a new script file with Notepad, one that's not even existing at this point in time. Later, once you have one such script, you can open it with Notepad and edit it; you can also copy it under different names (such as one per episode number). But for the very first script of yours, there's nothing you can copy it from. (Well, actually you could copy one of the scripts in the "examples" subdirectory of your Avisynth installation... but seeing their content might rather confuse you.)

You know how to open a file with Notepad, but do you know how to start Notepad directly (without it opening a file)? There are several ways of doing this; one would be to look in the Windows "Start" menu where Notepad must be somewhere in some sub-menu. A much faster way would be to select the entry for "starting programs" in this "Start" menu (I don't know the exact English name for this, something like "execute" or "run") which opens a box for selecting a program to be "opened"; there you can just type "notepad" and the "Enter" key, Windows will find it. Or perhaps you even have some Notepad icon on your desktop?

Anyway, let's rephrase your current task (I assume you still have a copy of the MKV file under its original name):

1. Delete the file "Shinryaku03.avs" that you created as copy of the MKV file (just to avoid a warning you'd get later; otherwise, when you'll save the script under this name you'd need to overwrite an already existing file which you'd have to confirm explicitly).
2. Start Notepad. (It will show you an empty buffer that you can type text into.)
3. Get this browser window (the one you're currently reading) as your active window, select the text
   DirectShowSource ("[FFFpeeps] Shinryaku! Ika Musume 03 [720p][6E3A0F11].mkv",audio=no)
   with your mouse, and "copy" it (into the Windows clipboard). The keyboard shortcut for this is Cntrl-C.
4. Return to the Notepad window, then "paste" the clipboard content into its empty buffer. (This way you can't mistype the file name, hopefully.) The keyboard shortcut for this is Cntrl-V.
5. In Notepad, use the menu entry "File" / "Save as" to save this buffer to "Shinryaku03.avs" within the same folder as the MKV container (this is important as we didn't tell the script a full path name of the MKV container, thus it will expect it in the same directory).
6. "Open" the script file "Shinryaku03.avs" with Media Player Classic.

So, simply renaming the Shinryaku fansub wasn't what I needed to do, even if it took on a neat AviSynth icon; I deleted this. I went searching in 'All Programs' and found Notepad under 'Accessories'. I opened it and cut-and-pasted the script into it. I saved it as 'Shinryaku03.avs' at 'My Documents', because I had not yet created a folder to contain it and the fansub. I went to 'My Documents' to do just that. I created a folder which I named 'Shinryaku03'. But for some reason when I attempted to place the fansub inside, I get the message that it cannot be moved because 'it is being used by another person or program'. I'm not running any program (which I'm familiar with) that would be 'using' the fansub, so my thinking is that it must be some sort of conflict with AviSynth, which must already be interacting with the fansub. But that doesn't make sense either, because this is the original version, which has never been retitled, so how would AviSynth 'recognize' it? I try every trick I can think of to create a new file and place the fansub inside it (like doing inside the seperate 'BitTorrents Downloads' folder), but every time I get the same response. Other fansubs ('Milky Holmes' for instance) can be placed in the folder without trouble. I delete the notepad script, thinking maybe now I'll be allowed to insert the fansub, and I'll redo the script afterwards, but that doesn't work either. I had no trouble inserting the Notepad script into the folder. I cannot understand what is going on here. Somehow the fansub cannot be moved to this (or any other) folder. The only trick I can still think of would be to restart the computer altogether.

I try to start the Notepad script with Media Player Classic, and notice that the gray screen, faulty version can be started in this way. So, some sort of link must have been established between the script and the fansub, even though they are not in a common folder.

Edited on 10/31/2010 11:16 AM.

Whatever program might "use" the MKV file (MKVextractGUI2 would be a candidate, or a running AviSynth script that would be correctly referencing that container - did you perhaps doubleclick the fansub after renaming it to *.avs?), this will not last beyond rebooting your PC, so if all else fails I would suggest using this as a last resort to fall back into a defined situation. But before this there are other things to try.

We need either the AVS script and the MKV file in the same directory, or we have to write the full pathname of the MKV container into the script (the latter being a lot more error-prone, you won't be able to use cut&paste then).
If the MKV file is being "used" by anyone and you can't move it, a copy (under the same name in another folder) would do as well. And instead of moving the MKV file you could move the AVS script (whose absolute location is irrelevant, AviSynth will find its script files via their name extension) into the folder of the MKV fansub.

You can do the test of the AviSynth installation with any video file of your choice (regardless whether they are MKV or AVI containers - AviSynth reads everything that your PC can play, remember? Milky Holmes would be fine), you just need to write a "DirectShowSource" call for the exact file name into a script with the "*.avs" extension and place both the script and the fansub into the same directory (i. e. save the script from Notepad directly into the folder of the fansub, that's the easiest method).
All we want to see is that

• video-playing the MKV container and
• video-playing an AviSynth script that executes "DirectShowSource" on that same MKV container

I'm operating on the assumption that placing the fansub in a folder (the sort I can create in 'My Documents') with the AviSynth script will automatically put them both in the same 'Directory'. Is that correct?

I tried moving the script to 'BitTorrents Downloads', where a copy of Shinryaku already exists, thinking that BitTorrents Downloads would act as their folder and directory. I attempted to start the script with MPC, and got exactly the same result as if I tried to start the fansub itself with MPC: gray screen, and within a few seconds the notice that MPC has encountered a problem and needs to close. Another thing I've been taking for granted is that if I did manage to start the script within the same folder as the fansub, I'd get a better result, but perhaps that was a mistake. If our goal was just to get the same result, then that goal has been accomplished. Maybe the problem is with my PC's splitter/codecs, because pretty much all MKV fansubs (except the HorribleSubs ones) won't play properly on the computer itself. Either an MKV fansub both plays on the PC and can be successfully converted to AVI using AllToAVI, or it does neither. Sorry if I didn't make that clear earlier.

For our purpose, "Directory" and "folder" are synonyms in general; I am now trying to use "folder" consistently but may fail occasionally as for me "directory" is a hierarchical concept whereas "folder" is just a symbol to visualize a directory ("directories" were already in use when GUIs such as Windows didn't even exist yet).

And no, my conversion method won't do anything better than the splitter/codec combo; I explicitly stated than we will use their abilities.
There might possibly be a way of bypassing a potential MKV splitting problem if we were able to extract the video stream from the problematic MKV container (MKVextractGUI2 could do that) and store it in some format that AviSynth can read, thus bypassing the Haali features (by not using DirectShowSource, there are other functions for other purposes); I've never done that and am not sure which additional installations this would require (extracting the video stream with MKVextractGUI2 creates a file with the extension *.h264 but my PC can't play this as it doesn't know this container format).
But I wouldn't advise following this path as fixing your general problem of playing MKV containers would be more rewarding and most likely cost less effort. After all, most fans of these recent fansubs can play them so simply upgrading the required components on your PC looks like a better option. And regardless whether AllToAVI itself has a problem or may be affected by a problem of your splitter (depending on how AllToAVI works internally which we don't know), my set of tools won't work unless its prerequisites are implemented, so we're stuck at this point anyway.

Now we have AviSynth up and running but your PC (i. e. splitter plus codecs) unable to play some recent MKV containers in the first place. So we may have to reset the whole discussion.
I can play the Shinryaku episode 3 file; if your PC can't then something in your PC installation may require an update but this has nothing to do with conversion to AVI at all.

Just to be sure your MKV file isn't broken: Did you verify its checksum? That's the "[6E3A0F11]" part of its file name.
I'm using a nice little tool named hashcalc for this purpose - freeware of course, the download is a ZIP file containing a file "setup.exe", asking you for accepting a license and a folder where it will be installed to.
Opening the MKV file with hashcalc will take about 10-15 seconds (for reading 300 MB file content) and then display a window with a number of checksum values for this file; the one in the file name is the CRC32 checksum.

If this checksum is correct and your PC still can't play the video from your MKV container (which is the most likely case as you claim the problem to occur for many MKV files) then we should conclude that either your splitter Haali or your H.264 codec needs an update.
When I'm playing a MKV video on my PC, a small, white icon appears in the task bar; moving the mouse to it shows a tooltip "Haali Media Splitter". If you double-click on this icon you'll get the Haali configuration dialog, showing on its first screen the version number and a copyright year interval (2004-20xy). Which version of Haali from which year are you using?

The latest Haali release (version 1.10.262.12) is from 2010-08-14, i. e. fairly new, with fixes for problems opening certain MKV files. Right now I upgraded my own PC to this new Haali version (my previous one was from 2007); the installation isn't that complex but offers a number of checkboxes where you can enable/disable features that Haali should be responsible for (e. g. splitting other container format as well, such as AVI, MPEG, OGM, MP4, some of which could be done even by certain video player programs - splitting AVI is much easier than splitting MKV). I decided to trust Haali and entitled it to handle every container format while disabling the MKV splitting ability of two alternative components in the process, and so far everything still works on my machine.
I'm not yet advising you to upgrade Haali as this is something not easily to be undone, and influencing as least playing every MKV container on your PC, perhaps even more. Then again, if your PC can play older MKV containers but not the most recent ones then upgrading the component responsible for splitting MKV containers into streams looks like the most plausible reaction.

My previous Haali installation was part of the CCCP package I have installed; if that's the same for you then you might consider upgrading the whole CCCP package instead of just the Haali splitter, if only to know better which products your system relies upon for being able to play fansubs. I did that as well right now, and I'm not really sure whether it is an improvement for me as recent CCCP versions don't ship with Zoomplayer any more, so I have to get familiar with Media Player Classic now... well, it can't be that different, can it?

Edited on 10/31/2010 10:31 PM.

The checksum number on Shinryaku is correct. When I started downloading Hashcalc I was asked again to purchase a WinRAR license. Does WinRAR have anything to do with what we are trying to accomplish? I went through the setup process and dragged the Shinryaku fansub file to the ‘Data’ box. After a little while the correct checksum (‘6e3a0f11’) appeared in the CRC32 box. I have the 'Copyright (C) 2004-2007' version of Haali--getting old, I guess. Is that the same one you just updated from? But you haven’t been having trouble reading MKV files, have you? Maybe the older Haali/CCCP combination can still handle the most recent MKV fansub files. I remember installing CCCP several years ago but running into some problems and choosing to go instead with just Media Player Classic (it was completely uninstalled). I was tempted to go ahead and download the more recent version of Haali, but since you didn’t immediately recommend it, I will wait. Thanks again for your help.

Is it OK to delete things like 'mkvtoonix-unicode-4.3.0-setup.exe' and 'switchsetup.exe' and 'hashcalc.zip'--the setup and zip programs?

Edited on 11/01/2010 03:55 PM.

WinRar is just for extracting archive files on your PC. Downloads for programs will contain many files so they're either an archive (for which you need some extraction tool, not necessarily WinRAR albeit this one does support a myriad of archive formats) or a self-extracting installation program, depending on the releaser of the program in question.
So, for handling videos you don't need WinRAR (albeit I've seen Direct Download pages of certain anime fansubbing groups that offer videos in some archived form because the file server they use has some file size limit of 100 MB so that they need to split an episode into several parts which have to be downloaded separately and concatenated on your PC, both of which are also features of WinRAR; fansubs you get via a BitTorrent client won't give you this kind of hassle) but for installing downloaded software it can be useful. There might be alternatives without such a repetitive message but as long as ↗WinRAR just nags you for money it shouldn't really bother you as you'll be using this tool not that often.

Yes, you may delete downloaded installation programs resp. archives after installing their products. I keep these programs on my PC for two reasons:

• to document which version of which product I have installed at which date (the latter will usually be the file modification date of the installation program), as many of them don't create an entry in the Windows configuration
• to have an older version at hand when a more recent version happens not to work on my PC or ships with fewer features (such as Switch or CCCP, both of which I upgraded during the current discussion thread).

Edited on 11/02/2010 12:54 AM.

I guess I will create a folder to contain startup files. I decided to install the new Haali over the old one. I left all default settings alone. This turned out to be the 2004-2009 version. When the setup was complete, I got the message 'Some files were in use and could not be deleted. They will be removed at the next reboot', (a reference to the old Haali, I guess) to which I clicked 'OK'. So I will restart the computer and see if MKV files play successfully. First, however, I have a dentist appointment.

Well, I checked my list of programs and my Haali version is now labeled the copyright 2004-2009 version, so it must have replaced the older version. The bad news is that Shinryaku is still messed up, with gray screen and all. 'looks like I need some codec downloading as well.

I downloaded DivX H.264 Decoder 5.2.0.26. Apparently I need 'AVS Video Converter' as well. Hopefully the former program lies within the latter one, because that was the one that ultimately downloaded. Like I said earlier, I get uncomfortable when making programming changes since unforseen problems might crop up--like two programs conflicting with each other while I have no idea what's going on.

Uh... wait a minute. This 'AVS Converter' seems like some sort of 'non activated' trial version of a program which they want me to purchase. I don't think it has anything to do with DivX H.264. I swear, I clicked on 'download' for DivX at least three times, and each time was just taken to another screen with another download button, and finally to AVS Converter. That annoys me. I uninstalled it and finally got DivX H.264 to download and install.

HOLY CRAP!! Shinryaku plays properly on the PC! The FFFPeeps MKV version, the one which has always suffered from 'gray screen'. 'looks like it was a codec problem after all. Now, if I'm not mistaken, AllToAVI should be able to convert it to AVI. I've got my fingers crossed...

Well, it looks like MKV fansubs will play on the PC but won't convert to AVI via AllToAVI. Perhaps AllToAVI can't cooperate with DivX H.264. 'Mencoder problems' come up again. It looks like we will need to go back to AviSynth--but at least all the effort you put into explaining that to me will not have gone to waste!

Edited on 11/02/2010 09:16 PM.

First of all, congratulations for working yourself through all these installations. With the majority of MKV fansubs now being usable for you again (for watching on your PC at least), it looks like it was worth the effort.

There is more than one way a codec can be invoked to uncompress a stream. Haali is one way of doing that (and the AVC codec you installed is a Haali filter, i. e. a codec specifically adapted to the Haali interface); AllToAVI apparently doesn't use the Haali interface but perhaps the ↗DirectShow framework, and via this one, the ↗ffdshow package. ffdshow is much older than Haali, and only a codec pack, but it has its own AVC codec. As ffdshow ships with more than 50 integral codecs (video as well as audio) and can do some fancy things (integrated subtitles support) it is still in use.

You did install Haali with its default configuration? Then Haali will not be responsible for splitting AVI containers on your PC; instead, DirectShow might do that (and then commission ffdshow to decode the streams). So when you play an AVI container with your Media Player, two icons should appear in your task bar, a blue one (tooltip: "ffdshow audio decoder") and a reddish/brown one (tooltip: "ffdshow video decoder").
Double-clicking the red "ffdshow video decoder" icon opens the configuration dialog for this component (with a huge number of settings). The top entry on the left side is "codecs" (this page of the configuration is opened by default on my PC after the double-click), showing a table which codec would be responsible for playing which video format. For H.264/AVC (top entry in this list) there's a drop-down menu in the "decoder" column with several alternatives who should interpret these AVC videos; my PC shows "libavcodec", "ffmpeg-mt" or "disabled", of which ↗libavcodec will probably selected. This is what I guess to be the codec that AllToAVI might be using for reading AVC videos, and as your ffdshow installation might be a few years old as well, this will probably not be the most recent version available.
The configuration interface goes unter the name the name "ffdshow tryouts" (which is actually a spin-off project as the original author stopped ffdshow development in 2004); if you scroll down the menu on the left side and select the last entry named "About", you'll get a text that begins with the version number and date of your ffdshow tryouts version; if you then click on the button "Version details" on the right lower side you'll get a list of version numbers for each installed codec, including the "libavcodec.dll" library. How old is your libavcodec.dll? (The one on my PC is version 52.92.0 from October 2010 as I installed the most recent CCCP package yesterday, with ffdshow being a part of it.) You can also search your hard disk for the file "libavcodec.dll" and then get its last modification date which will probably be the date when you installed some product containing ffdshow (but you won't get a version number this way, and you might find several files of this name, not knowing which one is currently in use by ffdshow).

Pondering how to test whether libavcodec.dll can play the video stream of Shinryaku episode 3, I ran into a problem. ffdshow can't split MKV containers; Media Player Classic can't do this either. Haali can do this (so MPC must be using Haali for playing your MKV files) but would then automatically use its own AVC codec. So we would need to extract the Shinryaku video stream (with MKVextractGUI2) and put it into a container type that ffdshow + MPC can handle, such as AVI. In theory this is possible but of little practical use (your standalone DVD player won't be able to play an AVI container with AVC video stream, and a PC able to play AVC will usually be able to split MKV as well), so I've seen it only in a few cases years ago when both AVC and MKV were still new; these days MKV has become the natural and most reasonable container for AVC streams (as soft-subbing has become the standard and AVI can't hold subtitle files).
I don't know a way how to put an AVC stream into an AVI container, so even I would need to experiment at this point. I just brought up this point as I hesitate to suggest installing the most recent libavcodec.dll while I'm not even sure AllToAVI is actually using it. Fixing AllToAVI which you are used to still looks like a reasonable goal (despite all the tools you've installed for an alternative approach); AllToAVI might actually do what I just described, i. e. extract the video stream and read it via some mechanism other than Haali. But this is still a guessing game, much like overwriting the "mencoder" component of AllToAVI by some more recent version; there could well be a different way AllToAVI uses to read AVC streams (such as shipping with its own codec pack to be less dependent on other tools being installed already, much like the ↗VLC media player).

The alternative would be to proceed with my "tools box" architecture approach. You're able to play Shinryaku episode 3 through AviSynth (implicitly using Haali and the updated AVC codec in the process), right? You should test this before installing the next tool.
As for this tool, there are many possible alternatives - actually any AVI container builder program should do, more or less. So... right now I got a funny idea: Try opening Shinryaku03.avs with AllToAVI! Would this be possible? It is an AVI "container" after all. But... can AllToAVI use subtitles and audio streams from external files during its conversion process? If not then you won't get them into your AVI container this way.

My AVI creation tool is ↗VirtualDub, even more so as the current version can do several things that I've been missing in previous versions (and I had been sticking to an outdated variant of this tool because of this); learning about VirtualDub 1.9.10 is what I got as "reward" from this thread. :-)
The download site for VirtualDub offers variants for different operating systems; you'll probably need the first one for 32 bit Windows (the 64 bit version doesn't even run on my Windows Vista64 system). If you want to adapt to my conversion procedure then this would be the last download of a GUI program (there will be one small add-on that we'll need to get subtitles interpreted, and maybe an XviD writer codec unless you have one already, you'll see that when VirtualDub is running). This is my anything-to-AVI converter & video compressor, with AviSynth feeding it uncompressed video while both audio and subtitles are inserted from external files during the process.
Keep in mind that VirtualDub is an AVI container creator only; there might be more powerful video converter tools that would support other output formats (↗MP4 comes to mind, for Apple devices, Playstation 3, and even some standalone DVD players). I happen to have ↗XMedia Recode on my hard disk but somehow never came to use it; AVI containers are all I ever had to create (even for releasing fansubs back in the days).

Edited on 11/03/2010 01:49 AM.

I don't understand why splitting AVI containers (with Haali, for instance) has become a problem. Those never gave me any trouble, either while watching on the PC or running them through AllToAVI. Did I misunderstand, and install the updated version of Haali in a bad manner which can't be undone?

Jumping ahead a bit, I attempted to open the Shinryaku03.avs script with AllToAvi. I got the message ‘The found DivX DirectShow decoder (divx_c32.ax) may be incompatible with the current operating system. Please try to install version 3.11 or 4.0+’ and ‘This message will appear only once per installation’. Nevertheless, I was allowed to attempt the conversion. I got the details, like the bit rate, from the original MKV fansub file, using MediaInfo. The good news is that the program went all the way to 100% complete without any mencoder problems. The bad news is that when I tried to play the finished file using MPC, I got the message 'Media Player Classic could not render some of the pins in the graph, you may not have the needed codecs or filters installed on the system'. MPC posted the message 'Cannot render the file'.

Edited on 11/03/2010 10:49 AM.

No, splitting AVI containers isn't a problem on your PC. It's just that the fact that Haali isn't responsible for AVI containers (which is okay, DirectShow can do this just fine, and Haali itself doesn't recommend being used for splitting AVI containers, hence the default settings of Haali leave this feature unselected) implies that someone else must be responsible for it (as you obviously can play AVI containers), and this leads to you being able to see the ffdshow configuration (invoked via DirectShow) while playing an AVI container (visualized as ffdshow task bar icons), just like you are able to see the Haali configuration while playing an MKV container (visualized as Haali task bar icon).
I was just looking for a way to show you which AVC codec might be used by AllToAVI, as obviously your freshly installed AVC filter for Haali isn't the one being used by this converter. And playing an AVI video with your Media Player obviously must be easier for you than finding the ffdshow configuration somewhere in your huge program menu tree.

Opening Shinryaku03.avs (a virtual AVI container with an uncompressed video stream) with AllToAVI was meant to make the task of decoding the AVC video to uncompressed be performed by AviSynth, leaving AllToAVI just with creating the AVI container plus compressing the video with subtitles, i. e. bypass the AVC reading feature of AllToAVI. I was hoping that this way of doing things would invoke the new AVC filter through Haali, and AllToAVI having no problems with an uncompressed video stream.
The message you got indicates that AllToAVI is opening the virtual AVI container from Shinryaku03.avs through the DirectShow interface (to get it split into streams, which is what we expected) but then attempts to decode the uncompressed video stream by divx_c32.ax (apparently an old DivX codec as filter for DirectShow, one that I don't even have on my PC; it might be part of your Windows installation as Windows ships with some elementary support for these video formats, or perhaps it was installed as part of some codecs pack ages ago), as if AllToAVI wouldn't be able to believe that an AVI container could possibly contain anything other than DivX/XviD (both of which this DivX codec might have been able to decode). If this is true then AllToAVI can't use uncompressed AviSynth output (due to making wrong assumption about its format, i. e. not being flexible enough to just check the format before choosing a codec). With this warning (of which I don't even know who exactly sent it) I'm not surprised that the conversion result isn't perfectly playable. But I wonder whether upgrading to a more recent DivX codec might get rid of this message. (One more reason for using CCCP which is one set of tools that has been tested to work together without conflicts.)

When locating the root of a problem, the first thing to do is: Isolate possible causes by separating operations (which is the core philosophy of my tools box approach). Apparently we tried too many things at once; I can't even locate whether the root of this warning is within AviSynth or within AllToAVI. So before doing anything else, please try playing Shinryaku03.avs with your Media Player Classic. If this works (i. e. you can see the video stream without a warning) then we should complete installing my tools set and leave AllToAVI aside; if it doesn't then we would need to fix this first (albeit I have no idea why this should happen inside of AviSynth).
Just to confirm what I wrote at the beginning of this posting, playing Shinryaku03.avs with Media Player Classic should show both the Haali and the red ffdshow icons in your task bar, as Haali is being activated by Avisynth (for splitting the original MKV container) and ffdshow is being activated by Media Player Classic (for rendering the video from the virtual AVI container created by the AviSynth script); you won't get to see the blue ffdshow icon as we suppressed the audio stream in the AviSynth script, so Media Player Classic doesn't need to activate an audio filter for the AviSynth output.

Edited on 11/03/2010 02:24 PM.

Let me try to get caught up: after looking around a little, I see a blue 'ffdshow audio decoder' icon at the bottom of the screen while using MPC. But there is no reddish/brown video decoder one. Instead, there are icons for 'DirectVobSub' and 'Haali Media Splitter' (and a couple of others which I'm pretty sure have nothing to do with MPC). I'm guessing that this will reveal something to you. I ran a search for 'ffdshow video decoder' and got the answer 'Search is complete. There are no results to display'. So, somehow I seem to have the audio but not the video ffdshow decoder. I did another search for just 'video decoder' and got three results: 'Video Decoder Configuration' (if I put my mouse on it the message 'location: C:WINDOWSSystem32' appears) in folder 'C/Documents and Settings/All Users/Start Menus/Programs/K-Lite Codec Pack/Configuration/ffdshow'. The other two appear to be two identical copies of the DivX H.264 download program. But all three are download/start-up programs, not the video decoder program itself, right? Has DivX H.264 taken over as the video decoder, but doesn't have an icon?

Edited on 11/03/2010 05:43 PM.

I don't know what exactly "running a search" means in your particular context; if you intend to search for the file that implements ffdshow on your PC, its name is "ffdshow.ax" (that might well have been installed as part of the ↗K-Lite Codec Pack on your PC which is kind of an alternative approach to CCCP, and installing both on the same PC might in fact lead to conflicts).

Your posting doesn't contain the information which video file you were playing, and thus reveals not that much to me. ↗DirectVobSub is a filter for DirectShow that interprets subtitle scripts (i. e. computes frame numbers within a video stream from the time stamps in the subtitle script, reads the font files for the letters to be visualized, and transforms the subtitles into pixels) so that the result can be written on the fly over each frame of the decoded video stream (which component does this overwriting, I don't know exactly).
So I'm guessing you played the original MKV container (which in fact requires Haali for MKV container & AVC video, plus someone handling audio and subtitles) but not the Avisynth script (which has neither audio nor subtitles, thus invoking these two filters should not have happened).

The DivX H.264 a.k.a. AVC codec ("DivX" here means ↗DivX, Inc. who released this codec, competing with ↗CoreAVC; "AVC" = "Advanced Video Coding" is the common name of a format whose technical specification is named ↗H.264/MPEG-4 AVC) is a filter for Haali, it doesn't have its own user interface (there's nothing about the way of decoding an AVC video stream that you would possibly want to configure while playing a video; if you actually intend to fine-tune the interpretation of AVC you will find a configuration tool in your programs menu), but as you see the Haali icon, this AVC codec (whose installed form is a file named "DivXDecH264.ax") is likely being executed for this video.

The procedure of splitting a video container depends (amongst other things) on the format of said video container and the streams inside, thus different applications (splitters resp. codecs) will be invoked for different video files. And sometimes this will even depend on your system configuration - for example, Haali can split AVI containers but whether Haali will be invoked when you play an AVI container depends on whether Haali was configured to do this (that's why I referred to you using the default installation setting which configures Haali to handle MKV containers but not AVI containers, thus leaving AVI containers being split by someone else, most likely DirectShow). So if you play an AVI container with your Media Player you'll most likely see the reddish/brown icon but no Haali icon.

I ask again: Are you now able to play Shinryaku03.avs with your Media Player Classic without problems (i. e. see the video stream without audio & subtitles)? This is the prerequisite for the next step, which would be installing VirtualDub 1.9.10.

Oh, I was thinking that when I played the original Shinryaku fansub but didn't get the ffdshow video decoder icon, then I must be missing a program which you thought I already had, and once that was made clear everything would make sense to you. But apparently not. And I clearly don't understand exactly what a 'search' is capable of. Anyway, when I play an AVI fansub, I still get the audio decoder icon, but neither video decoder, Haali nor DirectVobSub ones. And yes, when I open the Shinryaku03.avs script a video version without audio or subtitles plays without trouble.

Edited on 11/04/2010 10:03 AM.

Its not (just) the installed programs, it's the content types of the container/streams that the number of icons depends on. The original Shinryaku MKV container is split by Haali and decoded by a Haali filter plus some VobSub for the subtitles, so it won't need ffdshow for playing the video stream. An AVI container is split by DirectShow and decoded by ffdshow codecs but has no separate subtitle stream (i.e. no VobSub necessary), so I expected the corresponding icons to pop up (buy actually this is configurable within ffdshow so maybe you have switched this icon off by default).

Anyway, with Shinryaku03.avs being playable, let's go to http://virtualdub.sourceforge.net/ and download the 32-bit stable release for VirtualDub 1.9.10 as ZIP archive (but read this whole posting before proceeding).
Extract the content of this archive to a folder of your choice (no installation dialog this time but you'll probably have WinRAR nagging you again); you should have permanent write access to this folder (as some operation of VirtualDub will need to create a temporary file there later, a list of jobs when you want to schedule several conversion tasks for automatic batch processing).

To test whether VirtualDub is working, open Shinryaku03.avs with virtualdub.exe. It will take a few seconds to let AviSynth buffer the streams, just like when you opened Shinryaku03.avs with your media player. The screen should look similar to a video player; the scrollbar at the lower edge is for moving around in the video; all icons there have tooltips explaining their function. You'd be able to position frame by frame easily (this is how I'm doing screenshots when the exact frame is important).
If you see a black resp. green screen instead of the video image (right now I'm experiencing some weird buffering/delay effects with VirtualDub 1.9.10), click on the Haali splitter icon in the task bar once; does that change anything?
In VirtualDub, click the right mouse key on the video you see, opening a context menu. Set the "Zoom" value to 25%. You'll now see that there are two video screens (the second one probably was scrolled outside your screen as Shinryaku has a large video resolution that will likely fill your whole monitor). The left screen is the video as VirtualDub gets it, the right screen is the video as VirtualDub will output it to a file. We will be doing video transformation in VirtualDub (resizing and subtitles), so you will be able to see the difference between input and output before actually starting a conversion process (e. g. see that the subtitles have been interpreted correctly). Again, scroll around in the video. Can you now see the video?

This buffering issue (that requires me to click on the Haali icon to update the video display) is kind of annoying me; my ancient VirtualDubMod can handle the same AVS script without this effect. VirtualDub 1.9 is a brand-new experience for me as well; if you experience the same effect we might think about using VirtualDubMod 1.5.10 instead (which I tried to avoid as I wanted to have you use only tools that still are under maintenance).
Right now I found a setting in the VirtualDub preferences configuration that apparently fixed this delay issue but requires DirectX 9 (which itself may depend on your Windows version); we can try this if necessary on your system.

As I downloaded VirtualDubMod I was thinking that I would need to extract nine different files to get everything, but apparently extracting the '..' folder gave me everything all at once. I didn't see any mention of 'permanent write access' options, so I extracted with default settings. Opening Shinryaku03.avs went smoothly; the first frame of the episode appeared promptly and I didn't encounter any black/green screens. When I set 'Zoom' at 25% (and maximized the size on my viewer) I get a relatively small screen at upper left and a much larger one on the right. The thought occurs to me that perhaps the right screen needs to be set at 25% Zoom as well, and sure enough that gives me two equal sized screens. I notice that clicking 'Input Playback' causes the left screen to play the episode while the right one remains paused; but clicking 'Stop' causes the right screen to become identical to the left one. Anyway, the download, setup and test seem to have been successful.

So did you install VirtualDub or VirtualDubMod? Which version number? It won't be essential for this posting but might be for the next one (even more so as I may have misinterpreted one of the additional features of VirtualDub 1.9.10 which might force us to still use the "olde" VirtualDubMod 1.5.10 instead).

Input playback is much easier than running each video frame through whatever list of transformations VirtualDub was told to perform on it, so updating the output window will usually require much more CPU power than updating the input window, hence the effect of the output video being updated only when "play input" stopped is intentional. (You may try "play output" at the end of this posting when we have at least one filter activated, it might be significantly slower and bring a lot more CPU load on your PC.)

I only shrink the left (i. e. input) screen to 25% as this is the one we don't actually need (so 6% would be fine as well) whereas I leave the right (i. e. output) screen as large as possible. The zoom value of your choice may depend on the screen resolution you're using for your PC monitor - just set the zoom so that you can still see the complete video frame. Shinryaku came in HD resolution, so you'll probably be using something between 50% and 75%.

Having opened Shinryaku03.avs in VirtualDub[Mod], you could select the menu entry "File" / "Save as AVI", then select a file name, and you would start creating an AVI container.
But this file would have neither audio nor subtitles, and what's worse, it would be 92 GB (!) in size, i. e. 20 times the size of a DVD. That's what "uncompressed video" means.
And there's another obstacle: Shinryaku episode 3 has a video resolution of 1280x720px, and most normal standalone players (which I'll refer to as "SAP" from here on) won't be able to play anything beyond 720px width, i. e. ↗SD video as opposed to ↗HD video.
I guess you performed the corresponding experiments with your SAP already; we're about to map your AllToAVI configuration to several operations in VirtualDub, and these two (video codec and maximum screen resolution) are the ones to begin with. I can only guess what your SAP supports, so if you know better about certain aspects of this device, feel free to override my suggestions. We're transforming video data to your device's requirements after all.

Technical interlude: You've already seen codecs working as filters, decoding compressed streams to uncompressed ones. Now that we have access to uncompressed video in VirtualDub, we can manipulate it by running it through more filters. Whatever transformation we want, be that resizing the resolution or merging subtitles into it, this will be done by a filter transforming a video stream into another video stream; as the last step in the processing chain we will run this video stream through a codec to create a compressed video stream and store it into the AVI container. Some of these filters are shipped with VirtualDub; some are external products (not unlike codecs) that would have to be downloaded and copied into the VirtualDub configuration, thus making the features of VirtualDub extensible - you'll see at least one specimen of either type. Fansub encoders often make it a rocket science to find the appropriate combination of filters for sharpening thin lines, resizing to various resolutions, fixing errors in the original video material, removing TV channel logos and whatnot; we'll only do the minimum required by your SAP.
With filters transforming video streams and feeding their output into the next filter, the order of processing will sometimes be significant. For example, resizing a video first and then positioning subtitles to specific coordinates won't give you the same result as positioning the subtitles first and then resizing the video with the already embedded subtitles (which in this case get resized as well in the process). That's one reason why having the VirtualDub output stream window as preview for the result of the complete filter chain is a nice feature.

In order to get a file you could at least burn to a DVD and test on your SAP we will need to have it resized to less than 721px width, and the video stream being compressed to an appropriate format. XviD would be the codec of my choice (as I know the configuration best here); DivX might be used as replacement in case of need, your SAP will probably support both.

So let's try to create the first AVI container. In VirtualDub with Shinryaku03.avs opened,

1. Select the menu entry "Video"; in this menu there are 15 entries of which the second group influences the way of compressing the video stream. We need "full processing mode" to be selected (that's a requirement for using filters); this should be the installation default but if it's not selected already then select "full processing mode". The top-most entry "Filters" of the "Video" menu should now be selectable. (VirtualDub will remember this setting even for later program starts so you'll have to check this only once.)
2. Select the menu entry "Video", then "Filters"; click on "Add", scroll down and select "resize" (a built-in filter of VirtualDub), click on the "OK" button. You'll get the configuration dialog for this filter; replace the width "1280" by "704", the height "720" will automatically be set to "396". Confirm with "OK" and "OK". You will now notice that the right one of the two video windows has shrunk in size but still shows the complete scene - that's how you can preview the effect of this filter.
3. Select the menu entry "Video", then "Filters"; click on "Add", scroll down and select "TextSub" (an external filter for VirtualDub, one you might not yet have installed, but fear not), click on the "OK" button. If you don't see this filter then continue with the next step (the result of this attempt won't be perfect then but still sufficient for testing your SAP with it), we'll take care of this later. If you have this filter, you'll get a file selection dialog; select the subtitle file (*.ssa) that you extracted from the MKV container a long time ago.
4. Select the menu entry "Video", then "Compression". That's where we can select the codec to be used to compress the video stream. Do you have XviD resp. DivX available already? This may not necessarily be the case as playing an XviD stream only requires a filter that can uncompress that format, so we might have to install a compressing codec for this purpose. If you have XviD resp. DivX already, select the codec of your choice; the default settings of that codec will do for the time being (one episode might result in a file of up to 1 GB with these settings but for the first test that's okay). If you have neither, we have to stop here and install a codec first.
5. If you have either of these video codecs, you can now try "File" / "Save as AVI" to create an AVI container. This will invoke the video compression which will take a while (some 30-60 minutes I'd guess, depending on the speed of your PC).

Edited on 11/05/2010 12:41 AM.

Oh, sorry, it was VirtualDub 1.9.10. I know what you mean about SAPs only being able to handle 720 pixels at most; I must always be careful on AllToAVI to not allow any value greater than that. I'm familiar with Xvid, in that I always use it while working with AllToAVI. 6% zoom for Input and 50% for output seems to make best use of my viewer screen. TextSub was not listed among the 'Add Filters' options. For video compression, 'DivX 6.4.0 (1 Logical CPU)' and 'Xvid MPEG-4 Codec' were listed. I chose the latter, because I know MPEG4 is what I've been using up until now on my AllToAVI conversions. And I begin the video compression process. Time required seems to be about half an hour, which is about the same as with the 'transformation' step of AllToAVI. The speed of everything else underway within the computer is reduced to a crawl, however. The result is 'Shinryaku03.avi' with a size of 102,423 KB. It plays fine on the PC; my experience is that when placing my mouse on the file causes a 'duration' to be listed (0:24:14), that's generally a sign that the operation was a success. So far, so good, and thanks again. This was an encouraging session, and I'm sure that the process will get easier as I repeat it numerous times.

Edited on 11/05/2010 01:59 PM.

102 MB looks small even for a video-only file, something like 600 kb/sec (MediaInfo would tell you). When it comes to lossy compression, bigger is better; for anime with 704x396px resolution the XviD bitrate should be somewhere in the 800-1000 kb/sec range (I use "999" for one-time watch conversions, i. e. 200 MB per episode with audio), and if you intend to burn a good 13 episodes series onto DVD for archiving it you may go up to around 1750 kb/sec, as 4483 MB / 13 episodes would allow for a file size of 345 MB per episode. 26 episodes per DVD would thus be 4483 / 26 = 172 MB = 176561 kB, 24 episodes would be 4483 / 24 = 186 MB = 191274 kB, and you'll find these exact sizes for the XviD release of certain fan-subbing groups. The exact bitrate values for these would depend on the exact playing time per episode; the XviD codec configuration has an integrated calculator that helps a lot for doing the exact math.

The last missing ingredient for your meal is the subtitle filter, ↗DirectVobSub formerly known as VSFilter. You've seen this one at work already, its icon popped up when you played the MKV container with your Media Player Classic; so you have this one installed already, probably under the name of "vsfilter.dll". (On my PC this file is part of the CCCP package.)
Now VSFilter is a funny program: It can serve as filter for DirectShow when it has the file name extension *.dll; it can serve as plugin filter for VirtualDub when it has the file name extension *.vdf, both with the exact same file content. You remember the warning Windows gave you when you tried to rename a file? VSFilter is one of the rare exceptions that can actually work with two different extensions.
In order to get VSFilter, you may search for "vsfilter.dll" on your PC, or download the current version 2.39 from here (this is a ZIP archive containing the file "vsfilter.dll"). Copy the file "vsfilter.dll" into the sub-folder "plugins" of your VirtualDub installation, and rename this copy to "vsfilter.vdf"; thus you'll get the "TextSub" filter in VirtualDub.

And now we can do the real thing, create an AVI converter with audio & subtitles that you can watch on your SAP:

1. Open the AviSynth script with VirtualDub.
2. Select "Video" / "Filters" (or type "Cntrl-F"), add the "resize" filter, set the resolution to 704 x 396 px.
   (You may save these values by clicking on "Save as default" in this filter's settings but remember that these are for 16:9 aspect ratio only; many older anime will have 4:3 aspect ratio and need to be resized to 640 x 480 px, or even not resized at all if their resolution is small enough already.)
3. Select "Video" / "Filters" (or type "Cntrl-F"), add the "TextSub" filter, open the subtitle file you extracted from the MKV container a long time ago.
4. Check the result in the output stream window of VirtualDub: Are the subtitles visible and correctly positioned? (If not, you might have to swap the order of these two filters, by "Move up" / "Move down" in the "Filters" section of VirtualDub.) Do the fonts look plausible? (If not, you need to extract the font files from the MKV container an install them, for details see below.) In order to avoid spoiling an unseen episode to you, try using the second minute of the episode for this test, that's where the OP song usually runs and the karaoke subtitles often require fancy fonts.
5. Select "Audio" / "Direct stream copy" (meaning "just take the audio stream without trying to modify it"; you'll probably need to select this only once).
6. Select "Audio" / "Audio from other file"; select the MP3 file you created with Switch from the audio stream that you extracted from the MKV container.
7. Select "Video" / "Compression" (or type "Cntrl-P"), choose the "Xvid" codec, click on "Configure", set some reasonable "Target bitrate" (see above). VirtualDub does not remember the choice of codec beyond one program execution (whereas the XviD codec does remember its bit-rate setting), you need to select the codec once for each start of VirtualDub.
8. Select "File" / "Queue batch operation" / "Save as AVI" (or type "Cntrl-Shift-F7"), choose the file name for the AVI container. (This will not yet start the compression task, you may continue to specify the next task in VirtualDub right away.)
9. When you have scheduled all conversion tasks you need, select "File" / "Job control" (or type "F4"), and click on "Start"; this will sequentially run all scheduled conversion tasks that aren't already tagged as "done". (You may skip this queuing if you need only one file being converted, and use "File" / "Save as AVI" resp. "F7" instead.)

1. open the next AviSynth script,
2. select the subtitle script for this episode,
3. select the audio stream for this episode,
4. schedule the AVI creation task.

Edited on 11/08/2010 09:34 AM.

Gee, the resolution on Shinryaku03.avi seemed satisfactory, though that was on the PC rather than the SAP. Can I change a setting somewhere to devote more bytes to it? Anyway, after a little searching I found vsfilter.dll in Program Files/K-Lite Codec Pack/Filters. I copied it to My Documents, inserted it into the VirtualDub folder, and renamed it vsfilter.vdf.

Edited on 11/05/2010 08:24 PM.

Set the "Target bitrate" in the XviD codec higher if you want more video quality. How was it set for your first attempt? The more movement and gradual color changes (including 3D CG) your anime has, the more video quality you want; an action series might require more file size than a slice-of-life series.

I left out the "fonts" issue in my previous posting. As you've already seen, a MKV container may contain font files; you can extract them (with MKVextractGUI2), select them with the right mouse key, and choose "install" from the context menu. (This will effectively copy them into "c:/windows/fonts/", so you might need write access to this folder.)
Even though this folder's content will permanently grow this way, I tend to automatically install all fonts from MKV containers right away (as checking whether I already have them would be tedious and I want them to be used anyway, and most font files are tiny compared to videos; my fonts directory contains 600 fonts of a total size of 500 MB.)

"vsfilter.vdf" needs to be in the "plugins" sub-folder of Virtual Dub, not in the root folder of this program.

↗XviD, ↗DivX (both implementing "MPEG-4 Part 2 Advanced Simple Profile"), and even ↗H.264 (implementing "MPEG-4 Part 10") are all implementations of some ↗MPEG-4 variant, so an SAP "supporting MPEG-4" is a rather foggy statement. To add to this confusion, the ↗MP4 container format is specified in "MPEG-4 Part 14", so when reading "MPEG-4" you don't even know whether this refers to a codec or a container...

You mentioned that during the video compression everything else on your PC was slowed down. Video compression is computationally intensive; but while the compression is running you may see a small window showing you the estimated duration and some drop-down menu where you can select the "Processing thread priority" of this conversion task (in VirtualDub, make sure that "View" / "Show status window" is selected).
You may set this priority (which defaults to "Normal", i. e. the same as most of your other programs) to a lower value, even the lowest one named "Idle", thus allowing VirtualDub to only use time when other tasks aren't busy (thus slowing down the conversion process of course). Don't try higher priorities than "Normal", you might have problems to undo this (because the compression would then have priority over this drop-down menu...).

Edited on 11/06/2010 12:48 AM.

I can't find the figure for 'Target Bitrate' (in VirtualDub, right?); I see a box for 'Use target data rate of (blank) kilobytes/second', but it has not been enabled; do I need to do some 'configuring'? What is available is 'Force keyframes every (blank) frames'. this is probably not the figure you want, but the 'General' Bitrate for the completed Shinryaku03.avi file is 574 kbps. Moving vsfilter.vdf to the 'Plugins' folder was just a matter of a drag and a drop. I remember yesterday thinking 'I wish this compression step could be paused'. Of course I wasn't looking for any 'small window' at the time, and would need to do some more compressing to find it. Actually, last night I wrote a script for an episode of Bakuman and compressed it as well, as practice (I'll keep refering to Shinryaku in these messages, though). Under 'File' I see 'Load (or Save) Processing settings', but these just take me to 'My Documents'.

Edited on 11/06/2010 10:08 AM.

The "Target bitrate" is an attribute of the XviD codec, so in VirtualDub you need to select "Video" / "Compression", then select the XviD codec there, and click on the "Configure" button to open the XviD settings dialog.
The VirtualDub setting "use target bit rate" was meant to be a parameter for all codecs (most importantly for those that don't have their own configuration dialog, as the bit rate is all they allow to configure) but some of them allow for a finer tuning; Xvid, for example, may set a target bit rate but alternatively set a target ↗quantizer, i. e. specify the quality by some other measure than file size (thus more flexibly adapting to the requirements of the video, at the expense of varying file sizes), so this configuration setting of VirtualDub doesn't apply for XviD. (Try selecting one of the Microsoft codecs, just to see that for these the VirtualDub setting will be enabled.)
574 kbps was the value that I had estimated but what I wanted to know is how this target bitrate was set within the XviD configuration. The "target" bitrate won't enforce the bitrate to be exactly this way, it only suggests a value and creates an upper boundary; if the video doesn't have enough information then the XviD codec will decide for a reasonable value by itself (so encoding with a target bitrate of 9999 kb/sec will not make full use of this upper boundary but result in a bit rate depending on the movement and color changes within this particular video; if you set such a high limit for anime it may result in anything between 2500 and 7000 kbps according to my experience, all of which is more than necessary as you won't be able to see any difference beyond ca. 1500-2000 kbps for 704x396px anime in XviD).

XviD can be used in two different operating modes, 1-pass and 2-pass. The normal operation is 1-pass, i. e. read the video stream and compress it while dynamically adapting the compression parameters to the requirements of the content. As the compression will begin with the very first video frame but the information about movement in the video is a "learning process" during compression, the quality of the compressed video will change during the operation as for compressing the last frame XviD has more information about the video than it had for compressing the first frame.
The alternative would be to analyze the complete video first, and with this information in mind, begin the compression. This is what the 2-pass in XviD would do. But obviously this requires the complete video to be read and analyzed twice, i. e. increase the processing time by not much less than 100%; in VirtualDub it even requires to start the compression twice and manually switch these "encoding type" settings in the codec configuration.
(A fansub releaser would actually do this as it has one advantage: The quality will show less variation between different but equivalent parts of the video than the 1-pass variant, considering that the OP/ED section may contain significantly more movement than the rest of the video which may confuse the dynamical adaptation process, and XviD would be able to know this better when using the 2-pass method. 2-pass also makes it easier to exactly get the file size that you wanted because the XviD codec won't try to reduce the quality for the last part of the video due to its "learning curve" which may well happen in 1-pass, so with 2-pass XviD you will rarely ever see the result not making full use of the target bit rate you set - as long as there's enough movement in the input video. Two-pass with 9999 kbps target bit rate will not result in an insanely large file, only in an unnecessarily large one.)

To give you an idea about the numbers: The MKV container for Shinryaku episode 3 has a total bitrate of 1725 kbps (of which 161 kbps are for the audio, 1250 kbps for the video, and the rest for the surprisingly large font files) and a file size of 299 MB. It uses a video resolution of 1280 x 720 = 921.600 pixels per frame; we resized this video to 704 x 396 = 278.784 pixels per frame or 30,25% of the original video information. This doesn't mean that the file size should shrink to 30,25% (even more so as we didn't shrink the audio by the same factor, and large areas of a constant color compress better than smaller areas) but the order of magnitude isn't that wrong either - I would assume that the file should shrink to 40%, i. e. 120 MB, in order to have the same quality (and in fact the SD releases in MKV/H.264 tend to be around this file size; the Chihiro release of Amagami in MKV/H.264 with 704x400px has file sizes even as low as 80 MB per episode because Amagami has little movement, being a romance series with more talk than action). But the MKV release of Shinryaku was encoded in H.264 which is more efficient than XviD; so in order to get the same quality in XviD you should assume an additional 30-40% of file size, i. e. 156-168 MB (which in fact is close to the usual size of released anime files in AVI/XviD format; thus using 172 MB resp. 186 MB per episode for 26 resp. 24 episodes per DVD with 4483 GB capacity, or 175,5 MB per episode for 4 episodes per CD with 703 MB capacity which might suffice for an OVA, doesn't mean a quality restriction.).

The "Load/Save processing settings" would save the settings of VirtualDub and all activated codecs/filters (to a file of your choice, the file selection box just happens to start your navigation at "My Documents"). Imagine you have found the perfect settings for Shinryaku, but then have to convert Bakuman or whatever with different settings; for this you might want to save the Shinryaku settings to a file "Shinryaku.vdf" and re-load them when the next Shinryaku episode has been released. But actually your parameters for different anime won't be that different, you'll rarely ever set the XviD target bit rate unless you attempt to fill a DVD with one series to 100% of its capacity and use an "insanely" high quality for this purpose. For most other purposes some constant value in the 800-1000 kbps range and using 1-pass mode in XviD will do the trick.

You'll see the small window during compression only when it is enabled in VirtualDub, by selecting "View" / "Show status window". The compression can't be paused (as the codecs would have to be able to accept a "pause" signal which they apparently won't do) but it can be aborted or set to "idle" priority.

Edited on 11/06/2010 12:56 PM.

Under 'Xvid Configuration', for Xvid Mpeg4, I see some of the terms you mentioned. There is 'Encoding Type', set at 'Single Pass', and 'Target Quantizer' set at 4.00. But there is still no mention of 'Use Target BitRate'. Under the list of codec options for compression five different Microsoft ones are listed, namely H.261 Video Codec, H.263 Video Codec, RLE, Video 1, and Windows Media Video 9. But the first three can't be 'configured' because the computer 'Couldn't find compatible format' for the possible reasons that the codec might 'only support YUV' or might be 'locked'. Also, I haven't installed Windows Media Video 9, so that one is unavailable as well. The only option was Microsoft Video 1 (a crude default codec?), and under 'configure' the only adjustable value for it is 'Temporal Quality Ratio'.

Speaking of codecs, I have noticed something strange about the downloading step of MKV fansubs. They seem to download in their entirety, yet no 'duration' is listed afterwards. To my surprise, almost all still play normally on the PC, despite the lack of a duration, which I had always assumed meant they had only partially downloaded then something had gone wrong. A handful which still refuse to play give me the response I had expected: 'Media Player Classic could not render some of the pins in the graph, you may not have the needed codecs or filters installed on the system'.

Edited on 11/07/2010 09:51 AM.

The "Target quantizer" field inside the XviD configuration is a toggle, i. e. a button that you can click on, thus switching between "Target quantizer" (which is relevant only for 1-pass encoding, 2-pass will find a suitable quantizer by analyzing the video stream) and "Target bitrate (kbps)".
It's difficult to suggest a quantizer for anime encoding in general (as it's a mathematical concept of the internal XviD operation just vaguely related to anything what the pure consumer would ever see of a video); the (german) encoding guide from which I learned releasing XviD fansubs suggests as a rule of thumb (file sizes refer to Shinryaku episode 3 and include audio stream in 128 kbps MP3):

• "quantizer 1" for "insane quality" (531 MB = 2930 kbps video quality)
• "quantizer 2" for "high quality" (209 MB = 1072 kbps video quality)
• "quantizer 3" for "compromise between quality and file size" (155 MB = 762 kbps video quality)
• "quantizer 4" for "low quality that you should rather avoid" (125 MB = 601 kbps video quality).

Edited on 11/07/2010 06:32 PM.

Oh, I see: clicking on 'Target Quantizer' converts it to 'Target Bitrate (kbps)', which is set at 700. I must have been using Quantizer 4 rather than compressing via bitrate. Sorry it took me so long to grasp that. The tree analogy makes sense, since even when I 'Close' the message about the codec problem, the audio plays normally nevertheless. The one fansub which still refuses to play (either in episode two form from CrunchySubs or episode three from HorribleSubs) is Kuragehime; here's the MediaInfo data about the former:

General #0 Complete name : C:Documents and SettingsOwnerMy DocumentsDownloads[CrunchySubs] Kuragehime - 02 360p.mkv Format : Matroska File size : 173 MiB PlayTime : 23mn 7s Bit rate : 1045 Kbps Encoded date : UTC 2010-10-28 19:25:05 Writing application : mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 3 2010 22:54:08 Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video #0 Codec : VP6F PlayTime : 22mn 56s Width : 640 pixels Height : 368 pixels Aspect ratio : 16/9 Frame rate : 23.810 fps Resolution : 24 bits

Audio #0 Codec : MPEG1/2 L3 Codec/Info : MPEG1 or 2 Audio Layer 3 Channel(s) : 2 channels Sampling rate : 44 KHz


The problem must be with video codec 'VP6F' (which I have never heard of), since like I said, audio still plays normally. HorribleSubs episode three uses the same one.

Edited on 11/07/2010 05:19 PM.

Crunchysubs and HorribleSubs are both groups that "take" a subtitle script from an anime that was streamed via ↗Crunchyroll (Kuragehime is licensed by Funimation), "take" some raw video/audio stream, put these into a MKV container, and release the result under their name.
They're rippers, not fan-subbers (they're not subbing anything by themselves, and their accomplishment is something that you could do as well with the tools we installed during this thread, using the MKV creator in mkvtoolnix); what they're doing is the exact opposite of what fan-subbing was meant for. And they're not even competent rippers, leaving you alone with the problem of installing the ↗VP6F codec.

The Kuragehime release by umee (based on the same subtitles, so on the same level from an ethical perspective, but using a Japanese HDTV raw video) would be HD 1280x720 / MKV / H.264 / AAC / ASS, i. e. the same format as our Shinryaku ep3 example and much higher quality than the two releases you named.
(A certain well-known anime database has the exact technical specification for containers and codecs of each release they know about, so you would be able to check these formats before choosing a download group as you are now able to understand what these data mean, and the container type alone isn't sufficient information as you see. You might even contribute to these data by running each downloaded file through a client program they offer which is some MediaInfo & HashCalc combination with an automated web-interface to their database; for popular releases you might not be the first one to offer these data but each file is tagged/highlighted as whether they have been contributed already.)

I added some more file sizes / bit rates for other quantizer settings in my previous posting.

Perhaps what I ought to be doing in regards to Kuragehime is paying to watch it via Crunchyroll; although even if I'm only going to watch each episode once, I really wish I could do so from the sofa in the basement rather than from the PC!

Anyway, what I really want to know is how do I restore audio and subtitles to Shinryaku and make it complete and DVD burnable?

As practice, I take the Doki fansubs MKV episode four of Oreimo, re-read a good deal of your instructions, and using MKVExtract, I extract tracks one and three for audio and subtitles (I realize that I didn't do this with the Bakuman episode). As I understand it, this basically breaks up the original, un-DVD-burnable MKV fansub into seperate components, which is necessary to modify them. One reason I'm doing this is because this fansub is one of those which doesn't show a 'duration' time, so I was afraid that it might be somehow incomplete and the usual processes would not work. But apparently this step was a success. Next, I open Switch (to convert the audio file to MP3), but I get a message: 'Switch Sound File Converter is due to expire in the next few days. Do you want to view current special offers for purchasing online now?'. Did I download a trial version by mistake? But it is still up and running, so I convert the audio file. Again. the process seems to be a success. I notice that audio files that have not yet been run through Switch have the lightning bolt motiff while those that already have been have a light-blue musical note on them. Is there any point in saving the lightning bolt files, now that a converted version has been created?

Edited on 11/08/2010 10:05 AM.

Posting 4694 contains the complete procedure. If exact file size isn't important for you then I suggest using a quantizer between 2 and 3.

It's up to you how you get Kuragehime; I just object to "praising" these groups as fansubbers (having been one myself).

Edited on 11/08/2010 09:12 AM.

I see your post about posting 4694, so I will set the Oreimo project aside and try to complete the Shinryaku episode. As I re-read the list of steps, I realize that I had missed a couple of them the first time around. Somehow I was under the impression that what was going on with VirtualDub at the time was another all video step, and I never added the subtitle or audio files. I bet that's why the size of the 'completed' file seemed strangely small to you--because it was only a video file. Ths time around I carefully follow each step, and am delighted to see the subtitles reattached to the right screen. All seems to be well with the subtitles even during the OP song. When I 'Open' the audio file I get a message 'Import Options: MP3-Bit rate support' with three options: 'Autodetect', 'Constant Bit rate', and 'Variable Bit rate'. 'Automatic' seems the safest bet for my first try, so I select that. I change the Target Bit rate from 700 to 999. I specify that the completed file be saved as 'Shinryaku03b' so that the all-video one will not be overwritten, just in case I need it for any reason. I 'Start' the compression and recombination, and a colorful 'Xvid Status' display appears.

And, half an hour later, the operation seems to be a success! Somehow, completing this one doesn't thrill me as much as testing the new codec and finding that it really does enable MKV fansubs to be watched on the PC. But that's because I was confident that this operation would be a success whereas I sort of expected that one to fail. Anyway, thanks again for all the help. You must get a sort of satisfaction out of explaining solutions to complicated computer problems, because otherwise I don't see how it would ever have gotten done.

Edited on 11/08/2010 11:20 AM.

You're right, solving problems and explaining technical concepts is something I consider fun; read this article for an explanation (and having gotten a result, you must have done some important thing right).

My own encoder knowledge is getting rusty over time, so this was a good opportunity for me to re-read all those Wikipedia articles I linked to. A thread like this one is a also good trigger for me to upgrade all those tools I mentioned on my own PC (which I do about once a year); I wouldn't have known about the existence of VirtualDub 1.9.10. without this discussion (previous VirtualDub versions didn't have the "add audio from external file" feature thus I had to use VirtualDubMod 1.5.10 from 2006 for this purpose).

The Mazui AVI release of OreImo plays on my SAP without any conversion and uses SAP friendly XviD parameters (neither QPel nor GMC3).

Edited on 11/08/2010 01:12 PM.

I generally get my fansubs from Tokyo Tokoshan, and they have no Mazui episodes of Oreimo there. They have ones from Doki and Shimizu, but not Mazui.

Anyway, I thought I would try to complete the conversion of the Doki fansub of Oreimo 04, partly to see if it can be done with these fansubs that are without a 'duration' figure. I wrote the following script:

DirectShowSource ("Doki Oreimo - 04 (848x480 h264 AAC)4B420BC6.mkv",audio=no)

But when I try to 'Open' it with MPC, I get a message (in red letters on a black background, on an MPC display) saying 'DirectShowSource: Couldn't open file Doki Oreimo - 04 (848x480 h264 AAC)4B420BC6.mkv; the system cannot find the file specified (C:/Documents and settings/Owner/My Documents/Oreimo04.avs,line 1)

Yes they have. (Query for Mazui on Tokyo Toshokan)

Is the AviSynth script in the same folder as the MKV container? Judging from the database entry, Oreimo4/Doki shouldn't be a problem for you.

Edited on 11/08/2010 03:06 PM.

Whoops! I was searching for either 'Oreimo' or the full-fledged 'Ore no Imouto ga Konna ni Kawaii Wake ga Nai', but not 'Ore no Imouto' (or 'Mazui').

Yes, the AviSynth script and the fansub are both in the same folder. The thought occured to me that the problem might be that the fansub only downloaded partially--because when I try to Open the script, the button that is used to fast forward (or backward) zooms across the screen in the space of ten seconds. But that doesn't make sense, because when I open the fansub itself with MPC, it plays normally. I've noticed that just because a file doesn't have a 'duration' listed shouldn't mean it is automatically incomplete, because the Shinryaku episode hasn't got one, but it seems to be complete after being taken apart and reassembled.

However, MediaInfo says the Oreimo episode has a Playtime of 24mn 24s....

Edited on 11/08/2010 06:48 PM.

Shinryaku episode 3 has a playing time when you inspect it with MediaInfo - both the MKV container and the H.264 stream inside this container have such an attribute. So MediaInfo may just be able to split the streams and read the MKV header (which may work even with a broken stream inside); perhaps AviSynth's "open" does more checks for plausibility and completeness of the streams?

I guess with "it has a playing time" you refer to the Windows Explorer showing it (as stated above); I checked all the files in my Shinryaku folder and the only file for which Windows Explorer was able to read the playing time was the MP3 audio stream and the AVI containers with audio inside - but neither for the MKV container nor for the extracted AAC audio stream or even for the extracted H.264 video stream... so don't expect too much from this program.
Do you have any MKV container where the Windows Explorer can show you the playing time? If yes, then which stream types / codecs are in use there (according to MediaInfo)?

If you know the file is incomplete (or HashCalc tells you the CRC32 is wrong) you should try getting a correct file first. Only if this turns out to be impossible (file sharing networks may have only a part of the file) you should consider trying to watch the file anyway, for which the ↗VLC media player is a known good tool (even for previewing partial downloads while they're still running but more likely to be successful for AVI than for MKV). But converting a broken file may turn out to be impossible.

Stretch, try this program

Format Factory

It seems to be able to convert most of the animes I am watching at this time.

I can't find any MKV fansubs that Windows Explorer shows a duration time for; I guess that is only done with AVI files. I fear that the problem might be that I have forgotten a step somewhere, since our correspondence has been going on since October 24 and I've gone off on a tangent several times. Where, if anywhere, in the conversion process is MKVMerge GUI v4.3.0 ('Escape from the Island') used? I now have a desktop icon for that. Do I need to actually open it up and make selections of different options, or does it do its work from behind the scenes?

Anyway, I didn't have any trouble reading the AviSynth script for Bakuman, so I will begin the VirtualDub compression step and see how that turns out.

MKVMerge GUI is not used in the process. This is a GUI for creating MKV containers (which you're not doing for the given task). But it came as part of the mkvtoolnix package which is responsible for all low-level MKV manipulation, including extracting streams from MKV containers, and it was invoked only once in order to show you that mkvtoolnix had been installed correctly. You may remove the desktop icon for MKVMerge GUI (which doesn't remove the program file and can be restored if you need it later) if this makes your desktop less "polluted" with icons.
The GUI you are using for this is the MKVextractGUI2 which is not part of mkvtooknix (I wish it were, it would then have reduced the number of installations by 1). You may create a desktop icon for it if you want but invoking from the "Open with..." context menu in the Windows Explorer looks easier to me (hence my desktop is almost empty with a mere 8 icons).

↗FormatFactory might in fact be capable of doing the job (given its description claiming to support way more formats than we need, I didn't try it), and it is under maintenance as of today. Had you opted against the "toolbox with more transparency" approach it would have been a candidate (Forbin, please contribute an equivalent of posting 4694 showing how Format Factory would do such a job, and list the low-level tools it relies on if possible; would it be able to fix the margin of truncated subtitles at the edges of the screen, a ↗common issue for transcoding soft-subbed material to AVI?).
But you wouldn't have learned anything about the "processes under the skin" by using another monolith.

The most likely candidate for OreImo episode 4 not being found by AviSynth would be a typo in the file name. So try renaming the MKV container to "OreImo4.mkv", and edit the *.avs script accordingly - does it open now?

Edited on 11/08/2010 11:57 PM.

Well, the good news is that the Bakuman episode was completed successfully. I had thought that since the only conversion that had been completed successfully up until then was the Shinryaku one which you walked me through, that maybe I had forgotten something; but apparently not. Also, I was getting the same "Couldn't open file" message when I tried to Open a script I had written for an episode of Star Driver. But I re-examined the script and found that I had mis-typed one of the digits of the hash number. Once I corrected that, the Script would Open without trouble. The mistake must have happened because I was copying everything by hand, because until today I couldn't find a way to 'copy' the info in bulk. I tried copying and pasting the file info into the Oreimo Script, and this time it Opened and played--but not the way it normally should. Blue, green and purple are the only colors that appear, and I get two identical images side by side, just like it would be if I was using VirtualDub (but this is definitely MPC). These take up only about half of the screen, and the rest is covered by a band of a sort of 'static' (in the same colors), below which is a band of black screen, and below that a band of gray screen. When I pause the screen and minimize it to do some more typing here, then return to it, the image is perfectly normal. But starting it playing again returns it to the messed-up state. Any ideas? This isn't exactly critical, since I have already downloaded the Mazui version of this episode.

A more important question: Did I download the wrong version of Switch, since it says a trial period is ending?

Edited on 11/09/2010 09:41 AM.

I'm not sure how you are working in the Windows Explorer. I tried to set the visualization to "large icons". Selecting a file, waiting a second, then clicking on its file name makes this file name editable in order to rename the file. If you type "Cntrl-C" in this mode you'll copy the file name into the clipboard from where you can "paste" it with "Cntrl-V" into the editor.

Given the problems you have with playing OreImo 4 / MKV, did you verify the checksum already? (HashCalc) I started downloading this file to see whether there is any fundamental problem (the torrent might take some 30 minutes). By the way, "that database" knows only the 1280x720 (HD) release by Doki, not the 848x480 release by the same group, so my previous statement about knowing the stream types inside turned out to be invalid.

NCH software says: "The free version of Switch also has the additional features of Switch Plus enabled for a 14-day free trial after the software is first installed. If you choose not to purchase the Switch Plus license upgrade at the end of the free trial period, the advanced features will be disabled but the standard Switch features will continue to work." I upgraded my own installation only 12 days ago so I didn't get that message yet. As my version has a menu entry "File" / "Register Software" where I could activate a purchased serial number it looks like both "versions" are the same file.

EDIT: OreImo 4 / Doki / 848x480 looks rather similar to Shinryaku 3 MKV, the latter has been encoded with a slightly newer H.264 codec, audio and subtitle stream are identical formats in both containers. OreImo has the video stream as stream 2, the audio stream as stream 1 (which is unusual, most MKV containers have it the other way round) but both AviSynth and MediaInfo can play this file without problems here.

Edited on 11/09/2010 04:35 PM.

Yes, I noticed that I need to be in 'rename' mode to be allowed to 'Copy' the file info via Windows Explorer. When I use Hashcalc to check the checksum number for the MKV Oreimo fansub, I get the correct one. This probably is meaningless, but I get a different Checksum of 'cc3c8bf0' for the Avisynth Script. Up until you explained it, I had though the checksum number was nothing more than a sort of serial number. So, it sounds like I won't notice any loss of capability when Switch 'expires'; that's good to know. Well, I ran no less than three different fansub episodes through VirtualDub together this morning and all three seem to be successes. I'm about to burn them all onto a DVD for the final test of whether they play on a SAP. About the only thing I haven't done yet is adjust the processing rate so that other computer operations won't be curtailed while VirtualDub is underway.

A ↗checksum is a short content description for a file (and the AviSynth script doesn't have the same content as the MKV container). The idea is that two files of equal size but different content caused by a small local deviation will lead to a different checksum with extremely high probability - even though there are many, many more possible file contents than checksum values.
A simple text file of a mere 5 characters will give you 256 * 256 * 256 * 256 * 256 = 1.099.511.627.776 different contents; the ↗CRC32 checksum, being a 4 byte number, can only give you 256 * 256 * 256 * 256 = 4.294.967.296 different results, so for every CRC32 value there must be 256 different file contents of a 5 byte file. Now multiply this number of "checksum twins" by 256 for every additional byte of the file in question! The trick for a good checksum algorithm is that these file contents of equal checksum value must be globally different instead of locally different, i. e. not just one different character, because the goal is to make you aware of trivial differences between files of the same size (such as a transmission error over your internet line, or a missing block in an incompletely transferred file).

Before you start a torrent for a fansub file you'll have to download a ↗torrent file of some 10.000 to 100.000 characters. This torrent file contains some information about the tracker server that would tell you the IP addresses of other computers sharing this file - but the predominant part of the content of this torrent file consists of a list of checksums for each of those hundreds or thousands of data blocks (20 bytes ↗SHA-1 checksum per block, i. e. much better than CRC32, so a typical torrent for a 200 MB file for one episode with 800 blocks of 256 kB each will give you a file of 16.000 bytes for these checksums; you can see the block size of each torrent in your torrent client; batch torrents of a complete anime series use larger block sizes to keep the torrent file reasonably small). With these checksum data your torrent client can verify the validity of the file content, notice errors within each particular block, discard erroneous data for this particular block only and automatically request another transmission for this block.
That's why file sharing is so extremely reliable; unless you try using an incompletely transferred file it should be practically impossible for you to get a wrong file content via the torrent network (not counting the possibility that the file was broken before the transmission already... but every decent fan-subber would certainly try playing the video at least once before creating the torrent file for it, wouldn't they?). And to avoid even this one potential failure cause, I configured my torrent client so that it uses its own file name extension for a temporary file and renames the result to its true file name only after a complete transfer.
With torrent transfers being so reliable, the CRC32 has in fact become kind of a serial number for many files; with varying names for anime titles (OreImo vs. Ore no Imouto...) the CRC32 (with 4,3 billion possible values) may even be the better query term to search for a particular file (as it is often displayed at the original releaser's website).

Ever wondered why ↗bank account numbers are so much longer than the number of customers of one bank? Some of their digits are forming a checksum, so when you mistype one digit of an account number your bank should be able to notice that the number you typed can't possibly be a valid account number.

Edited on 11/10/2010 01:33 AM.

Last night I sat down to watch the converted fansubs on my new DVD, using a SAP. I performed a quick test, and all seemed to run fine at the beginning, with audio, video and subtitles in proper synchronization. Synchronization is important because I've been having problems with it during some of the fansubs I converted using AllToAVI. Then I decided to watch episode three of Star Driver (originally from StolenSubs--come to think of it, I bet that means it was a 'ripped' fansub). All went well for the first six minutes or so, then audio and video went completely out of sync. Audio and subtitles continued playing at the normal pace while video seemed to go into a sort of slow motion, and the episode became unwatchable. I tried to play the same episode on a different SAP, but got the same result. This might be significant--I took another look at the original StolenSubs episode and it has no checksum number, just this:

{StolenSubs} Star Driver - 03 {720p}.mkv

The original file seems to go briefly out of sync at about the same point as my conversion, but recovers its synchronization within a few seconds while my version seems to remain out of sync indefinitely. So, I am taking the most obvious next step: downloading the {gg} fansubs version of the episode!

Edited on 11/10/2010 08:58 AM.

The StolenSubs release isn't even registered in "that database" (thus no CRC32 available for your file). I wonder what they might have added (song karaoke perhaps?) as [gg] releases 720p/MKV as well.

[gg] are veterans (active since 2005, 30 completed and 24 dropped anime series); I have three fansubs of them in my archive (REC, Toradora, Suzumiya Haruhi). [gg] appears to be the only Star Driver release beyond episode 2 at this stage; note they released version 2 files for episodes 1 and 2, i. e. they consider their own releases to be speedsubs and are willing to fix translation errors for those who want to archive the series.

Some fans are pissed by commercials being part of [gg]'s Star Driver release; as you're converting it to AVI via VirtualDub anyway you would be able to cut out these commercials (there have been releases where I did that for my archived version, or cut out a OP/ED song I strongly disliked, or cut out spoilerish episode previews).
Some other fan was pissed by [gg] using a very high profile (i. e. feature subset) of the H.264 codec for the video stream, meaning that some older H.264 decoders might run into problems when decoding this stream; [gg]'s encoder staff suggests to use a more recent H.264 codec in this case (which means that [gg] is giving the latest encoding features priority over compatibility to older installations and expect their audience to update their PC regularly).

Err.. what am I doing wrong when I try to compress three episodes of a series together, the first one comes out OK, but the second one has both its own subtitles and those of episode one running simultaneously, and the third one has the subtitles of all three?

Maybe I'm doing too many things, like double-checking the resize and Xvid configure steps each time around (rather than just 1.open the next AviSynth script, 2.select the subtitle script for this episode, 3.select the audio stream for this episode, and 4.schedule the AVI creation task).

Edited on 11/10/2010 05:32 PM.

Double-checking can't be wrong. But if you add a second TextSub filter to the second episode (instead of clicking on "configure" for the already loaded filter and select another subtitle file) then you'll run the video through both filters, i. e. add both subtitles. You would see this in the VirtualDub preview already.

Once you scheduled a compression task for execution this task will remember which filter settings it needs (including the name of the subtitle file), so don't be afraid of editing those settings while preparing the next task for scheduling. The same applies to adding the audio stream.

OK, I was afraid to delete the first Textsub subtitle track until the compression process was complete. But once I have queued it, it should be OK, right? Thanks.

Yes, exactly. (Otherwise the whole batch processing in VirtualDub wouldn't make much sense.)

Edited on 11/10/2010 11:36 PM.

How long do I need to keep the AviSynth script for each file that I am compressing intact? Once I have Opened Notepad, can I compose a script, choose the settings in VirtualDub, queue the file, then go back to the script, cut the old file data out, paste the file data for the next fansub in its place, rename the script, and start the process over?

VirtualDub will need all files that it has to read (which includes the AviSynth script that needs to be interpreted by AviSynth during this process, VirtualDub only sees the result of this interpretation) during the compression process.
Instead of renaming a file, just make a copy under a different name; you might want to be able to repeat the compression in case you notice something that wasn't perfect (fonts, margins between subtitles and screen borders etc.). You can delete all temporary files (i. e. the complete work folder for this anime) once you decide you have the "final" AVI instance for this particular episode burnt (or discarded) permanently, which in my case is after I watched the file on my TV set.

OK. I have started work on the conversion of Astro Fighter Sunred 2. This was a fun show which absolutely refused to convert to SAP mode in the past, but I saved it because I really liked it and had a vague idea that maybe someday a way of converting it would become available. And, it turns out, that is just what happened. Thanks. I have a backlog of shows which are stored in Iomega for similar reasons.

My one remaining problem seems to be that I cannot for the life of me figure out where the processing 'window' is located--the feature that could downgrade the priority of compression tasks if I'm also working on something else at the moment.

Err... Problem! When I try to activate Switch, I get "Your 14 day trial period of Switch Sound File Converter Plus has expired", and I can't use the program.

Edited on 11/12/2010 11:09 AM.

Hm, getting the processing window in VirtualDub is a bit more tricky than in VirtualDubMod.
VirtualDub has a Menu entry "View" / "Show Status Window"; enabling this setting makes VirtualDub show that "flashy" window (named "XviD Status") with the compression results (temporary quality levels, quantizer statistics etc.). Do the following: Schedule a compression task in VirtualDub, go to the VirtualDub Job Control (with F4), and start this job. You'll see that the VirtualDub window now (in "batch mode") has fewer menus but is still accessible. Now, select the menu entry "View" / "Show Status Window" again - it has a different meaning this time, enabling the window "Virtual Dub Status". (Ouch, this is indeed cryptic... the ancient VirtualDubMod has two separate menu entries for these two settings.)

My Switch still says "Unlimited free version 4.02" in menu "Help" / "About Switch Sound File Converter". The installation program I used was named "switchsetup_v4.02.exe", has a size of 421.984 bytes and a CRC32 checksum of "885995cc"; I selected none of the additional tools during installation.
If everything else fails you might need to uninstall Switch 4 and downgrade to some older version; I've seen websites like this one or this one offering such versions but haven't checked any of these myself (as I have several older Switch installers in my software archive and my version 4.02 still works).

Note that any audio converter would work within this modular approach, so if you find one that suits you well enough it wouldn't change the whole procedure.
To give you a slightly weird example: ↗WinAmp, the popular audio player program, ships with myriads of audio codecs, thus enabling it to play a large number of audio formats. What's more, there is a WinAmp plugin that allows to compress the selected audio stream to MP3 and write it into a disk file. So with this plugin you can turn WinAmp into an anything-to-MP3 converter (and this was actually the way I converted audio streams before I found Switch - it's just a bit awkward to always toggle the WinAmp configuration between "playing" and "converting to MP3" by enabling/disabling the plugin in the WinAmp configuration, Switch's GUI looks a lot more user-friendly).
Using WinAmp instead of Switch would be a lot like using VirtualDub instead of AllToAVI - replacing a commercial black box by a more modular and extensible approach, at the expense of perhaps having to collect a necessary plugin for some future audio codec yourself instead of relying on an upgrade by the tool's releaser.

I decided to uninstall the Switch version which I had and replace it with one of those which you suggested. However, within the Uninstall sequence I found an option to ‘Downgrade to the free version’, and selected that. Sure enough, Switch is usable again!

(Fortunately, the audio tracks of Astro Fighter Sunred seem to already be in MP3 mode, so I didn’t need switch there)

I found the alternate VirtualDub Status Display, but under ‘Processing Thread Priority’ only three options were available: ‘Normal’, ‘Higher’, and ‘Even Higher’! What I need is to slow things down, right? I tried adjusting 'Speed Limit' to about a 50% of maximum (which is where it started). That seems to have helped; other tasks (especially on the internet) run more slowly than usual but don't take literally minutes to get underway, which is how things used to go.

So, two major problems more-or-less fixed. Thanks again!

You can scroll upwards in that "priority" dropdown menu and there access the lower priorities (of which "idle" would be the lowest one, i. e. the first entry in this menu).

OK, I see now.

Well, I think I have finally gotten the hang of it. I burned a DVD which contained lots of Sunred episodes and episode five of pretty much every show I am currently following. I haven't watched them all yet, but so far there have been no problems. The processing feature makes sense to me now and I really can't think of any more questions to ask. So, thanks once again. I don't know where I'd be if it hadn't been for your help; perhaps only watching those shows which are still fansubbed in AVI!

And even those won't always play on SAP.

Recent example: Amagami SS. Eclipse (one of my favorite fan-subber groups for years, releasing AVI containers with SAP compatible encoding parameters for shows like Akane-Iro, Clannad, Kanon 2006, To Aru Majutsu no Index, Zero no Tsukaima) "entered hibernation mode" after episode 12 so I switched to UTW's AVI release, only to find that episode 13 was encoded in XviD with ↗QPel enabled (which makes my SAP display random video garbage at certain points within an episode) and an MP3 audio stream with ↗variable bitrate (which may or may not cause my SAP to reject the complete episode with the message "wrong file format"), both of which are known issues by SAP (the third one being ↗Global motion compensation where SAP support no more than 1 warp point, i. e. when MediaInfo shows "GMC3" as XviD encoding setting in the video stream then the episode will play on my device but occasionally hang and force me to reboot my SAP, or jump ahead 15-30 seconds at random positions within an episode... sigh). So I had to recode this episode before watching it.

Fortunately, UTW changed their encoding parameters to the same settings as Eclipse after I told them about the SAP issues in some forum (AVI releases in SD with hard-coded subtitles aren't meant to be the high-quality variant anyway compared to 1920x1080px H.264 video with softsubs in MKV containers these days, so why try ultra-fine-tuning AVI releases at the expense of SAP compatibility?), and from episode 16v2 on I can play their AVI releases without post-processing.

You're probably right; when I'm watching animation, reading subtitles and listening to audio all at the same time, it's easy to get confused when something definitely isn't timed right. A problem with 'offset' would explain a lot. VirtualDubMod isn't part of VirtualDub is it (though it sounds like it should be)? My problem now is that I don't seem to have VirtualDubMod anywhere within my computer. I just performed a search and no programs by that name were found. I went looking for clues on this page, but it doesn't seem to go all the way back to the beginning of the Mencoder problem. Did another page get too long, and was a new continuation page (this one) created? I don't remember.

This thread used to be much longer but the first couple of postings are missing. The forum search can still access these postings but the thread display doesn't seem to have them any more. EDIT: Adding more postings to this thread makes more of the early postings disappear so let's open a new one instead...

↗VirtualDubMod (download from Sourceforge) is a code spin-off of VirtualDub with additional features (attempting to handle other containers such as OGM and even MKV as well), unfortunately with many bugs and not under maintenance since 2006 thus I considered usíng VirtualDub instead as a safety play. The GUI is almost the same, with slightly different menu entries.

Edited on 01/12/2011 11:13 PM.

Update one year after the beginning of this discussion:

Some earlier posting in this thread contained my full video conversion procedure.

But in the meantime I purchased a new media player.

Said media player is capable of playing H.264 encoded video streams in AVI containers. And I have a H.264 encoder installed on my PC that can be used from VirtualDubMod.

So while H.264 isn't exactly what AVI containers were designed to contain, from now on I will create AVI containers with H.264 video streams that still have the subtitles hard-coded (because SSA subtitle stream support of my media player still leaves a lot to be desired), resulting in a minimal change of the procedure (just using H.264 with Quantizer 20 instead of XviD with Quantizer 2) while creating files that are 40% smaller without any visible loss of quality (judging by the first dozen episodes that I compressed with both procedures for the sake of comparison).

So, you can't quite simply download MKV fansubs and burn them directly onto a DVD to watch on the new Media Player, right? Do you still need any steps of the MKV Extract/Switch/VirtualDub process at all?

No, I can play MKV containers with SSA subs on this device. It's just that

• all formatting information of the subtitles (fonts, colors, bold/italics, fading effects etc.) is ignored and
• the timing of the subtitles is pretty bad (too late, and often very short; apparently the built-in subtitle interpreter is too slow), making subtitles bothersome to read (too much "stop & rewind" necessary).

• The media player can play H.264 video streams, thus I can create encodings that are about 40% smaller in size than XviD encodings with the same video quality. ("Downgrading" H.264 to XviD was owed to using the "ancient" DVD player technology that's years behind current video formats, and that's something I no longer need to do now.)
• The media player can play HD resolutions of up to 1920x1080px (i. e. BluRay quality). So I would not need to resize the resolution down to 704x396px for 16:9 material any more; in reality I'm still doing it because the file size is much smaller then and the difference on my 1366x768px "HD-ready" TV set is not really visible for my eyes.

• Insert the DVD into the DVD reader of my PC (then being accessible on Windows drive "E:")
• Insert the USB stick into one of the many USB slots of my PC (then being accessible on Windows drive "K:")
• Copy whatever files I want to watch from E: to K: (the USB stick capacity is 7.5 GB, i. e. larger than one DVD)
• Extract the USB stick from the PC and insert it into the USB slot of the satellite receiver
• Switch the satellite receiver from "receive TV program" to "play files from USB device" with the remote control

I must be missing something here. It sounds like while H.264 MKV fansubs can be played, there are so many problems with formatting and timing that you still do everything you taught me (except maybe Resizing). In other words, converting them to AVI. But if that were so, how does this new technology make things any simpler and easier? I sounds like the only major advantage is that encodings are about 40% smaller in size. Or, was that the point of the new media player all along?

The point in purchasing anything in the first place was that otherwise I would have completely lost the ability to receive German TV programs on April 30, 2012.

So, as I had to purchase a new satellite receiver anyway, I stumbled upon this box that also serves as recording device for TV programs. In order to do so, the box needs to be able to record videos and play videos - the latter being quite similar to what a DVD player is capable of doing. So would it be able to replace my DVD player in the process? The supported formats turned out to be way superior to what a DVD player can play (most notably HD formats and H.264 video streams); in order to make the whole conversion procedure for anime redundant the box would have to be able to support SSA subtitles. My current opinion is that yes, subtitle support is working to a certain degree - but not fast and complete enough for my personal needs. Hence I prefer sticking to the established conversion procedure for the time being - but only for anime with subtitles. (And for these, I can modify the conversion procedure slightly by making use of H.264 video encoding and occasionally HD resolutions - this was the point of posting in this thread.)

The core issue isn't the conversion to AVI, it's the on-the-fly interpretation of SSA subtitles which happen to be the standard format in today's MKV containers. When downloading anime in, say, MP4 containers the subtitles must have been burned into the video already (because MP4 can't contain subtitle streams, just like AVI) - so I can play MP4 fansubs with H.264 video in HD resolution directly. Unfortunately, only few fansubbers are releasing MP4 containers already - but at least MP4 releases are beginning to be more common than AVI releases these days, so the percentage of fansubs that I will play without conversion on the new box (with a GerSub for Kannagi having been the first of these series already) is increasing now while it was decreasing in the days of the DVD player.
Also, there is a number of fansub releases in AVI/XviD but with a resolution larger than 720px in width (including the GerSubs for Kanon and Aa! Megami-sama - Sorezore no Tsubasa), and the new box can play these whereas a DVD player would have rejected them as "wrong format".

But the main benefit that I got from the purchase is that I was almost unable to reliably play DVDs on the old player anyway - whenever I wanted to do this I needed to give the DVD player some warmup period of at least 10 minutes, i. e. trying to play a DVD, wait for the error message "Can't read this DVD", turn the box off and on again, try again... which can become quite tiresome when you need to do this just for a single anime episode. And even when the DVD player decided to play a DVD there could still be reading errors on the disk, more so as I was using rewritable DVDs that tend to wear of at random positions of the disk after a while while the rest of the disk still works fine. Thus I was on the verge of additionally purchasing a new DVD player - which would have cost not much less than the new satellite receiver...

So as the whole use of DVDs had become very bothersome for me, and no DVD player has survived in our household longer than three years before the error rate increased massively, I finally decided DVD to be a dying breed, and was thus looking for a different and less error-prone storage medium - and I found it in the form of the USB stick, by separating the storage medium (DVD) from the video interpreter function (video player) which currently just happen to both be features of the DVD player.

Edited on 11/24/2011 09:00 AM.

OK. Once things get technical I tend to zone out and have a hard time understanding. I get my television via cable so I have little idea what sort of problems there might be with a satelite system. The closest parallel might be when we recently switched to a new cable TV system which rendered old VHS players incapable of recording anymore (they can still play). I just use ordinary, non-reprogramable DVDs. They cost only 40 cents of so, and I have an obsession with saving everything just in case I ever want to watch it again someday.

I'm also saving almost everything - but I want to store anime in a way that

1. I know this file is playable on my target device
2. I know where to find any particular anime
3. I can watch this anime without interruption from episode 1 to the end

Edited on 11/24/2011 01:54 PM.

I tend to burn a DVD around once a week with all of the episodes of series that I'm currently watching from the week before. I also save all episodes of series which look like they might be worth rewatching someday, using my auxiliary hard drive. At the end of the season I burn the entire series onto one DVD--and use whatever space is left over for the first episodes of the new series of the next season. So, if it's a halfway decent show, each episode appears once on the weekly DVD and once on the series-as-a-whole DVD, which makes the rewatch much easier.

But the archiving method isn't really part of the issue, it's the reliability of playing DVDs at all. The aforementioned warm-up period of 10+ minutes before the player would even begin to read any DVD applied to permanent DVDs as well. This was what I had to get rid of.

I guess your DVD player was slowly dying and the signs were all too clear.

Yep, and the new box was the alternative to purchasing a new DVD player every three years.