BD3D2MK3D: Convert 3D BDs or MKV to 3D SBS, TAB or FS MKV - Support thread

[r0lZ]

Well, BD3D2MK3D doesn't change the frame rate of the original BD3D. As far as I know, all 3DBD are encoded at 23.976 fps (More precisely, at 24/1.001 fps. Don't ask me why that crazy NTSC frame rate has been adopted when the frame rate of the cinema has always been 24 fps and all modern equipments are able to play exactly 24 fps. It's a stupid american decision imposed to the whole world! Anyway, the fact is that we must live with 23.976 fps.) Of course, in frame sequential frame packing mode, there is twice the number of frames but when distributed to the two eyes, the frame rate is still 23.976.

Unfortunately, there is no support to change the frame rate in BD3D2MK3D. However, it is easy to modify the frame rate of the video stream by editing the text files produced by BD3D2MK3D before launching the encoding. The problem will be that the audio track will not be in sync any more. You will have te re-encode tha audio to adapt its frame rate. You can do that with eac3to (distributed with BD3D2MK3D, in its toolset folder) but wou will have to write the command in the Windows command prompt yourself. See here for more info. You will also have to change the file name in a text file.

In summary, you can select the Full-TAB mode in BD3D2MK3D, then edit __ENCODE_3D.cmd to change the --fps 24000/1001 to - - fps 24
At this point, you can launch the encoding. During the encoding, you should launch the eac3to commands to convert the audio strean(s), with something like this :

"path\to\BD3D2MK3D\toolset\eac3to.exe" "path\to\projects\movie\00001\InputAudio.ac3" "path\to\projects\movie\00001\OutputAudio.ac3" -changeTo24.000 -progressnumbers

Then, edit __MUX_3D_OPTIONS.json to change the frame rate below "--default-duration", from "0:24000/1001p", to "0:24p",
In the same file, change the file name of all audio track(s) at the end of each sections under // ### Audio stream(s)
If the muxing operation took place before you have finished everything, just relaunch the __MUX_3D.cmd file.

I have not explained what to do if you need to include subtitle streams in the final MKV. If it's your case, let me know...

Also, I don't know why the specs of your projector doesn't show SBS at 24fps. If it can play TAB at that frame rate, why not SBS? And the labels of the first formats, "(Frame Packing)", do not make sense. Frame packing is the generic name of all methods used to pack the two video streams in a single file, including SBS and TAB. I suppose they mean Frame Sequential. Anyway, a hardware claiming to support 3D video but unable to play the only official frame rate of the 3DBD format is certainly a bizarre hardware. But unfortunately, it's the case of many projectors. BTW, can I know if you live in NTSC or PAL land?

Sorry, I can' t help much more.

[r0lZ]

I forgot to explain that it is theoretically possible to avoid the audio re-encoding by just editing the mux options json file. But the result may not be perfect. I can explain how to do it if you want to try. That will be much easier and quicker. (The conversion of the subtitles to 24fps use the same method).

[VonHagenstein]

Allrightythen... First, I'm very grateful this forum exists, and for the creator of BD3D2MK3D. Wealth of info here. I'm still a relative noob at using it but not a complete noob to the world of working with video and audio, encoding etc. in general. Hopefully I'm following proper protocol with this post; if not someone set me straight.

I have a decently sizable collection of 3D Blu Rays that I am just getting ready to embark on ripping. Over 300. Yeah, I'll be at this awhile.
I'm currently using BD3D2MK3D to convert MVC 3D mkv files sourced from my 3D Blu Rays to Full SBS/TAB format.
Using FSBS as an example, this results in a 3840 x 1080 frame containing the full-res left and right eye images side-by-side.

What I want to end up with is a 3840 x 2160 frame with that same content. For FSBS this means the image would be stretched vertically from 1080p to 2160p. For FTAB it would mean stretching the images horizontally from 1920 to 3840.
I could take the resulting output file from BD3D2MK3D and load it into something else, stretch it, then re-encode it. That whole copy-of-a-copy/re-encoded-multiple-times thing with all the horrible generational quality loss it brings. Which leads me to question 1:

Q1: Is there an "Additional options:" command(s) I can add, or via other means, get BD3D2MK3D to output FSBS or FTAB stretched into a 3840 x 2160 frame, as opposed to the 3840 x 1080 / 1920 x 2160 frames I currently get? So that I can get files in the format I want in mostly one step instead of multiple, avoiding the pain and quality loss of having to re-encode multiple times?

Next questions are to help me understand all of this better.
Q2: Am I correct in thinking that BD3D2MK3D drives AVISynth for the (re)encoding portion, and that AVISynth in turn uses whatever it's configured to use (ffmpeg etc.) to do the actual encoding, or BD3D2MK3D is driving ffmpeg directly or...?

Q3: Looking at the [?] help for the "Additional options:" section on the [5: Options and Go!] tab of BD3D2MK3D leads me to think that the commands/parameters/switches entered there are related strictly to the encoding portion of the process, is that correct? If so, I'm thinking that's not going to be a path to what I'm trying to do (just a means to fine-tune the encoding process with advanced options etc.)?

Q4: If AVISynth is being driven "behind-the-scenes" so-to-speak by BD3D2MK3D, is there a way to "inject" or utilize additional AVISynth commands or functions into the process? Such as stretching, sharpening, other video-processing things etc. AVISynth is a deep tool in and of itself, and I haven't learned it yet, but surely it has features that would let me stretch my video to the desired height/width? I'm not sure where I would (if possible) utilize those commands with BD3D2MK3D, or whether any syntax would need to be modified for them.

I learn best by examples, so if anyone wants to point me to those or sources of info on the topics I'm happy to look at those. I've done a LOT of searching for these answers already but my Search-Fu has failed me thus far.
Appreciate any help.

[r0lZ]

Hello and thanks for your appreciation of BD3D2MK3D.

First, I would like to know why you want that strange output format, stretched in one direction but not both. With Full-SBS (or Full-TAB) option, you get a full-HD video. The horizontal resolution is due to the two views stacked together, hence its value identical to the horizontal size of an Ultra-HD 2D video. But it's not UHD! Resizing the height as you suggests means that you will obtain an hybrid mix between full and ultra HD. As far as I know, it's a format not supported by any hardware player, and even probably illegal. Note also that enlarging the video will not improve the overall video quality and may even degrade it somewhat.

Anyway, yes, it is possible to resize the video as you want it, although not with the GUI (because you are almost certainly the only person who wants that!) You are right about the way BD3D2MK3D uses avisynth internally. And avisynth itself uses several extensions to decode the source AVC video and to "hardcode" the subtitles over the video (if you have enabled that option). It doesn't use ffmpeg directly although some avisynth plugins are derived from ffmpeg (but BD3D2MK3D doesn't use them).

The avisynth magic is controlled by the __ENCODE_3D_MOVIE.avs script. It is generated by BD3D2MK3D with the commands necessary to decode the two video views, stretch them in one size if you have selected the Half-SBS/TAB option, optionally hardcode the subtitles and stack the two views together in SBS or TAB format. The resulting output is then sent to the x264 or x265 encoder. When the project is generated by BD3D2MK3D, the encoding is not launched automatically by default to let the user modify the content of the AVS script. It's why you can easily change the final resolution, without the necessity to encode the movie twice.

So, when the project is generated, edit __ENCODE_3D_MOVIE.avs with a text editor. In Full-SBS/TAB, you will notice that two lines (Even and Odd can be swapped, depending of the input format of the BD3D):

left  = SelectEven(interleaved)
right = SelectOdd(interleaved)

It's where the output generated by the MVC decoder is processed to isolate the two views. And, after that step, you can add any filter to modify the video. I assumes that you want a Full-SBS output resized vertically to obtain the hybrid output described above. You can simply add these two lines right atter the two lines above.

left  = LanczosResize (left, 1080, 2160)
right = LanczosResize (right, 1080, 2160)

Here, you have created that strange mixed format. Of course, the horizontal width is not modified, since the two images are still not stacked horizontally together. This will be accomplished later with the "StackHorizontal(Left, Right)" command, and after that command, you will obtain your 3840 x 2160 resolution. See here for the various resize filters available natively with avisynth.

Now, that modification is not sufficient to ensure a correct output by the player. You should also modify the values of the aspect ratios, so that the player will be informed that the format it has to play is not at all usual. Therefore, edit __ENCODE_3D.cmd to modify the sample aspect ratio included in the encoding command. In the normal Full-SBS format, the SAR should be 1:1, but it is probably 1:2 (or the opposite - honestly, I'm not sure). So, change --sar 1:1 to --sar 1:2.

Edit also the --aspect-ratio value in the __MUX_3D_OPTIONS.json file. In the // ### 3D video stream section, locate this:

	"--aspect-ratio",
	"0:32/9",

and change it to whatever your player may need to stretch the picture during the playback and obtain the correct display. This may be, for example:

	"--aspect-ratio",
	"0:16/9",

Or, maybe "0:16/18". Again, when playing with non-standard format, the correct aspect ratio values are difficult to determine, as they will depend of the interpretation by the player.
BTW, even in standsrd Full-SBS, the SAR and aspect ratios depend of the player. It's why there is a BD3D2MK3D option to modify them according to what your player needs. See Settings -> Full-SBS/T&B aspect ratio. With some luck, the aspect ratio values necessary to play your stretched video will be available via that menu, and you will not need to edit the two files to modify them.

I think I have replied to your Q1 and Q2 questions. For Q3, yes, the last tab deals mainly with the encoding options. You can perhaps replace the procedure described above with a resize option included in the Additional options field of the x264 parameters, like this:

--vf resize:3840,2160,method=lanczos

It's clearly easier (especially since you can save that option for later with Settings -> Save Tab Settings now), but personally I would prefer to do the resize operation with avisynth. And you will probably have to modify the aspect ratio values anyway.

For Q4, you know now how you can modify the avisynth script to include new commands. I have explained it for the resize, but you can add other commands as well. Just take in mind that the two views must be (almost) identical, as otherwise the effect on your eyes can be disastrous, so use only commands that will act on both views in a very similar way.

Good luck !

[VonHagenstein]

Thanks so much r0lZ for replying and for continued support of the tool. Stuff like that tends to be thankless job.
I kept digging after posting and was getting pretty close, but this should get me over the finish line.
I'm going to do a deep-dive soon to learn avisynth because I think that can only benefit me for other uses too.
As for the "Why" of this odd sounding format lol, I'll do my best to explain.
It's a "2 birds one stone" solution for my scenario. Maybe even 3 birds lol. And I'm overly-verbose, not on purpose, I just am for some reason, so I apologize in advance for that.

tldr; There are 2 types of displays I primarily view these files on: A VR headset and a large passive 3D television (approx. 85"). This "odd" format is the one I can most easily and universally use on both my VR headset and my 4K passive-3D TV via a media-server due to limitations my TV has on the type of formats for 3D content it can process. Doing it this way also allows for a single movie file I can view on both devices either directly (e.g. a computer connected to my TV via HDMI, or a file saved on the VR headset's storage) or via streaming from a media server, with no resolution loss and as little quality loss as possible other than what might occur due to compression etc.
Gory details follow...

As you already know, 3D Blu Rays normally contain frame-packed video with a separate 1920x1080 frame for each eye. If I take each of those 1920x1080 frames and "squeeze" them into an output video that is also 1920x1080 via the "Half" options, I am losing either half the horizontal resolution of each frame, or the vertical resolution, depending on whether I'm doing SBS or TAB. Which again, you're already aware of. Enter the "Full" options. Those do solve the resolution loss issues by stacking the full resolution frames next to each other, either horizontally or vertically to produce either a 3840x1080 or 1920x2160 video containing both the left and right eye images. Sorry again for "I'll take things I already know for $200 Alex..."

So the 3840x1080 or 1920x2160 frame sizes can work fine in my VR headsets. I have a variety of VR media "players" for those, the main one being "Bigscreen", which can simulate watching a movie in a theater with a large screen. It's quite convincing and I enjoy using it a lot. H-SBS, H-TAB, F-SBS, F-TAB, and even interleaved are all supported. So the regular presets in BD3D2MK3D do work just fine for that. For my LG 3DTV however things are more limited, unless I jump through some hoops.

Re. the 3DTV. It's a 4K passive display. 2D content can display at full 4K res with HDR. 3D content however is interlaced/interleaved with alternating rows of pixels for each eye. A polarized layer with rows of alternating polarization direction lets me use modern movie theater style 3D glasses that don't require batteries like active-3D (frame-sequential) displays use for viewing 3D content. The interleaved nature though means that, regardless of the display being 4K, the maximum vertical resolution ever available to me in 3D is going to be 1080p, although the horizontal resolution can still be 3840 (the display also supports the full 4096 spec.).

For 3D formats going into the TV, it can process frame-packed, H-SBS, H-TAB, or interlaced. Interlaced is problematic with it; it displays it, but there's some sort of processing that occurs and I've never gotten interlaced 3D content to line up 100% with the polarized lines such that no ghosting occurs. All other 3D formats are processed into the interleaved format by the TV itself for passive-3D-glasses viewing.

Formats that the TV cannot natively process however include F-HBS, F-TAB files, and frame-sequential. I wish it could. It would simplify things for me. I have to provide either 1920x1080 or 3840x2160 video (or frame-packed). With 1920p I'm going to lose either half the horizontal or half the vertical resolution of the image, since both the left and right eye images have to be "squeezed" into the image. With a 3840x2160 frame I can put both the right and left eye images into that with no resolution loss. But to accomplish that I have to provide a 3840x2160 frame to house the left and right eye images. As long as the full-res images are being stacked I don't lose any resolution but I still need to stretch or upscale them in the appropriate direction so that the fill the frame. My TV will not do that for me unfortunately, nor will it properly process a F-SBS/F-TAB 3840x1080 or 1920x2160 frame.

Using this format also solves another issue for me: Streaming 3D movies to BOTH my VR headset AND my TV without resolution loss.
If I didn't want to use a media server, I could play 3D movies from files on my TV simply by connecting a laptop/computer to it (or my original 3D Blu Rays via my 3D Blu Ray player).
Using Potplayer + "MadVR" and some plugins I can play nearly any format, even ".iso" rips directly. Interlaced and frame-sequential too.
With iso's or mvc-encoded mkv files that software combo can decode the individual left/right eye images into a variety of selectable formats and aspect ratios in real-time and it works great with fantastic visual quality. But I can't stream those formats to my TV with any current media server that I'm aware of. Plus those are quite large files, since they haven't been re-compressed to something more efficient.

Anyhow, I hope all that that explains the "why" part, if you or anyone else is curious. Even if I did use more words than needed to try and do that.
I'm a stereoscopy enthusiast of many years, having done stereo photography, videography, wrote my own anaglyph-conversion process that resulted in better looking color than any commercial processes I've seen, and continue to be interested in things like old stereoscope cards, View-Master reels, and obviously 3D movies lol. Always happy to meet others with similar interests. And there's not many people left still using a 3D TV (although there are still lots of 3D projectors in use). I may indeed be literally the only person that might want to use this formatting for 3D video lol.

[r0lZ]

BD3D2MK3D v1.37 released

Finally, there is a new version of BD3D2MK3D.

I did it because a new and very good MVC decoder is available. Jens Duttke is its author and he did a handy Avisynth plugin, compatible with BD3D2MK3D without too much work. It has also the big advantage that it is not dependent of an external API such as the Intel decoder. It should therefore work well without having to install some drivers and may even be compatible with BD3D2MK3D running under Linux and Wine HQ. It doesn't use the Intel hardware acceleration but it is really fast.

To select the new decoder, be sure to install Avisynth+ x64, then use Settings -> MVC Decoder -> Use Jens MVCSource.

Please note that this new MVC decoder requires Avisynth+ 64-bit. It you have not installed it, you can continue to use FRIMSource.

v1.37 (July 18, 2026)
- Added a new MVC decoder for Avisynth+ x64, made by Jens Duttke. Thanks Jens ! https://github.com/jens-duttke/mvc-source
- Updated x265 to version 4.1+239-8be7dbf (GCC AVX2)
- Updated the Mkvtoolnix tools to v100.0 ('Do Hot Girls Like Chords')

As usual, donwload the latest BD3D2MK3D version here or visit the BD3D2MK3D home.
Have fun with your 3D movies!

P.S.: Jens is also the author of Oku3D, a fun media player that can turn any 2D movie to 3D with the help of some AI magic.

[BenMcLean]

Thanks for all your hard work, r0lZ.

I have a bug report and got some LLM help writing it up:

Bug: launching with a disc folder as a command-line argument crashes on startup

Version: v1.37 (July 18, 2026) — confirmed this is the current latest version.

How to reproduce
Launch BD3D2MK3D with a BD3D disc folder as a command-line argument — the exact usage documented by BD3D2MK3D.exe /?:

BD3D2MK3D.exe "D:\Some 3D Movie"

Result
A "Script error!" dialog appears immediately on startup:

Error sourcing /zvfs/.../BD3D2MK3D.tcl: invalid command name "Get3Dplaylists"

Root cause
In the command-line argument handling near the end of BD3D2MK3D.tcl (the if {$argc > 0} { ... } block), passing a folder calls OpenBD $arg synchronously as the script is still being sourced. OpenBD calls Get3Dplaylists to parse the disc's playlists — but Get3Dplaylists is defined in toolset/MPLSParser.tcl, and that file is only sourced after the argument-handling block, right near the very end of BD3D2MK3D.tcl:

if {[catch {source [file join $::TOOLSETPATH MPLSParser.tcl]} err]} {
    ...
}

So on a fresh launch with a folder argument, Get3Dplaylists genuinely doesn't exist yet at the moment OpenBD tries to call it. Launching with no arguments and opening the disc afterward via File → Open Blu-ray 3D (or drag-and-drop) works fine, since by then MPLSParser.tcl has already been sourced — that's presumably why this hasn't come up before; it's a much less common way to launch the app than the GUI-first workflow.

Suggested fix
Either:

• Move the source ... MPLSParser.tcl (and AVC3Dmodifier.tcl) calls to before the if {$argc > 0} { ... } argument-handling block, or
• Defer the argument-triggered OpenBD call with after idle { ... } so it runs after the rest of the startup script (including those source calls) has finished.

Either should be a small, low-risk change.

[r0lZ]

Thanks for ypur excellent bug report, BenMcLean!
I will fix it as soon as possible. Fortunately, I guess you are probably alone using the command line argument to open the BD, as otherwise, the bug should have been reported sooner. Good finding anyway!

[BenMcLean]

Fortunately, I guess you are probably alone using the command line argument to open the BD, as otherwise, the bug should have been reported sooner.

I am trying to get an automated pipeline going so that I can rip my large 3D Blu-Ray collection with as few clicks as possible. For the purpose, I was hoping to just stop interacting with the GUI at all and automate everything but unfortunately, that doesn't seem to be possible without heavy modifications to BD3D2MK3D. This is what I have come up with: https://github.com/BenMcLean/bd3d2mk3d-boilerplate

I'm not sure whether the settings I went with actually make sense, but the idea is that I want a high quality future-proof archival format which is also able to play on both relatively recent and future consumer devices as well as doing the encoding on GPU. BD3D2MK3D's defaults seem to be geared towards a lower quality CPU-only path, probably for backwards compatibility with older 3D devices I don't own. What I'd prefer would be to find whatever settings are "correct" for the three goals of 1. Being able to play on current devices and 2. Being a future-proofed archival format so that I won't have to get the discs out again to watch on higher end devices that may exist in the future and 3. Encoding on GPU to save a massive amount of time. I'd appreciate if you could take a minute to advise whether I've done that or not with the settings I came up with r0lZ and thanks so much for all your hard work on this program!

[r0lZ]

I understand your will to encode (semi-)automatically your large collection of 3DBD. Unfortunately, BD3D2MK3D being essentially a GUI, it is not easy to do it with the current state of the program. IMO, the main difficulty is the selection of the audio and subtitle streams to keep (unless you want to keep them all anyway). Otherwise, personally, I would have tried to make a little Autohotkey script to interact directly with the GUI, but it is difficult to predict how the script will do its work in case of difficulties (such as an unusual dialog popping up because something strange happened). Honestly, personally, I don't want to waste my time in deeply modifying the current version of BD3D2MK3D. Normally, I should not work on any project any more, unless a bug has to be fixed, or an important but simple update is possible (such as the addition of the new MVC decoder in the latest version). Thanks anyway for your effort and for letting it available to other users.

For your questions about the encoding CPU or GPU based and its quality, I have adopted x264 as the standard encoder because it encodes in AVC (h264), and AVC is the only official way to encode 3D movies in SBS or TAB format. It's also the only encoding format that is supported by most 3D TVs. Of course, I understand that modern UHD equipment usually support HEVC (h265) but it's not the case of the hardware released during the boom of the 3D, soon after Avatar. Anyway, I have added the possibility to encode with x265 for peoples using a more recent TV or projector. Note that for the same reason, Half-SBS (or Half-TAB) is the default stereoscopy mode, as Full-SBS/TAB require larger buffers, usually not available with most 3D TVs (but of course available with UHD TVs, but UHD TVs are rarely compatible with 3D!). Full-SBS/TAB is theoretically not legit for 3D movies.

The default quality in BD3D2MK3D is indeed low (CRF 23 for x264 and CRF 28 for x265, and medium preset), but for that matter, I have adopted the default recommended by the authors of that encoders. That default values save much disc space, and it's the goal of many users. Anyway, it is easy enough to change the quality setting (and optionally record it as the default for later uses).

As you have noticed, it is also possible to use your own command-line encoder, including GPU based encoders. I have not added officially a GPU based encoder in BD3D2MK3D, because they are considered as largely less good than x264 and x265 and the speed gain is not very important. Personally, I did some tests with nvencc, but I continue to use x264 that offers the best results for my Samsung 3DTV.

Of course, I cannot guess what format will be mainly accepted in the future, but I am almost sure that the good old standard Half-SBS in AVC format will always be supported (although some picky projectors refuse it). Normally, a good player should be able to play old movies (as long as they have been created correctly). The primitive AVI format is still supported by most, if not all, software and hardware players, although it is certainly not recommended any more to go the AVI way! IMO, currently, h265 Full-SBS is probably the best compromise between quality and future compatibility, because UHD will almost certainly be the future of the video equipment. But I may be wrong! CPU or GPU encoding is of course not concerned by the compatibility problem, but has an important impact on the final quality.

I can't help much more.

[BenMcLean]

Thanks so much for your response. What I was kind of expecting would be that some setting or other out of the settings I chose might jump out as a major downside I wasn't aware of, but it appears that the main downsides are:

1. 3DTVs (and a few other niche older devices like the RED Hydrogen One) require h264 HSBS so that my h265 FSBS rips won't be backwards compatible with them. I find that an acceptable tradeoff, so long as the 3D devices I actually have (the Meta Quest 3, the Lume Pad 2 and the Acer Predator Helios 3D 15 SpatialLabs Edition) as well as the Steam Frame and future devices will be able to reliably play the files in high quality. 3DTVs have become super rare and I am hopeful that, should I ever acquire one, then pairing it with an external playback device which can do the h265 heavy lifting should suffice to make it work.
2. While GPU doesn't compress as small as CPU, choosing GPU is (I hope) a reasonably judicious tradeoff.
3. FSBS does not 3D-ify subtitles in BD3D2MK3D unfortunately.

I'd appreciate if you'd let me know if there are any other "red flags" I haven't anticipated in that assessment, because I do NOT want to invest a large chunk of my time into converting a ton of discs only to discover afterwards that I'm doing it all wrong for one of my goals or are failing to take into account some big concern other than the backwards compatibility with older 3D hardware that I know I'm dropping with this approach.

I suppose another fact I should probably have documented is that I'm depending on MakeMKV to do whole-disc rips to folders from the physical discs as the source for all this.

I am considering the possibility of making a new non-commercial open source project that would be heavily inspired by and based on BD3D2MK3D but which takes a CLI approach and which also solves the issue of how to 3D-ify the subtitles for FSBS encodes. No animosity towards you at all r0lZ: your work is what has got me interested in and fired up about how to archive 3D Blu-Rays!

[r0lZ]

I agree that, if you are not concerned by backward compatibility, h265 FSBS seems a good choice. Personally, I would avoid the GPU encoders, unless encoding speed is for you a major concern. I don't think that other red flags exist, but as I wrote in my previous post, I cannot predict the future !

MakeMKV is currently probably the best way to decode your physical 3DBD. However, it is supposed to become commercial when it will not be beta anymore. But honestly, I don't think that this will ever happen.

About your point 3 (3D subtitles in FSBS) : In fact, the problem is that the subtitles are officially limited to the Full-HD resolution. Even in UDH BD, the subtitles are still exactly identical to the ones found on classic HD BDs. The UHD player has the responsibility to upscale the subtitles at playback time. But for Full-SBS, it is necessary to create subtitles twice as large as what the standard permits. And, unfortunately, the current tools to manipulate subtitles (such as BDSup2Sub) are unable to create that illegal format. And including legit subtitles (made for HSBS) in a FSBS MKV doesn't work, due to the fact that the player must consider that the final video is in Full-HD and not UHD, and they have therefore no reason to upscale the subtitles. (Furthermore, even with an upscaling, it will be done in both directions, and that is not suitable to preserve the horizontal position of the subtitles). That's why real 3D subtitle streams cannot be used in FSBS (or FTAB) format. But BD3D2MK3D has implemented a solution : it is possible to "hardcode" (aka "burn") the 3D subtitles on the video. It's because the left and right subtitle streams are created independently, and they are hardcoded over the left and right video streams before that two streams are stacked together to form the final combined HSBS/HTAB video stream. That works pretty well and it's even easier to use than the normal 3D subtitle streams in HSBS, that must be printed by the player over the combined HSBS view BEFORE it is split in the two left and right channels. That option is only available in good players, and often difficult to find. With hardcoded subtitles, there is no difficulty : just turn the subtitles off! Unfortunately, there is a price to pay. You can hardcode only one specific subtitle stream, and, or course, you cannot watch the movie without the subtitles.

I have had a look at your current bd3d2mk3d-boilerplate project, although I have not tested it. I like the idea to retrieve the metadata automatically from IMDB. That would be a nice addition to BD3D2MK3D, but I don't think many W$ users will accept to install python just for that feature. But if you can do some kind of standalone exe to do that, or better, a Tcl/Tk script, I'll be happy to include it in BD3D2MK3D.

If I understand correctly what you are doing, your tool generates a command line to encode the final video, independently of what BD3D2MK3D generates. Right? If it's the case, I don't understand why you do not use the BD3D2MK3D option to "use your own custom command for encoding". When that option is enabled, you can type the command in the last tab, and save it for later use (with Settings -> Save TAB settings now). That will modify the __ENCODE_3D.cmd file so that your command will be used instead of x264 or x265. You will therefore be able to tick the option to launch automatically the encoding during the long process of the creation of the project. IMO, that will be easier than your current method. Or have I missed something?

[r0lZ]

BD3D2MK3D v1.38 released!

This version is mainly a bug fix. When opening a 3DBD or a 3D MKV from the command line, the program crashed. (Bug reported here. Thanks BenMcLean!)

v1.38 (August 21, 2026)
- Fixed bug when opening a 3DBD or 3D MKV from the command line. (Thanks BenMcLean!)
- Updated the Jens MVC decoder (libavsmvc.dll) to v8.0. (Thanks Jens!)
- Updated x265 to v4.3+13-fe9bc85 GCC

Download the latest version here or visit the BD3D2MK3D home.

[BenMcLean]

Thanks for taking a look! Actually, I am already using "use your own custom command for encoding" exactly as you describe: it's ticked, my NVEncC command is in the custom command field on the last tab, and it's saved.

The issue is specifically with "Exit and encode after successful demux" (autolaunch). The autolaunch trigger always launches __ENCODE_3D.cmd. That filename is hardcoded (set once, never reassigned) and used unconditionally, regardless of whether a custom encoder is configured. The custom command goes into a separate file, _CUSTOM_ENCODE_3D.cmd, generated by its own code block a bit further down. Ticking "use your own custom command" doesn't change what gets written into __ENCODE_3D.cmd. It's still the regular x264/x265 command in there, while the custom one only ever lands in the _CUSTOM_ENCODE_3D* files alongside it.

This matches the "Custom encoder help" text, which says the custom scripts get generated "in addition to" the standard ones, and that __ENCODE_3D_LAUNCHER.cmd is still there if we want to fall back to x264/x265. So ticking autolaunch with a custom encoder configured launches the x264/x265 script, not the custom one. I have to launch _CUSTOM_ENCODE_3D_LAUNCHER.cmd myself once demuxing finishes.

It would be nice if autolaunch checked whether a custom encoder is configured and launched _CUSTOM_ENCODE_3D_LAUNCHER.cmd instead in that case.

[r0lZ]

BD3D2MK3D v1.39 released!

I have fixed the problem of the option to encode immediately. Now, the custom encoder is used if you tick the option in the little progress dialog shown when the project is generated and the custom encoder is selected in the settings. (The message of the option shows also if x264, x265 or the custom encoder is used.) Thanks again BenMcLean!

I have also discovered that the new x265 exes trigger a virus warning by Windows Defender. I guess that it's a false positive (as usual with M$), but it's annoying anyway, so I have decided to revert to the version distributed with v1.37. It's also why I have released this new version as soon as possible.

v1.39 (August 21, 2026)
- The option to "Exit and encode after successful demux" launches now the custom command if that encoder is selected in the options. (Thanks again BenMcLean!)
- Reverted to v4.1 of x265 because v4.3 triggers a (probably false positive) virus warning in Windows defender.

Download the latest version here or visit the BD3D2MK3D home.

[BenMcLean]

I like the idea to retrieve the metadata automatically from IMDB. That would be a nice addition to BD3D2MK3D, but I don't think many W$ users will accept to install python just for that feature. But if you can do some kind of standalone exe to do that, or better, a Tcl/Tk script, I'll be happy to include it in BD3D2MK3D.

I could provide the TMDB feature but it would be LLM slop code for two reasons:
1. The original Python version was a quick and dirty maximum lazy LLM-generated piece of trash in the first place, the point of which was strictly to save me time grabbing the metadata, not to brag about how great of a coder I am and
2. I don't actually know Tcl/Tk. I have enough general coding knowledge that I expect I'd be able to know what comes out is reasonably on topic despite not knowing this specific language but not the deep understanding required for actually high quality "I'd be proud of this" work which can guarantee no memory leaks, race conditions, etc.

If you're OK with it being a low effort "AI slop" module (But contained in a module so that you can always just delete if it stops working and you don't feel like fixing it) then I don't mind trying to slap it together for folks cause it would speed me up too if I could eliminate a step with this. Otherwise, I can just keep clicking my current python script, no big deal. It was 262 lines in Python so it's pretty small. Let me know which way you're leaning given this additional context.

Another "nice to have" feature would be to allow adding a description for each audio track so that I could label the commentaries. Most of the old timey films that come out from 3-D Archive have commentaries and Handbrake lets me add a description for them but BD3D2MK3D doesn't.

[r0lZ]

Thanks for your proposal. Indeed, it would be great to have a way to retrieve the most important metadata automatically from IMDB. The way it works or it is coded doesn't matter for me, as long as it can easily be interfaced with BD3D2MK3D. A command-line tool would be perfect. Of course, it is up to you to judge if the necessary work worth it.

Regarding the description of the audio (and subtitle) tracks, I agree that BD3D2MK3D does the minimum strictly necessary. I have not tried to support all possibilities offered by MKV as there are many flags and metadata (such as, for example, the "original language" and commentary flags). I have assumed that most peoples want only to arrange the audio streams so that their preferred language is played by default.
However, the philosophy of BD3D2MK3D is to be as open as possible. Therefore, it is possible to edit the mux options file to add any missing flag or the stream label, but that requires some additional work with a text editor. Another way would be to simply remux the final MKV with Mkvtoolnix, that offers all possibilities. Sorry, but I don't think I will modify the streams selection tab, partially because most peoples do not need more features, partially because there is not enough room in the GUI, and essentially because I'm lazy, As I wrote above, I don't want to work anymore on programming projects. I'm becoming old, I live now in Southern France, under the sun, and my computer should stay off most of the time. I hope you understand.

[BenMcLean]

OK but my script doesn't actually use IMDB, it uses https://www.themoviedb.org/
I can try to put something together soon.

[BluDave]

Just ripped my collection of 88 3D Blu-Rays using MakeMKV and BD3D2MK3D. All worked great except one, a 1953 Rock Hudson western named "Gun Fury", released by Twilight Time. MakeMKV worked fine for reading the disc, but something triggered an error in BD3D2MK3D. Attached is a screenshot showing the error in the mux'ing and a log file. Thanks for any advice you can give. -- David

[r0lZ]

Hum ! The log seems absolutely normal so it's probably not a problem with BD3D2MK3D.

The error produced by avisynth is strange. I have never seen that. I have no idea of what means "Not expecting more than one bitmap per descriptor!" but obviously, something is abnormal in one video stream (or both?)

I know that it is possible to convert Gun Fury therefore I guess that the problem might be caused by a wrong first operation : the conversion to the initial MKV with MakeMKV. I suggest to retry, and if that doesn't work, try to convert the BD to a decrypted ISO and use the ISO as input. Or, with some luck, you can try to process directly the BD - some old movies are not protected and processing the BD directly may work.

Another thing to try is to use the other MVC decoder within the AVS script. If you have used the latest version of BD3D2MK3D, the script contains the two ways to decode the video. It is easy to change them without re-creating the whole project. Just be sure to change the commented out lines. (The lines beginning with # are treated as comments.)
Example (this version is for using Jens MVC decoder) :

[...]
# AVC/MVC video decoder
#LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\plugins64bit\FRIMSource.dll")
LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\plugins64bit\libavsmvc.dll")
[...]
# Load the two video streams (128928 frames per stream)
#interleaved = FRIMSource("mvc", "01001.track_4113.264", "01001.track_4114.mvc", layout = "alt", num_frames = 128928, cache = 2, platform = "")
interleaved = MVCSource("01001.track_4113.264", dependent="01001.track_4114.mvc", stack = "alt")
[...]

Of course, you can also simply change the Settings -> NVC Decoder option and retry.
However, I think that the problem is probably due to a bad rip with MakeMKV, so you have to restart the whole procedure anyway.

Sorry, I can't help much more. Good luck !

[BluDave]

Thanks for the quick reply, rolz. I'll try the things you suggest.

BluDave

[BluDave]

The problem with the "Gun Fury" BluRay disc seems to be that the subtitles are written on the disc in a way that SupTitle and SupCore (called within BD3D2MK3D) cannot handle. If I run MakeMKV and read only the video and audio, without any subtitles, then BD3D2MK3D works fine on the MKV file (but of course, the result has no subtitles).

If I run MakeMKV and read video, audio, AND subtitles, then BD3D2MK3D throws the previously noted error, no matter what I try. So, MakeMKV is preserving whatever problematic subtitles are on the disc, and SupTitle and SupCore are failing on those subtitles. (As further evidence, I can view the MKV file from MakeMKV in VLC and it does show the subtitles, even though VLC only displays the video in 2D.)

Is there any other way to read the subtitles from MakeMKV's MKV file without using SupTitle and SupCore, perhaps into a separate subtitle file with a format different than Sup, which can then be combined with the audio and video? If so, this seems like the only fix to this problem. Thanks...

BluDave

[r0lZ]

SupTitle.dll (or VSFilter.dll) is used only if you hardcode the subtitle on the video. Is it what you are doing ?

If you need only the subtitles as an independent stream, I suggest to try this. Generate the 3D movie without subtitles (with only the video and audio).

Then, you need the subtitle stream. You may already have it within an old project. It it's not the case, generate another MKV with MakeMKV with the subtitles (but you don't need the MVC stream). Extract the subtitle stream from that MKV with MkvExtract (with or without its GUI MKVExtractGUI2). Of course, it's the 2D version of the subtitles. Try to convert it to 3D with the independent subtitle conversion tool in BD3D2MK3D. That may work or fail; I don't know. Finally, you can mux the 2D and possibly 3D streams with the final MKV with the MkvToolnix GUI.

Note that you can convert the subtitle stream to 3D with SubtitleEdit. It is unable to use the 3D depth information so the subtitles will be "flat", on the surface of the screen, but since there are no 3D Planes (offset sequences) within the MVC stream of Gun Fury, you will not lose anything. If the conversion with the BD3D2MK3D tool fails, it's probably a good solution.

Note that if the conversion to 3D has been successful, you can also edit the AVS script to hardcode the subtitles over the video. Just uncomment the two lines necessary to do it (in the first project), and add the path name pointing to the 3D subtitle stream. Then, restart the encoding by double-clicking __ENCODE_3D_LAUNCHER.cmd. Note that the format of the 2D and 3D streams will be BD Sup. If you really want another format (why?), you can convert it to, for example, DVD Sub with SubtitleEdit.

If you can extract the 2D subtitle stream, please write me a PM. I would like to examine it. Thanks in advance.

[BluDave]

Rolz, thanks again for the detailed response. Yes, I want the subtitles hardcoded on the HSBS video. I'm sorry; I should have mentioned that earlier. I'm also using VLC to convert the final MKV file to MP4 (after BD3D2MK3D). I know this isn't necessary and might degrade the quality a little, but my goal was to create the simplest possible HSBS file that would work on the largest range of software and devices, and MP4 seemed to be a good choice.

Here's what I've been able to do: Given the MKV file produced by MakeMKV, I've been able to use "mkvextract" to extract the (2D) subtitle track to a "subtitles.sup" file. Then I can use the subtitle tools in BD3D2MK3D to convert the subtitles to 3D (producing a "subtitles.3D.sup" file). I'll send you a link to these in a PM.

Then I edit the .avs script to load the "SupTitle.dll" plugin and to call it on the "subtitles.3D.sup" file. But running the "__ENCODE_3D_LAUNCHER.cmd" script then bombs with the same "Not expecting more than one bitmap" error I have seen a hundred times.

Is there a way to use "mkvmerge" (or something else) to merge the 3D subtitle file with the audio and video, that won't go through SupTitle? Or can the subtitle file possibly be edited to avoid the error?

BluDave

[r0lZ]

MkvMerge can be used to merge (add, or technically multiplex) the subtitle stream to the MKV, but it cannot be used to hardcode the subtitles on the video.

Obviously, there is something special in the 2D subtitle stream. The conversion to 3D, although possible, fails in some way that makes the resulting 3D stream incompatible with the SupTitle avisynth plugin. I will have a look soon but I can't do it today.

In the meantime, I suggest to load the 2D subtitle stream in BDSup2Sub++ (present in the toolset folder of BD3D2MK3D) and resave it under a different name. Then, try to convert that new 2D version to 3D, and use the new 3D version to encode the movie. I'm not sure, but perhaps that will work. You may also want to try BDSup2Sub.jar the same way.

Another thing that may work is to convert the subtitles to 3D (with BD3D2MK3D) using the IDX/SUB (VobSub) format (instead of the BD SUP format). The quality is less good (it's DVD quality) but the result might be compatible with the VSFilter avisynth plugin. You will have to edit the AVS script to use VSFilter.dll and the VobSub filter.

Also, when you convert a stream to 3D, tick the option to "Verify input subtitles to skip malformed and monochrome subtitles". That may help.

[r0lZ]

I just had a quick look. Unfortunately, loading and re-saving the 2D (or 3D) stream in BDSup2Sub (++ or jar) doesn't work. But using VSFilter/VobSub works perfectly (at the price of a less good quality). Therefore, it seems that the problem is in SupTitle.dll or SubCore.dll. That filter is not my work, so I cannot fix it, sorry. I will report the bug in its Doom9 thread.

Currently, I suggest to use the VSFilter. Just convert the 2D stream to 3D using the VobSub format. Then, edit the AVS script to load the VSFilter dll and use VobSub instead of SupTitle.

But I noticed a bug in BD3D2MK3D related to the VSFilter. Depending of your settings, the opening quotes may be missing in the LoadPlugin command. If it's the case, the AVS script will fail. Just add the quotes, like this :

LoadPlugin("path\to\BD3D2MK3D\toolset\plugins64bit\VSFilter.dll")

Using the VobSub plugin is currently the best solution if you really want to hardcode the subtitles. Anyway, there is nothing abnormal in the subtitle stream, and the conversion to 3D is apparently perfect. I really don't know what is the cause of that strange error message about multiple bitmaps. Perhaps the author of the SupTitle filter will understand the problem and fix it, but that will probably require some time.

[r0lZ]

OK, I did several additional tests. First, I have discovered that the original 2D subtitle stream produces the same error. It's very strange, because the first step of the conversion to 3D consists in saving all subtitles as PNG images. The PNG images are then converted to 3D and finally re-encoded as the final 3D SUP file. I can't understand how it is possible that a problem in the original stream survives through that two conversions up to the final 3D stream. That's puzzling.

I have also tried to convert the XML/PNG files produced during the conversion to 3D to SUP with the ++ and JAR versions of BDSup2Sub, but although the error message is different, the problem subsists. Same problem when exporting the SUP file with SubtitleEdit. I give up.

Sorry, but currently, the only solution is to use the DVD SUB format.

[BluDave]

Thanks for investigating this problem. But I have good news: Your latest suggestions worked for me! I ran BDSup2Sub++x64.exe, from the BD3D2MK3D/toolset directory, to convert my 2D subtitles to the DVD format. Then I converted those subtitles to 3D using the Subtitle Tools in BD3D2MK3D. Then I edited the "__ENCODE_3D_MOVIE.avs" script to load the VSFiles.dll plugin and to call VobSub on the new 3D subtitle file. Running the "__ENCODE_3D_LAUNCHER.cmd" script then produced exactly what I wanted (MKV file with HSBS video and hard-coded 3D subtitles). Thank you so much for all your help!

BluDave

[r0lZ]

Thanks for the confirmation.

[r0lZ]

BluDave, if you are interested in the explanation of the problem, have a look at the discussion at Doom9. It's somewhat technical but the problem is caused by a "big" subtitle that must be encoded in a special way (multiple ODS) and the SupTitle avisynth plugin doesn't handle it correctly. Unfortunately, the source code is lost, so the bug will not be fixed. Luckily, it is possible to convert any BD subtitle stream to 3D in DVD SUB format with BD3D2MK3D. The quality is not optimal, but at least, you have your video with the subtitles.
Thanks again for having reported the problem.