Converting Aku no Hana form {gg} - different speed of video and audio

Converting episode 1 of Aku no Hana from [gg] with our usual procedure creates an AVI file with video and audio in different speed.

Why is that? Because video and audio have indeed been created with different speed, and were then muxed together into the MKV container of the release which contains a directive telling the video player to play the audio stream with a different speed than the one it was created with. Modern video players understand this directive, thus the file plays correctly on Windows via MPC.

But when we extract the audio stream from the MKV container, the directive gets lost, and the file is still in the wrong speed. Thus our conversion routine produces an unusable result with an audio stream running at 29.97 fps instead of 23.976 fps.

So instead of extracting the audio file directly from the MKV container with MKVextractGUI, we need to fix that speed issue first. And the easiest way to do this is - let Windows do it. How can we achieve this?

Normally, we read the video (!) stream via some Avisynth script where we ignore the audio stream ("audio=no").

This time, we will read the video stream via a slightly modified AviSynth script where we also take the audio stream ("audio=yes").

From here, we need to extract the already fixed audio stream into some external file:

• Open the modified AviSynth script with VirtualDubMod.
• In VirtualDubMod, select menu entry "Streams / Stream list", thus opening the dialog "Available streams". (VirtualDub can't do this, we do need VirtualDubMod this time.)
• In this dialog, click on "Save Wav" to extract the (already selected, only) audio stream (in uncompressed form) into a file "Aku_no_Hana.wav".

Edited on 04/25/2013 09:58 AM.

I went to the folder where I save the various parts of a conversion until I have watched the completed version and am satisfied with it. I modified the AviSynth script from 'no' to 'yes'. In VirtualDubMod after clicking 'Save Wav' I was shown a display entitled 'VirtualDubMod Status' which kept track of progress for a minute or so as it completed its task. I needed to store the saved Wav element somewhere, so I went back to the incomplete folder, and hand copied 'Aku_no_Hana.wav' as the title. When I try to begin the final conversion step on VirtualDubMod, it refuses to accept the script--nothing happens. I don't know if it means anything, but a message appears in the bottom margin reading 'Error decompressing video frame 0: the source image format is not acceptable (error code -2)'. VirtualDub (not VirtualDubMod) accepted the new script but the end result had the same problems as before, namely audio and video are out of sync.

Did you successfully convert "Aku_no_hana.wav" to MP3? Does that stream play with the correct speed and length (about 23 min)?

I can't see why VirtualDubMod would accept the script, allowing you to extract "Aku_no_Hana.wav", and then reject the very same script for the final compression step.

Actually you may just

• open the modified AviSynth script with VirtualDubMod,
• extract "Aku_no_Hana.wav",
• deselect the audio stream (by clicking on it in the same VirtualDubMod dialog) so that this broken stream won't be used for the compression result,
• use Switch to compress the extracted audio stream to MP3,
• "Add" the MP3 stream (in the same VirtualDubMod dialog where you extracted the WAV stream from),
• add the subtitles and
• start the compression in VirtualDubMod.

Edited on 04/25/2013 01:40 PM.

Step 2, 'extract "Aku_no_Hana.wav"', would be done with another program, like MKVextractGUI-2, right? And we're talking about extracting it from the original {gg} fansub (again), right?

Step 3, 'deselect the audio stream' would be done in 'Available Streams', right? I have options to 'demux' or 'disable', but I don't see anything about deselecting. Clicking on the stream (source, desc, length, etc) doesn't seem to do anything.

Here's something I noticed earlier: when I convert the 'Aku_no_Hana.wav' stream (which has what seems a good length of 00:23:59) to mp3 (using Switch--right?), the mp3 version I get has an absurd length of 01:11:59.

No, the extraction of the audio stream has to be done in VirtualDubMod (with "save as WAV" from "Streams" / "Stream list") and from the AviSynth script output instead of the MKV file, because the AviSynth script has fixed the speed of the audio stream at this stage already (this happens probably when the installed splitter of Windows splits the MKV container into streams during the interpretation of the AviSynth script) which MKVextractGUI does not do.
The original audio stream, i. e. what you extracted with MKVextractGUI, is unusable for our purpose because we don't have a tool to explicitly change its speed from 29,970fps to 23,976fps (as Switch isn't capable of doing this), thus we have to do it implicitly by asking Windows to "play the MKV container correctly" by using the AviSynth script (that simulates a video player). You may, for example, play the original MKV container with your Windows Media Player MPC and the audio stream would have the correct speed then - but MPC doesn't allow us to extract and save the audio stream while AviSynth + VirtualDubMod do.

Clicking on the audio stream within VirtualDubMod / "Streams" / "Stream list" should slightly change its color (as visual feedback). We don't want two audio streams in the compression result, thus we have to deselect the audio stream that comes from the AviSynth script and add the MP3 stream we created externally with Switch.
Alternatively, you could use two different AviSynth scripts, one with "audio=yes" to get the corrected audio stream available for extraction, the other with "audio=no" to not get the WAV audio stream added into the compression result; but deselecting the audio stream (after extracting it and adding its MP3 variant) should suffice and allow you to run VirtualDubMod just once in the process.

Actually, the audio stream from the AviSynth script would be usable for the compression result without any MP3 conversion step. But this stream is way too large for using it in a file that you would want to achive (about 300 MB per episode for the WAV file alone, i. e. much larger than the compressed video stream). It's a pity that VirtualDubMod can't compress both the video and the audio stream at the same time.

Edited on 04/26/2013 12:08 AM.

Actually, clicking on the audio stream did cause a pattern of diagonal lines to appear across it, but there was no mention of anything being deselected so I didn't think that was what we wanted.

I think I have accomplished everything up to 'add the subtitles' in the list of steps--but where did they go? Isn't the only thing that has been extracted the wav sound file?

what is the VirtualDubMod command to start compression? I don't see any 'Q batch operation' here.

"Start compression" in VirtualDubMod is "File" / "Save as..."; there's a checkbox "Don't run this job now" for queueing.

The subtitles handling is the same as always: You have to extract these from the MKV container with MKVextractGUI and add them in VirtualDubMod via the "TextSub" filter.

The system which I have been using to convert fansubs via VirtualDub doesn't require the subtitles to be extracted; only 'audio' needs to be extracted, the subtitles work out OK as they are. If I remember correctly, you discovered this long ago and showed me how to do it. Previously an extra step was needed to deal with the subtitles, but I haven't had to do that for several years and have forgotten how. Is the 'TextSub filter' part of VirtualDubMod, or is it a separate program? I don't see any mention of TextSub anywhere in VirtualDubMod; the only mention of 'Filters' is in the Video category.

Hm... right.

When you run the MKV container through the AviSynth script, it will be "played" with default settings of the MKV container. This means: If the MKV container has set the subtitle script of your choice "on" as the default, then you don't have to do anything else, i. e. you'll get the video with the subtitles being added already. This may be the majority of cases, most notably for fansubs. Apparently I misunderstood one of your previous postings in the sense that this had not worked automatically.

There are MKV containers out there with more than one subtitle language, and even DVD rips (for BluRay releases with higher resolution, uncensored versions, no TV station logo etc.) that have the English audio stream and no subtitles as default for playing. For these, the more general approach of extracting the subtitles and using a VirtualDub plugin/filter "Textsub" to add the subtitle & audio stream of your choice would always work.
That's why I'm still using this procedure in some cases albeit nowadays I can download most fansubs in MP4 containers that play on my satellite receiver without any conversion (such as OreImo 2 from [DeadFish]).

Well, after reading your last post I decided to attempt a conversion just to see what would happen. I opened the 'yes' script with VirtualDubMod, set compression at mpeg4, replaced the wav audio with the mp3 one, did nothing regarding the subtitles, then instructed the program to 'save as' AkuHana1. I got this:

"The decompression codec cannot decompress to an RGB format. This is very unusual. Check that any "Force YUY2" options are not enabled in the codec's properties"

I am surprised, because I didn't have this effect here.

After you opened the AviSynth script in VirtualDubMod, are you able to play the video there? My guess is "no" because the problem seems to appear already before that point.

Are you able to play your MKV container with MPC? This is what we're simulating in AviSynth after all, so this should work in the first place.

Both "↗RGB" and "↗YUY2" are color spaces, i. e. formats for encoding colors.

The "decompression codec" in your case is the codec for H.264, as the video in the MKV container has been encoded in H.264/AVC (says MediaInfo, right?).
This codec is invoked by the "DirectShowSource" command in the AviSynth script and should normally be able to handle the standard color spaces, and in this case transform them to the simple "RGB" color space.

The message indicates that the configuration of your H.264 video codec appears to be set in a way that would enforce this codec to deliver its decompression result in the "YUY2" color space which might cause problems for whoever attempts to process this output further. I can't see who generates the message you quoted, but apparently it must be VirtualDubMod because AviSynth works with all the color spaces mentioned above.

When I play the MKV container with MPC, I get the two icons "FFa" (blue) and "FFv" (red) in the Windows taskbar. "FFv" is the user interface for the "ffdshow video decoder" and offers the settings of the video codec used, in this case the H.264 codec.
Amongst the "supported color spaces" I have checked entries for "YV12", "YUY2", "UYVY" and "RGB32" (my version of ffdshow has much fewer entries than the online documentation version though); the submenu "RGB conversion" (selectable at the left side of the dialog) has "High-quality YV12 to RGB conversion" checked.

When I move my mouse over this "FFv" icon, a tooltip appears showing me "Output: YV12" amongst other information. So on my PC the DirectShow H.264 codec creates an uncompressed video in the "YV12" color space but my VirtualDubMod doesn't seem to see that as a problem.

AviSynth allows you to forcibly convert a video to a specific color space. Not knowing the origin of your problem, you might try a test and replace your script line

DirectShowSource ("[gg] Aku no Hana - 01v2 [0F69A819].mkv", audio=no)

(as you don't need the original audio stream after having created the MP3 version already) by

DirectShowSource ("[gg] Aku no Hana - 01v2 [0F69A819].mkv", audio=no) . ConvertToRGB32 ()

; does that change anything?

If all else fails, then are you able to compress the video to XviD/AVI without an audio stream, using VirtualDub instead of VirtualDubMod? If so, then you may open the AVI container with VirtualDubMod and add the MP3 audio stream later.

Edited on 04/28/2013 05:48 PM.

No, I can't play the episode on VirtualDubMod, but I can with MPC (with everything in the proper sync).

When I examine the Fansub ({gg} 01v2) with MediaInfo, I see no mention of a Decompression Codec or H.264, but the (video) format is AVC. The Color Space is YUV.

When I attempt to open the new Avisynth script with VirtualDubMod, I get the message:

“Avisynth open failure:
DirectShowSource: couldn't open file {gg} Aku no Hana - 01v2
{0F69A819}.mkv;
The system cannot find the file specified.
(C:UsersRonDocumentsAkuHana 01v2AkuHana 01v2.avs, line 1)

here's something odd: while I was trying to make a conversion using VirtualDubMod, I checked to see if a 'resize' was necessary, and was surprised to find that a 'new'width of 320 and a 'new' height of 240 were listed. I clicked OK and left that alone. Now, when I'm trying to make a VirtualDub conversion without audio, I find that the dimensions are back at what I would expect, namely 1280 x 720.

I'm attempting the 'if all else fails' tactic, and will get back to you with the results tommorrow. So far, so good; everything seems to be working, the only question will probably be whether the synchronization issue is solved.

Hmmm... the synchronization seems OK, but somehow the size of the image has been changed to 320 x 240 pixels. VirtualDubMod must have set a default resize, because I never specified those numbers, I just clicked 'OK'.

VirtualDubMod would create 320x240 frames if no video were loaded; but if that's the case then how would the "synchronisation seem OK"?

VirtualDubMod doesn't resize the image by itself; if you wanted to do this you would need a filter (just like the filter "TextSub" that you formerly used for embedding the subtitles). Did you add such a filter? This requires using "full processing mode" for the video processing in VirtualDub resp. VirtualDubMod.

The "resize" filter in "Video" / "Filters" of VirtualDubMod would indeed have a default setting of 320x240px. You may use it for resizing 1280x720px down to what your DVD player supports; but I prefer resizing in the AviSynth script instead, using a line like

LanczosResize (704,396)

or

LanczosResize (640,480)

below the "DirectShowSource" line, and then running VirtualDubMod in "Fast Recompress" mode because no filters are used.

The VirtualDubMod filter "Resize" can do the same but having this line in the AviSynth script is easier for me to remember.

Well, I simply typed in the usual 704 x 396 dimensions and tried again. This time I think I finally have what I want: a converted version with audio, video and subtitles all in sync! I will burn this on a DVD containing all the Week 3 episodes of Spring shows I am watching (plus episodes 2 and 3 to get caught up).

What I need to do now is write down the steps I took so that I don't forget them. Thanks for your help!

Edited on 04/29/2013 10:19 AM.

Lines in an AviSynth script beginning with "#" are comment lines and ignored by AviSynth, so you can just write all the steps into the AviSynth script itself.

Here's the list of steps I came up with:

1. Switch the Avisynth script from 'no' to 'yes';
2. Open it with VirtualDubMod;
3. Set Compression to mpeg4 as usual;
4. In Streams/Stream List, click on 'Save WAV'; assign a name to the stream and save it.
5. Convert the stream to mp3 with Switch;
6. Convert the video to Avi without an audio stream using VirtualDub;
7. Open the Avi container with VirtualDubMod;
8. In Stream List, click twice on the original audio stream to disable it, and replace it with the mp3 version.
9. Type the 'Resize' dimensions of 704 x 396 in place of the default 320 x 240.
10.Begin the conversion with the command 'Save as'.

You know, this seems much like the way you once taught me to handle conversions, before you discovered the simpler version which I mentioned above. I remember being surprised to learn that a major step was unnecessary after all.

On my PC I didn't have any problem when reading the AviSynth script (video) with VirtualDubMod; and as I have the resize statement in the AviSynth script, I needed only steps 1-5, 8 and 10.
(Actually, for playing on my satellite receiver I would use steps 1-2 and 10, creating a huge temporary AVI file with uncompressed video and audio and hard-coded subtitles, and then run this AVI file through Handbrake, thus getting an MP4 container with H.264/Q20 video and AAC/128 audio; Aku no Hana episodes in 1280x720px have a size of 160-180 MB in this format.)

As you're now aware how to deselect the audio stream in VirtualDubMod you're free to always use a script with "audio=yes".

The unnecessary step appears to be extracting the subtitles with MKVextractGUI and adding it in VirtualDubMod via the TextSub filter, as this will in most cases be done automatically when running the MKV container through the AviSynth script.

Edited on 05/01/2013 01:15 AM.

Thanks again. Now I will try to convert Majestic Prince, which is the only Spring series left which I wanted to watch at least one episode of but couldn't convert successfully.

There's one thing about this way of converting video files to AVI that I should mention.

The main idea is that playing the original MKV container via the AviSynth script and accessing both the video (with already hard-coded subtitles) and audio from the script's output in order to compress both separately to MP3 resp. XviD.

This idea works not only for MKV containers but for any container type you can play on your PC. Anime fansubs these days are mostly MKV containers but other videos may come in other formats, be that

• "↗*.mp4" (usually H.264 video with already hardcoded subtitles),
• "↗*.wmv" (Windows Movie, ancient microsoft format),
• "↗*.mpg" (ancient MP1/MP2 formats, still in use on DVDs these days) or
• "↗*.ts" (transport stream, the format used for satellite TV transmissions).

That is intriguing. I have avoided mp4 mode whenever possible because I have never been able to get it to convert successfully. IIRC, I skipped the series Mushibugyo because it was only available in mp4. Perhaps I can get that one to convert using this technique.

[Kamigami] and [HorribleSubs] release Mushibugyo in MKV, says TokyoTosho.

Most MP4 releases are just re-encodings much like the stuff we are doing, with [DeadFish] being my primary source for anime downloads as my satellite receiver can play MP4 containers with H.264 video but doesn't render SSA subtitles in MKV containers in a readable way.

Yeah, I remember now, there was a HorribleSubs version of Mushibugyo in MKV. But just like mp4 in general, I have made a practice of avoiding HorribleSubs products because they always seem to be out of sync once converted. I bet this technique you taught me here would make them usable again as well.