Keep aspect ratio in AviSynth?

[Downgraded286]

Another minor issue with MeGUI: When I try to select a folder with a bunch of mkvs in it that need processed, I get an error saying this file or folder cannot be used in one click mode. I can still add them one by one which wouldn't take much time, but still, it would be nice...

[Downgraded286]

I'm getting some strange results with neroaac. The audio seems to be really quiet. I don't see any options adjust the volume of the audio... but it's definitely lower than the source.

[KarMa]

I'm getting some strange results with neroaac. The audio seems to be really quiet. I don't see any options adjust the volume of the audio... but it's definitely lower than the source.

Did you downmix it from surround to stereo, as that will do it.

[Downgraded286]

Sure did but I do that with handbrake too and I never lost volume that way...

[Downgraded286]

Any way to avoid the volume loss when downmixing to stereo? Command line switch or something?

[jagabo]

You can always use an normalizer filter after downmixing.

[Downgraded286]

How would I go about doing that?

[hello_hello]

Deleted. I replied to an older post.

[KarMa]

Pretty much the only way I deal with the lower volume is to downmix it in Megui, and have it output a FLAC. Then raise the volume of the FLAC in Audacity using the "Amplify" effect, and it will give you the highest dB number possible without clipping automatically. Amplify the audio and then export it again in FLAC, then encode with Megui to AAC/MP3/AC3 or whatever.

http://manual.audacityteam.org/man/amplify.html

[hello_hello]

MeGUI's encoder configuration has a "normalise peaks" option. It uses Avisynth to normalise (2 passes). You can even set the percentage it's normalised to (100% = peaks at maximum). Or the QAAC encoder can also do 2 pass normalising. I haven't used it with MeGUI but it should be just a matter of adding -N to the custom commandline section for QAAC, although for MeGUI it's probably easier to use it's own normalising. There shouldn't be any need to normalise with a different program.

I'm getting some strange results with neroaac. The audio seems to be really quiet. I don't see any options adjust the volume of the audio... but it's definitely lower than the source.

It could be relative. How's the 5.1ch source being downmixed when you listen to it? Often it's not downmixed "safely" to prevent clipping on playback, so it can sound louder.
If you don't have "normalise peaks" enabled in MeGUI's encoder configuration it'll no doubt sound quieter when downmixed as MeGUI reduces the volume when combining channels to prevent any chance of clipping. The "normalise peaks" option will then ensure it's as loud as possible, but it still mightn't sound as loud as the original.

Handbrake doesn't include the LFE channel when downmixing to stereo (it downmixes to Prologic) and if ithe LFE channel increases the overall volume, not including it might allow the volume to be raised a little more so that might be why downmixing with Handbrake sometimes results in a louder stereo file. I think for Prologic the volume of the surround channels is reduced a bit, which might make the front channels a bit louder by comparison after downmixing and normalising. MeGUI downmixes 5.1ch to stereo using Avisynth like this (peak normalising enabled), but the encoder configuration also has a Prologic downmixing option.

fl = GetChannel(a, 1)
fr = GetChannel(a, 2)
fc = GetChannel(a, 3)
lf = GetChannel(a, 4)
sl = GetChannel(a, 5)
sr = GetChannel(a, 6)
fl_sl = MixAudio(fl, sl, 0.2929, 0.2929)
fr_sr = MixAudio(fr, sr, 0.2929, 0.2929)
fc_lf = MixAudio(fc, lf, 0.2071, 0.2071)
l = MixAudio(fl_sl, fc_lf, 1.0, 1.0)
r = MixAudio(fr_sr, fc_lf, 1.0, 1.0)
return MergeChannels(l, r)

Normalize()

The upshot is (the numbers are percentages) the stereo surround and stereo front channels are mixed together. The centre channel and LFE channels are both reduced by 3dB and added to the stereo mix. The whole lot is then reduced by a further 7.5dB (I think) to prevent clipping and after downmixing Normalize() adjusts it so the peaks are at maximum.

Peak normalising isn't the best way to do it when working with a bunch of related files (episodes of a TV show). For single files such as movies it's fine, but peak normalising doesn't guarantee each audio track will be adjusted by the same amount. If the peaks are different relative to the average volume they won't be. For TV episodes I tend to downmix to a lossless format (without normalising) then scan the downmixed audio with ReplayGain and convert to the final output format while using the ReplayGain info to adjust them to the same volume without clipping. MeGUI can't ReplayGain scan so I use foobar2000 for that part.

[Downgraded286]

MeGui is giving me another problem. It's producing results with video and audio out of sync. It seems I have some rather odd DVDs. Mediainfo reports my copy (made my MakeMKV) of Blue Collar Comedy Tour Rides Again as having variable frame rate mode, listing "Frame rate: 24.000FPS" and "Original Frame rate: 23.976 24000/1001 FPS". I suspect this could be the reason for the audio/video desync. Also, for some reason, the encoded file comes out as a few seconds longer in duration than the original...

[jagabo]

Stop using MakeMKV to remux the VOB content into MKV. Many programs have problems with MPEG 2 video in MKV. Instead use the VOB files directly with DgMpegDec. Make an Index file (d2v) and demux the audio with DgIndex, then open the index file with Mpeg2Source("filename.d2v") in AvISynth.

[hello_hello]

MeGui is giving me another problem. It's producing results with video and audio out of sync. It seems I have some rather odd DVDs. Mediainfo reports my copy (made my MakeMKV) of Blue Collar Comedy Tour Rides Again as having variable frame rate mode, listing "Frame rate: 24.000FPS" and "Original Frame rate: 23.976 24000/1001 FPS". I suspect this could be the reason for the audio/video desync. Also, for some reason, the encoded file comes out as a few seconds longer in duration than the original...

There's too many variables to say why for sure. "Frame rate" is probably the container (MKV) frame rate while "Original Frame rate" is the frame rate written to the video stream. I'm not sure why they're different and if they are, I can't remember which one MeGUI uses, but it has to pick one.
How is MeGUI opening the video? Indexing, DirectShowSource, which indexer is it using?
If it's using ffmsindex for indexing is frame rate conversion being added to the script? If so, what frame rate is being used?

If you manually add info() to the end of a script and preview it, what's the output frame rate being displayed?

Given you've already ripped the DVDs using MakeMKV, I'd open one of the MKVs with TSMuxer and remux it as a TS file. Open the TS file with MeGUI's File Indexer and let it index with DGIndex and extract the audio, then use it for encoding. That'll be less problematic than mpeg2 video in an MKV, assuming the resulting TS file doesn't have problems carried over from the original ripping process.

You could possibly also check if the frame rate is the problem by opening the output file with MKVMergeGUI and remuxing it while setting the frame rate to 2400/1001 (23.976), or 24p as the case may be, and seeing if the remuxed MKV has synced audio.

[Downgraded286]

@jagabo I'll try exploring that option... I messed with it a little previously and a bunch of .vob files seems pretty messy to me, but I'll go that route if I have to.

@hello_hello Well, I use the One Click Encoder in MeGUI, not sure exactly what goes on behind the scenes with that, but in an attempt to answer your questions I'm copying the code in the avs script generated by it as well as the MeGUI log. If I'm not mistaken, it's indexing with LSMASH.

I tried adding AssumeFPS(24000,1001) to my avisynth template in the MeGUI one click encoder, and the framerate indeed came out 23.976FPS (as opposed to 24FPS) but the audio is still way off.

Looks like I got some things to try next time I get time off...

I might add the resulting files vary in length. The one I encoded at 23.976fps is 1:46:41, the one without changing the FPS (that's the log I'm posting) came out 1:46:35, and the original MKV made my MakeMKV (which is in sync) is 1:46:33.

global MeGUI_darx = 8640
global MeGUI_dary = 4739
LoadPlugin("C:\Program Files (x86)\Tools\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("F:\MakeMKV Output\progressive\kmu5q4id.m0n\Blue Collar Comedy Tour.mkv.lwi")

[manono]

I messed with it a little previously and a bunch of .vob files seems pretty messy to me, but I'll go that route if I have to.

What's the least bit messy? You open all the VOBs at once in DGIndex and make a single D2V file for the entire movie. If I remember correctly, you've already been told to make D2Vs and use MPEG2Source several times already. You can lead a horse to water...

If you're using MeGUI I don't know how it works. Open the IFO, open the first VOB and the rest follow along? In any event, making an MKV for MeGUI or anything else to use as a source is just inviting trouble.

[jagabo]

I might add the resulting files vary in length. The one I encoded at 23.976fps is 1:46:41, the one without changing the FPS (that's the log I'm posting) came out 1:46:35

That's the difference between 23.976 fps and 24 fps.

[hello_hello]

@hello_hello Well, I use the One Click Encoder in MeGUI, not sure exactly what goes on behind the scenes with that, but in an attempt to answer your questions I'm copying the code in the avs script generated by it as well as the MeGUI log. If I'm not mistaken, it's indexing with LSMASH.

I tried adding AssumeFPS(24000,1001) to my avisynth template in the MeGUI one click encoder, and the framerate indeed came out 23.976FPS (as opposed to 24FPS) but the audio is still way off.

Looks like I got some things to try next time I get time off...

From the log file you posted:

---[NoImage] LoadPlugin("C:\Program Files (x86)\Tools\MeGUI\tools\lsmash\LSMASHSource.dll")
---[NoImage] LWLibavVideoSource("F:\MakeMKV Output\progressive\d5jgcuxm.1ti\Blue Collar Comedy Tour.mkv.lwi")
--[Information] [7/12/2016 11:21:37 PM] resolution: 720x480
--[Information] [7/12/2016 11:21:37 PM] frame rate: 24030/1001

---[Information] [7/12/2016 11:27:32 PM] avs [info]: AviSynth 2.60, build:Feb 20 2015 [03:16:45]
---[Information] [7/12/2016 11:27:32 PM] avs [info]: Video colorspace: YV12
---[Information] [7/12/2016 11:27:32 PM] avs [info]: Video resolution: 720x480
---[Information] [7/12/2016 11:27:32 PM] avs [info]: Video framerate: 24030/1001
---[Information] [7/12/2016 11:27:32 PM] avs [info]: Video framecount: 153469

I might add the resulting files vary in length. The one I encoded at 23.976fps is 1:46:41, the one without changing the FPS (that's the log I'm posting) came out 1:46:35, and the original MKV made my MakeMKV (which is in sync) is 1:46:33.

The video should vary in length if it's encoded at different frame rates without changing the number of frames.
For L-Smash, MeGUI lets L-Smash decide the frame rate. So.....

Your log file says the audio duration is 01:46:33.067 and the video is 01:46:32.992, so they're basically the same. The log file says you're encoding 153469 frames, and if my math is right that would make 24030/1001 the correct frame rate. Knowing it results in out of sync audio though, and knowing the DVD frame rate is likely to be 23.976fps, that probably means the total number of frames is wrong.

AssumeFPS() simply changes the duration without changing the number of frames. If I'm right you'd need to tell the decoder to output the correct frame rate. That will change the number of frames, but not the duration, which appears to be correct.

Create a simple script like this and load it into the video section so you can open it in MeGUI's preview to check the total frame count.

LoadPlugin("C:\Program Files (x86)\Tools\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("F:\MakeMKV Output\progressive\kmu5q4id.m0n\Blue Collar Comedy Tour.mkv.lwi", fpsnum=24000, fpsden=1001)

The above will force LSmash to decode at 23.976fps, duplicating/dropping frames as required. I'm not sure how you'd get the OneClick encoder to do that though. You probably can't. It's not a good way to do it anyway, if the video consists if a mixture of film and interlaced etc, but if it fixes the audio sync at least you'll know what the problem is.
As you know, NTSC DVDs aren't necessarily the same from start to finish. Sections can be 23.976fps progressive, or 29.970fps progressive or 59.940i, or "film" with pulldown.... or other things.... it's very common and I think you may have one here. For AVISynth, if the DVD consists of different frame rates it all needs to be converted to a common frame rate for encoding, but that's after interlaced sections are de-interlaced and pulldown removed etc, which is done with Avisynth filters. The OneClick encoder will probably handle all that automatically when DGIndex is decoding vob files (or TS files) as it's a fairly tried and true system, but it probably doesn't expect to for MKV (either that or disabling automatic deinterlacing prevents it from doing so), so L-Smash is just outputting the average frame rate (24030/1001 in this case), and the audio sync is therefore out. I never use the OneClick encoder, but that's my guess....

When you said in your opening post you were already using Avisynth for detelecine/deinterlacing, how were you going about it exactly?
It's hard to imagine you weren't already bumping into this sort of problem if your source videos were MKVs containing mpeg2 video.

Chances are if you remux your MKV as a TS file as I suggested, the problem will go away. Let the OneClick encoder de-interlace if it thinks it needs to. If the chapters or subtitles aren't retained after remuxing to a TS file you can always add them to the output file yourself later. It's easy to do, especially as they're already inside an MKV. If the problem doesn't go away when re-encoding the TS file it probably means the issue was created when the DVD was ripped.

I'll give Handbrake one thing. It's very good at handling these types of problems so they don't happen. If there's gaps in the audio stream it'll account for them. It handles variable frame rates without sync problems as it can output a variable frame rate, but while it'll give you a decent output without having to think about it, there's a lot more you can do with Avisynth.

Have you used MKVToolNix yet? If not, you should download it. It's pretty straight forward to use, and if you're working with MKVs, pretty indispensable. Often if you use it to remux different streams (ie the original video with the encoded audio, or encoded audio with the original video etc) that makes it fairly easy to determine which stream is causing a sync problem, and if you have to encode a stream individually yourself, you can use MKVToolNix to create the final MKV containing video/audio/chapters/subtitles etc.

[jagabo]

If you refuse to work with the original VOB files at least use MkvExtractGUI to remux the video in your MKV to an MPEG program stream (.MPG) file. That will get you better compatibility than transport streams with a wide range of programs.

[Downgraded286]

Almost there...

Following your suggestions, I copied the disc with DVD Decrypter and made an index with DGIndex. I opened it with MeGUI, transcoded it, and the audio and video was in sync like it should be, chapter markers were there... but not the subtitles. So, I tried loading the .IFO directly into MeGUI, and got the same result. In both cases the subtitles appeared in MeGUI but didn't show up in the resulting video. The subtitles are there when I play the VOBs directly, but they look different than they do when I play the file I made with MakeMKV. The VOBs show the subtitles as large purple letters, yet the MKV shows them as normal looking yellow letters.

Posting a log file...

@hello_hello Since you were curious, I'll explain my old process to you. I would rip with MakeMKV, and make a corresponding AVS script for either deinterlace or detelecine and load that into VirtualDub, encoding with a lossless codec (usually Lagarith). I would load that video into MKVToolNix, along with the original created by MakeMKV, to mux the audio, subtitles and chapter markers in with my video track processed by AviSynth/VirtualDub. I would then load that file into Handbrake to finally compress with h.264 and AAC.

This process works, but is not ideal for a whole list of reasons. Not only do I have to encode the video twice this way, as you mentioned, but there's so many intermediate steps involved thanks to AviSynth/VirtaulDub processing only the video, and losing aspect ratio information on top of that. I have to mux everything back in (which takes a while thanks to the huge file sizes resulting from using a lossless codec), only to load it up in an arguably inferior program (Handbrake). It was a very involved process on my part, a lot of me having to be there to do this and that to make my final product. MeGUI's one click encoder makes everything so much easier, because I can load the source file straight into MeGUI. AviSynth is available if I need it, and the video gets encoded with h.264 already along with the audio, subtitles and chapter markers. I set it up once and let it go, and I may even be able to queue multiple files automatically if I set up my presets for the files I'm converting beforehand. It's pretty much set it and forget it, literally taking days off my process time depending on how long the project is (big TV series for example).

If I could just get the darn subtitles to work properly... that's the last roadblock here.

[hello_hello]

It's really the "make a corresponding AVS script for either deinterlace or detelecine" part I was curious about. If a DVD is a mixture of telecined film and progressive and interlaced it need to be handled properly and I was wondering how you go about it when it's mpeg2 in an MKV. I don't work with NTSC a lot but there's pulldown and interlaced flags to consider when it's being decoded before it can be processed correctly and I was wondering how you determine what needs doing. I'm not saying it can't be done, but I've not re-encoded much mpeg2 video inside an MKV. I guess it'd always need to be decoded at 29.970fps to be handled properly?

Automatic de-interlacing was disabled in your log file, but it looks like DGIndex decided the DVD was "film" and "force film' was applied so it was decoded as progressive at a constant 23.976fps. As it turns out, I'm pretty sure forcing L-Smash to decode at 23.976fps as I mentioned earlier would have produced the same result in the case, although it's no doubt not always that simple.

--[Information] [7/14/2016 2:29:26 PM] Running auto force film
---[Information] [7/14/2016 2:29:26 PM] Film percentage: 99.35
---[Information] [7/14/2016 2:29:26 PM] Applied force film

I assume there's a small section at 29.970fps somewhere which is why L-Smash decoded more frames at an odd frame rate because it decoded at the average frame rate. There were 153278 frames encoded this time vs 153469 last time.

As I don't use the OneClick encoder it's log file is a bit like trying to translate Greek for me, but I can't see anything wrong as far as the subtitles go. You can open the IFO file manually using VobSubber. You'll find it under MeGUI's Tools menu. It'll extract the subtitles for you in the usual idx/sub format.
Open the MKV containing the encoded video and audio etc with MKVToolNixGUI, deselect any existing subtitles shown, add the extracted subtitles, and remux that as a new MKV. If the new MKV still gives you subtitle playback problems I'd be very surprised if it's MeGUI's fault. I've muxed subtitles after extracting them that way countless times and never had an issue. Could "normal looking yellow letters" for the MKV indicate they're not displaying correctly when you open the vob file?

[Downgraded286]

Well, generally I would mediainfo the file and see if it said interlaced or progressive, and go from there. Regardless what mediainfo said I'd watch the original video made by mkvtoolnix and check for combing. If I saw it, I'd then determine whether to deinterlace or detelecine by looking for that 2-3-2-3... pattern. ffmpegsource2 is what I'd load the mkv with into virtualdub, and it hasn't given me trouble.

A quick recap of what goes on with the one click encoder while loading the original .IFO, regarding subtitles:
1. Loading the IFO alone causes the subtitles to appear in MeGUI, but they just... don't make it. MPC-HC doesn't show them, mediainfo doesn't show them, MKVToolNixGUI doesn't show them.
2. Loading the IFO, and then the .idx produced by MeGUI's Vobsubber for subtitles produces the same result as 1.
3. Loading the output from MeGUI with the .idx subs and making a new file with MKVToolNixGUI works. If I load that file into MeGUI and run it through, the subs survive.

This all seems like a big mess. Isn't there any way to retain the subs while encoding the video the first time? I really don't want to go back to using MKVToolNixGUI... that's another step in the process, and, well, it makes a .mkv and I need .mp4.

[jagabo]

This all seems like a big mess. Isn't there any way to retain the subs while encoding the video the first time?

Use VOBSub in your AviSynth script to render a SUB file extracted from your VOB files with VSRip.

Mpeg2Source("VTS_01_1.d2v") 
VOBSub("VTS_01_0.sub")

[hello_hello]

Well, generally I would mediainfo the file and see if it said interlaced or progressive, and go from there. Regardless what mediainfo said I'd watch the original video made by mkvtoolnix and check for combing. If I saw it, I'd then determine whether to deinterlace or detelecine by looking for that 2-3-2-3... pattern. ffmpegsource2 is what I'd load the mkv with into virtualdub, and it hasn't given me trouble.

I discovered OneClick's advanced configuration lets you specify the preferred decoder order. By default, L-Smash has precedence over ffms2 but you could change it to see if re-encoding your MKVs is more successful that way. If MeGUI adds frame rate conversion to the script for ffms2 it might help, or mess things up (it adds it after indexing manually although I don't know about the OneClick encoder), but I thought I'd mention it in case you want to try using ffms2 instead. I doubt MeGUI would handle automatic de-interlacing or IVTC as well that way.... but if you sort that out yourself it probably doesn't matter.

A quick recap of what goes on with the one click encoder while loading the original .IFO, regarding subtitles:
1. Loading the IFO alone causes the subtitles to appear in MeGUI, but they just... don't make it. MPC-HC doesn't show them, mediainfo doesn't show them, MKVToolNixGUI doesn't show them.
2. Loading the IFO, and then the .idx produced by MeGUI's Vobsubber for subtitles produces the same result as 1.
3. Loading the output from MeGUI with the .idx subs and making a new file with MKVToolNixGUI works. If I load that file into MeGUI and run it through, the subs survive.

For the muxing issue, see my next post.
I had a look, and I'll confess if there's a way to automatically encode the subtitles using the OneClick encoder I've not found it yet. It seems like it'd be odd if it didn't have that option, but I don't know as I never use the OneClick encoder myself. You could probably create an Avisynth template that includes subtitle encoding (similar to what jagabo suggested) and use it as part of a OneClick profile when you want to encode the subtitles.
Mind you DVD subtitles tend to be fairly ugly so even when I do want to encode them I usually convert them to a text format for encoding with SubtitleEdit first. A tedious process I thankfully don't have to do much.

[hello_hello]

Rewriting this post after a bit of experimenting......

After discovering DVD subtitles can be muxed into an MP4 and doing a bit of experimenting, it seems there's an oddity relating to the way VobSubber extracts subtitles and the way MeGUI adds them to the command line for muxing in relation to the track number of the subtitle.... or something..... I'm not 100% sure yet. It seems though, automatically adding them via the OneClick encoder mightn't always work.

When I opened the IFO file I was using for testing, vobsubber showed a single English subtitle stream numbered 01. When I checked the "show all subtitle streams" option there was a stream 00 listed, a stream 02 listed, a stream 03 listed etc, but all listed as "not detected".
I extracted the single English stream and MeGUI used the following to add it to the command line for MP4 muxing:

-add "E:\testing\VTS_01_0.idx#trackID=1:lang=eng:na me="

There was an obscure warning in the log file about "track 1 ID not being found in file" and there were no subtitles muxed.

I tried again, but rather than selecting the single subtitle when extracting, I checked "keep all subtitle streams" in VobSubber. Only the stream "01 English" was being displayed. After extracting I tried muxing again and MeGUI created the same command line. This time though, the subtitles were muxed and the warning was replaced with:

VobSub import - subpicture stream 'eng'

I don't quite understand what's happening. When opened with VobSubber, the English subtitle (and the only subtitle) appears to be track one (although the first stream could be track zero). When extracting by selecting the single English stream VobSubber, must extract it as track zero and MeGUI can't find it, although why it detects it as track one when adding it for muxing I don't know. I'm making guesses here.....

The problem may have even happened at the ripping stage. When re-authoring, DVDShrink has a "logical re-mapping of enabled streams" option. Maybe that's got something to do with it (although I'm pretty sure it was disabled when I re-authored this DVD. Oh FFS..... I guess I should test it.....

.... nope re-authoring the DVD with that option checked didn't change anything.

Anyway.... there's some sort of MP4 command line issue I'll have to report if the guy who maintains MeGUI returns from wherever he's disappeared to recently, but in the mean time try manually extracting the subtitles while checking "keep all subtitle streams" in VobSubber and adding them to the OneClick job that way. Or use the utility for extracting subtitles jagabo suggested to see if it plays with MeGUI better.
If there's more than one stream to be extracted..... well.... I've no idea how that works for OneClick or for the MP4 container yet.

PS At one stage I muxed some subtitles MeGUI wouldn't mux into an MP4 using My MP4Box GUI, so that's probably an option rather than MKVToolnixGUI, for an MP4 output. For whatever reason, I then extracted the subtitles from the MP4 and after extracting I added them to a MeGUI muxing job and this time MeGUI muxed them successfully. I don't know how the subtitles changed due to the muxing/extracting process to make them MeGUI friendly but I might try to work it out later on.... in a few days..... I hate MP4.

[Downgraded286]

Right again, hello_hello. I just tried it on my end, that is, using vobsubber and ticking the "keep all subtitle streams" box. This time, the IDX it produced actually made it through the one-click encoder and gave me my subtitles. Unfortunately, it involves another step (more manual input) and the indexing can take a while, but at least it works. So far, this seems the path of least resistance. I'm sort of considering using my SSD instead of HDD for my encoding workspace due to all this indexing, but that would make my games load a bit slower and the speed increase was disappointing.

This surely smells like an issue with MeGUI that the developer(s) ought to fix, hopefully. It's such an awesome tool otherwise... aside from this one issue.

[hello_hello]

I've reported the problem but the guy who maintains MeGUI seems to be missing in action at the moment so I wouldn't hold my breath.

[Downgraded286]

I appreciate that, and all your help you've offered. At least I have a workable solution now, even if it is a bit of a pain. It's too bad the one click encoder doesn't handle it properly... hopefully there is a fix soon.

[Downgraded286]

Following your train of thought, I found out that if I select "keep all subtitle streams" the size of the resulting file is greatly increased from the one generated if I select "select subtitle streams", even though in both cases I only checked the box for one subtitle track. I recognize that it's probably extracting the other subtitles and simply not showing them because I didn't select them with the "keep all subtitle streams" option, but this lead me to consider the possibility that when you use "select subtitle streams" some key data could perhaps be left out, which causes the subtitles to not work.

[hello_hello]

Are you referring to the size of the extracted subtitle file? You should be able to see if there's additional subtitle streams by checking "show all" in VobSubber. Are you sure it's not that it's simply because it's extracting multiple streams?

Normally when you extract subtitles you end up with an idx and sub file. If you open the idx file with MKVToolNix and there's more than one subtitle stream it should display them individually and you can select which ones you do and don't want to mux. That's the way I've always done it so even if I extract all the streams I can pick and choose when muxing. Although MKVToolNix only displays the language for each subtitle and not whether they're forced or SDH etc. You have to work that out for yourself.

I tried a quick experiment with a subtitle file I know contains two subtitle streams. When opening it with the OneClick encoder it only shows "Subtitles 1". The same happens when opening it with the muxers under the Tools menu.
Even though only one subtitle stream showed when opening the idx file, the MeGUIs MKV muxer muxed both subtitle streams. The MP4 muxer only muxed one of them.

I think MeGUI is misbehaving badly all round. Ideally if you open a subtitle containing more than one stream with a muxer or with OneClick it should show there's more than one stream (ie Subtitle1, Subtitle 2 etc). If it can only show the first subtitle stream, then even the MKV muxer should only mux the first stream, so at least it's not indicating it's doing one thing while it does something else. That way you'd at least know if you want to add more than one subtitle stream you need to extract then individually.

[hello_hello]

Here's all the the oddities I've discovered while playing around and the best workaround I've found so far at the end of this post.
According to Vobsub and VSRip, there's two subtitle streams in the DVD files I've been playing with.
Stream 0 and Stream 1. They're both English and as best as I can tell, exactly the same, so whether there's only one physical stream I'm not sure, but if I extract both I get a sub file twice the size as when I only extract one.

VobSub and VSRip see Stream 0, but MeGUI's VobSubber does not. The lack of detection may be just a glitch in this case, but if I select Stream 0 for extraction it's successfully extracted and MeGUI can mux it. Had I not been messing around though, I wouldn't have known stream 0 actually contained subtitles.



That oddity aside, if I only extract stream 1 with VSRip and open the idx file it creates with VobSub, it shows stream 0 as English but empty.



When I extract only stream 1 with VobSub (MeGUI), it shows stream 0 as not detected.



Either way seems acceptable on the face of it, and if anything the way VobSub extracts there'd be less ambiguity as to which streams actually contain subtitles.

When muxing subtitles into MP4s, MeGUI always seems to specify track 1 in the command line (Stream 0 = Track 1 to MP4Box).
-add "D:\VTS_01_0.idx#trackID=1:lang=eng:name="
For the subs extracted by VobSub the problem seems to be obvious. MeGUI must simply assume the subtitles it's muxing are stream0/track1 and for the VobSub subtitles they doesn't exist. Specifying track 2 in the command line fixes the problem, but you can't make MeGUI do that.

For the subs extracted by VSRip, Track 1's English subtitles are technically empty, but when track 1 was specified in the command line, the muxed MP4 appeared to have subtitles. Until the penny dropped and I realised MP4Box was foolin' with me and it muxed an empty subtitle track. English subtitles were showing up in the player menu but there were no subtitles to display.

One way to solve the problem might be to not specify a track number, or specify track 0, which seems to mean all tracks. That'd fix the problem for subs ripped with VobSub but in this case for subs ripped by VSRip it resulted in two English subtitle menus in the MP4, but only one contained subtitles. It seems a bit silly of MP4Box to be muxing empty subtitle streams. MKVToolNixGUI ignores them.

Ideally MeGUI should detect multiple subtitles from a single idx file and let you choose which to mux. Failing that you'd have to extract streams individually but at the moment unless they're stream 0 it appears MP4 muxing still won't work.

When selecting "keep all streams" in Vobsubber it obviously extracts all streams containing subtitles and maybe the subtitles you were working with were similar to mine, so when you selected "keep all streams" it extracted stream 0 which appeared to be empty in the GUI but MeGUI was able to mux them. Based on my experience so far I can't think of another explanation for "keep all streams" fixing the problem. I wonder if MeGUI not detecting subtitles in stream 0 is a general problem, or just a glitch in this case? I probably should check later.

So far I've found one workaround. MKVToolNix to the rescue.
- Extract a subtitle stream or all the subtitle streams with VobSubber (works for VSRip too). Open the idx file with MKVToolnixGUI.
- Select the subtitles you want to keep and remux that as an mks file.
- Open the mks file with gMKVExtractGUI and extract the subtitle streams. They'll be extracted as an idx and sub file per stream, so for multiple streams you'll have multiple idx and sub files. Each subtitle stream will be extracted as Stream 0, making them MeGUI and MP4 muxing friendly. I'd imagine MKVExtractGUI2 or MKVCleaver would extract them the same way.

That appears to be how it always works so far, based on my limited testing. There might be ways to remap the streams with VobSub or VSRip, or even at least remap one of them to stream 0 when ripping the DVD, but if it's possible I haven't discovered how to yet. I haven't needed to investigate subtitle problems much myself as I mux everything manually and haven't had any issues doing it with MKVToolNix.