This is the official BD3D2MK3D support thread at VideoHelp.
BD3D2MK3D is a tool to convert a 3D blu-ray (or a 3D AVC+MVC MKV created with MakeMKV) to Half or Full side-by-side (SBS), top-and-bottom (TAB) or frame-sequential (FS) 3D MKV.
BD3D2MK3D home (hosted at VideoHelp, thanks Baldrik !)
The current version of BD3D2MK3D is v1.19.
The latest version of BD3D2MK3D cal always be downloaded here: BD3D2MK3D.7z
The full modification history can be viewed or downloaded here: Version history
Please post all feature requests, bug reports or general comments about BD3D2MK3D in this thread, or at the BD3D2MK3D thread at Doom9. I will try to reply as soon as possible.
An old thread about BD3D2MK3D up to v1.17 can still be viewed here at Doom9. It contains a lot of useful information but is now closed. A search for BD3D2MK3D here or at Doom9 can also be useful.
Happy 3D viewing !
+ Reply to Thread
Results 1 to 19 of 19
BD3D2MK3D v1.18 implemented several fixes and little improvements:
v1.18 (December 24, 2019)
- Added Subtitle Tools -> Crop Transparent XML/PNG Background to remove the useless invisible parts of a XML/PNG subtitle stream. This may be necessary fo convert full-width subtitles to 3D.
- The --alpha-crop 0 argument has been added to all BDSup2Sub command lines so that it will not crop the transparent background of the XML/PNG streams any more, except when necessary.
- The Verify 3D-planes Compatibility subtitle tool has been improved to include a global score indicating roughly the compatibility of each 3D-Plane with the analysed subtitle stream.
- The presence of all required files in the toolset folder is now verified at startup, as some antivirus software may quarantine some exe files due to false positive.
- Fix: eac3to crash when an AC3+ audio stream is converted to stereo.
- Workaround for a possible bug when checking for M$ .NET v4 on some systems.
- Little bug fixed: The _POSTPROCESS_2D.cmd file was not executed after a 2D encoding due to a typo in the filename.
- Updated x264 to the latest version (v0.159.2991)
- Updated mkvtoolnix to the latest version (v41.0.0 "Samarra")
- Updated the Intel library libmfxsw32.dll to version 184.108.40.206
- DGMVCDecode is now withdrawn and has been removed. It was useless anyway, and baby is happy.
v1.19 (January 1, 2020)
- The home of BD3D2MK3D has changed and is now http://download.videohelp.com/r0lZ/BD3D2AVS/index.html
- The support thread at Doom9 is now https://forum.doom9.org/showthread.php?t=177317
- There is a new support thread at VideoHelp here: https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-T...Support-thread
Thank you very nuch for this awesome application. I'm not an encoder expert, so I'm currently trying to understand how it works.
There is one parameter that is not clear for me, at least which value I have to setup: the CRF.
What I would like to understand if is it possible to approximately calculate the size of the final encoded SBS file. For example, I have one BD (40 GB size). I setup CRF=15 and I got a final file of 18 GB. So it's about 55% compression. I would like to compresso it at least 40/45%.
Obviously I can reduce the CRF value, but is there a way to calculate the right value before encoding?
No. By definition, the CRF mode compresses differently according to the content of the movie and the quality of the images. For example, a clean computer graphics movie (like a Pixar film) will be compressed very much (because the frames of a same shot are very similar to each other), but an old film with much noise will be less compressed (because the noise makes it difficult to locate similar parts in the images). It's the interest of the CRF mode: it produces always s similar quality for the same CRF value, regardless of the difficulty to compress the movie. But that means that the final file size is difficult to predict. I have read somewhere that lowering the CRF value by 3 has the effect of multiplying the file size of the video stream approximately by 2. But you need to encode the movie at least once to apply that formula, and I don't think that it is always correct. Also, a slower preset compresses better that the fast ones, so the CRF value is not the only thing to take into account. (The CQ mode is similar to CRF, but without the ability, that CRF has, to compress more when the human eye cannot see the details, such as in a fast moving action scene. It is therefore not recommended to use CQ.)
In the other hand, the ABR and 2-pass modes can be used to obtain a precise file size, but the quality will greatly differ for different films, even if they have the same length. It's why you should NEVER trust the numerous advices found on the internet claiming that a specific bitrate is necessary to encode a movie correctly. That doesn't take into account the fact that a movie is not another one. Only the CRF and CQ modes are smart enough to offer a constant quality, BECAUSE they DO NOT use the same bitrate for all movies. Note also that ABR is forced to obey the bitrate specified on the command line, but it doesn't know in advance what parts of the movie will be difficult or easy to compress, and it will therefore encode everything the same way. That means that some easy parts will have an unnecessary high bitrate, and the difficult parts will exhibit artefacts because the bitrate is not sufficient for the difficulty. 2-pass is supposed to solve that problem, as the first pass is used mainly to analyse the difficulty of the encoding, and the second pass encodes according to the stats produced during the first pass. Although much better, the result is not perfect, as the first pass is a relatively fast analysis, that doesn't take everything into account. Constraining the bitrate is always a disadvantage, even if it is possible to minimize it. Therefore, the 2-pass mode is always slightly less good than CRF for the same global bitrate, and ABR is certainly the less good option. Of course, another drawback of 2-pass is that the encoding takes much longer.
Also, I really think that the bitrate of most commercial BDs is selected specifically so that the movie doesn't fit on a single-layer BD. It's probably some kind of protection and certainly a selling point. x264 and x265 are very good encoders, able to offer almost the same quality than a commercial BD for a much smaller file size.
So, my conclusion is that you should always use the CRF mode, unless you really need a specific bitrate or final file size, for example to burn the MKV on a DVD with the best quality possible. In that case only, 2-pass with file-size control is recommended. And trust your eyes instead of the misleading advices about the bitrate. It is perfectly possible to encode a clean movie with a very low bitrate. Just find the good CRF value for you, and use it for all movies.
Thank you for the very good detailed answer. So I'll go to CRF for sure, the space occupied by final SBS mkv is not a problem for me since I'll keep my file in my NAS with enough space. So I'll try with CRF 12 and let's see.
Thanks for the continued updates to this most excellent app!Steve
I'm trying to rip my (UK?) 3D Blu-ray of Avatar for watching in VR, using MakeMKV and BD3D2MK3D. I've ripped a bunch of other films and they all went fine.
Problem is with Avatar it has some automatic subtitles for the Na'vi speak, so there's 2 English sub tracks, but every time I render the movie with BD3D2MK3D these subtitles are getting squashed together, so every single line in the movie gets a subtitle. Obviously what I want is the original experience with just subs on the Na'vi speak.
The actual MKV produced by MakeMKV is perfect, it has both of the English subs. When I load it into BD3D2MK3D it shows 2 English subs, but I just can't get them to stay separate when BD3D2MK3D renders the file. I always end up with a single Eng sub track, or with none.
I've tried about 10 times now (2+ hrs each attempt) with every variety of the below settings I can think of. I've tried separating the 3D planes, just selecting one of the Eng sub tracks, selecting both, selecting everything etc.
Thanks in advance for any help. Related pics-
Last edited by fish998; 20th Mar 2020 at 10:21.
I don't remember right now how the subtitles of Avatar are authored.
Unfortunately, in an original BD, there are two possibilities to author the forced subtitles (the Navi subs in Avatar) :
The complete English subs and the forced subs (Navi) can be in their own streams. This means that there are at least two physical streams with the same language code. It's the most frequent case, and the easier to understand. You should only need to determine precisely in what stream the subtitle you need are authored, and select that stream in MakeMKV. (With this method, the MakeMKV "(forced only)" sub-streams are useless and can be ignored.) Usually, the first stream available in a specific language contains the complete subs, and the second the forced subs only, but in rare circumstances, that can be the opposite, or the second stream can contain specific subtitles like the subtitles for hearing impaired, or the director comments. The only way to be sure is to play the original BD with a good player, that doesn't swap the subtitle streams. Of course, it does not hurt to select all streams in the languages you are interested in, just to be sure to rip all potentially useful streams, but you will have to determine what stream contains what later, with a player and BD3D2MK3D.
The second authoring method is when the forced (Navi) subs are mixed in the same stream, with all English subs, and simply individually marked as forced with the "forced" flag. MakeMKV offers always an option to extract the forced subtitles "sub-stream" only. as if it was a real independent stream. You should select it (and if you are sure that you don't need the other subs, leave the other subtitle streams unticked, to have less confusing streams in the final MKV). See the example I've uploaded (the Russian forced sub only is selected).
Unfortunately, MakeMKV (like BD3D2MK3D) has no way to know what method is used with a particular BD without a very long processing (involving to demux the subtitle streams), and therefore you cannot guess what method to use when you are in front of the MakeMKV GUI. I suggest to tick all streams, including the "(forced only)", in the language you want to include in the final SBS. You should be able to determine later what stream to use with a good player. Unfortunately, a MKV file cannot contain subtitle streams with some subtitles marked as forced and others not, so the only method to leave the two possibilities to the user is to include the two streams.
When you have generated the AVC MKV with MakeMKV, play it with a good player. I suggest to use PotPlayer, but any player that doesn't change the order of the streams should be OK. (You can even start the playback of the MKV with the associated player with the Preview button in tab 1 of BD3D2MK3D.) In the player, select each subtitle stream one at a time and play various segments of the movie until you are sure of the content of each stream. In BD3D2MK3D, select the stream(s) you want to add in the final SBS or T&B MKV in tab 2 (and, if you want so, the stream to hardcode over the video in the last tab).
So, there is nothing really difficult, but I agree that the lack of preview in MakeMKV and the two different authoring methods of the forced subtitles can be confusing. Anyway, the secret is to determine the content of each subtitle stream, including the forced-only sub-streams, with a good player, and note their order. BD3D2MK3D shows always the streams in the order of the MPLS, as all good players and ripping software should do. Most of the confusion comes from the fact that many players change the order of the streams without a good reason.
Right, had a look at the log and there's definitely an error with the default Eng subtitle track (track 8). I've attached the log but the relevant bit is-
Loading E:/Avatar 3D/MKV3D/MKV3D.track_8.Eng.sup
Detected 83 forced captions.
child killed: unknown signal
*** BDSup2Sub close error: child killed: unknown signal
*** Found 102 captions, including 83 forced captions.
ERROR: Can't convert "MKV3D.track_8.Eng.sup" to XML/PNG format!
Btw I realize now that the 2 Eng Subs aren't getting smushed together, just the failed track 8 is missing. Track 7 has subs for all dialogue including the Navi stuff.
Last edited by fish998; 20th Mar 2020 at 14:28.
OK, I'm not very surprised. I wrote this in my previous post:
Normally, a 3D movie is stored in the 3DBD as two different M2TS, the main and dependent M2TS, merged together as the SSIF. The first one contains everything necessary to play the movie in 2D: the main 2D video view, the audio and the subtitle tracks. The dependent M2TS contains the additional material to play the movie in 3D: the AVC video stream (the dependent 3D view), and the 3D-Planes (aka offset-sequences) to display the subtitles properly in 3D. But the dependent M2TS must NOT contains the subtitle streams, only the 3D depth values.
Avatar and a couple of other movies do not obey this rule. The dependent M2TS contains also some subtitle streams, with single full-screen subtitles with warnings like "Put your 3D-Glasses now!". I don't know why they did that, but the fact is that for each regular subtitle track in the main M2TS, an obscure track with the same UID exists in the dependent M2TS. If the player or demuxer (or in this case MakeMKV) uses the combined SSIF file instead of the two M2TS to do its job, it cannot distinguish the parts of the subtitle stream pertaining to the regular 2D M2TS from the one from the dependent M2TS, since they share the same UID. These two mixed streams confuse the player/demuxer, and it may crash, issue a lot of error messages or just do what it thinks is correct, but with a bad result.
It's why I have abandoned eac3to to demux the 3DBD, and opted for tsMuxeR, that can demux only the "good" subtitle streams, without errors. I don't know how MakeMKV works, but it may be the culprit. (However, I'm not sure, as it seems to be capable of demuxing correctly the complete English subs.)
I can only suggest to use another method to decrypt your 3DBD in this precise case. If you can manage to create a decrypted ISO, you can normally safely use BD3D2MK3D directly to process it.
Sorry, but I can't help much more.
I used the following two for mats 1> "--profile high --ref 5 --deblock 1:-3:-3" and "profile=high:ref=5:deblock=-3,-3" but in both it was unable to open 3DMKV.h264
can anyone show me an example how to write those commands in additional option?
Is it a warning in the command prompt window when you begin the encoding ?
Also, you can see the final command in __ENCODE_3D.cmd. Please verify that there is no mutually exclusive arguments. In particular, the preset and level specified in the GUI are passed automatically, and they may not be compatible with your arguments.
Anyway, you should not need the quotes in the arguments. They are passed to the command as you have typed them, and with the quotes, the whole content will be considered as a single argument. Similarly, afaik, the = are not supported by x264/x265.
Honestly, I'm not sure that specifying arguments yourself makes much sense. Currently, the Presets are very well designed, and usually, the commands lines found on the internet give less good results than the equivalent preset. So, imo, unless you really need to specify some arguments, you should avoid them.
If you can understand the problem, and if it comes from the way BD3D2MK3D handles the command and the additional arguments, please let me know. I may have to fix a bug...
I did a short test, with CRF 18, preset slow, tune none, force level 4.1 and 8-bit of colour, plus your arguments:
--profile high --ref 5 --deblock 1:-3:-3
The result is OK, and plays correctly with 10 different software players, and with my (capricious) Samsung 3D TV.
What player or hardware do you use to play the final MKV file ?
I can only repeat that most of the times, the recommendations on the internet are useless at best, and often completely wrong.
Anyway, if you insist to use your parameters, try them. As I wrote above, they work. Unless you have a conflict with the other parameters, and in that case, the warning should explain what's wrong. Without more info, I can't help you.
edit: BTW which one of the following should i select? left or right?
Last edited by WiNT3R; 28th Mar 2020 at 22:46.
MakeMKV is supposed to add the correct left/right information in the AVC+MVC MKV file it generates, and BD3D2MK3D should just need to retrieve it. But I have had to add the possibility to change it manually because at the beginning, that information was not included in the MKV created by MakeMKV, and later, when they have added the information, a bug was present that made the left/right info often wrong. I suppose that currently, the information is correctly retrieved in the original BD3D and written without bug in the MKV, but honestly, I'm not sure, so the possibility to overwrite the order detected by BD3D2MK3D is still available.
Anyway, unless you see a warning highlighted in red in the first tab, explaining that the information has not been found or that you are using an old version of MakeMKV, known to have the bug, you should not modify the left/right setting yourself. It is hopefully correct. Note also that the vast majority (perhaps 95%) of the movies are encoded in the "classic order": left-view in the main AVC stream (and of course the right view in the dependent MVC stream), so if you are not sure, try that first. But if BD3D2MK3D has selected automatically the other option (Right view in AVC stream), then you should normally leave it as it is. And if the views are inverted in the final SBS, please report the bug to the authors of MakeMKV. BD3D2MK3D cannot guess that information if it is not properly included in the source MKV.
You can also click the [?] button to see more info about that option and how to use it.