BD3D2MK3D v1.17: Convert 3D BDs or MKV to 3D SBS, T&B or Frame-sequential MKV

[r0lZ]

Adding an option to replace the spaces with a dash, an underscore or a dot should be feasible. But no, BD3D2MK3D has never used the underscore. A space is a space, and should be left as it is. We are in the 21th century, and the 8.3 file names without spaces are a thing of the past. IMO, if you have a player or TV that doesn't support the spaces in file names, you should return it to the store for malfunction! But don't worry, I'll try to do what you want. BTW, it will replace ALL spaces in the whole file name with the selected character, not just the last space before the "postfix". Is it OK?

The gaps between the two views of a movie depend of the original BD, and are not due to BD3D2MK3D. I can't remove them. And anyway, a good player should recognise the 3D format automatically with the frame-packing flag in the video stream, or with the stereoscopy option of the MKV container. They are added automatically by BD3D2MK3D anyway, and there is absolutely no need to analyse the image to discover that the file is a 3D movie. (However, I agree that that analysis may be useful for movies badly encoded with programs that do not set these options properly, as it's the case with most 3D movies posted on the internet.) Again, if your player doesn't recognise the 3D format, you should return it to the store! ;-)

[CaBleman]

Hey r0lZ,

thx for the quick reply. The spaces can become a problem in scripting, especially with my Synology NAS; and maybe it was only on the folder level
but at some point I decided it was safest to use the Underscore throughout all file names. Yet I totally agree with you that it shouldn't have to be that way.
Thanks for offering the option, and yes, globally in the file name is fine.

The auto recognition via analysis fails on a fairly new Sony 3D TV, but the player I use is an old Popcorn Hour C200,
which does not interpret any 3D flags and may not even send this information to the TV.
That's where SBS comes in handy: the player does not need to know ;)

I know the gap is not BD3D2MK3D's responsibility - it was just the first time for me and I wanted to know more about it... thanks again!

Bye,

CaBleman

[CRFOnly]

I just came back here to see there is a new version of the program (havent tested yet but it's a matter of time hehe).

I'm glad you fixed the 2d sup forced subtitle problem, it was the only thing i didnt liked. Now everything is perfect, even better than when i started using your software. You did an error in my nickname in the changeslog but honestly i dont care much, the important thing is its fixed and this software rock. Ima probably try it really soon and come back at you.

Keep rocking!

[r0lZ]

Here is the new version, with the possibility to replace the spaces in the file names as requested above, and a new tool to verify the MKV files (useful if you have sometimes some MKV files that are not correctly muxed due to USB problems).

Enjoy!

# v0.55 (November 14, 2014)
# - Added the Settings -> Output File Name menu, with the possibilities to replace the spaces with another character and to specify the extension.
# - Added Tools -> Verify MKV File to verify if the specified file has been correctly muxed.
# - When converting a subtitle stream to 3D, the Depth tag is added anyway in the temp 2D XML file, even if no 3D-plane has been provided.
# - Bug fix: The Arcsoft DTS decoder was not used to convert DTS to AC3 during the main process, even when it is available.
# - Minor cosmetic changes.

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[RipFan]

Thanks a lot for all your work on this, i really appreciate:thanks:

How can i change some settings like: deblock, subme, me_range, vbv-bufsize and vbv maxrate?

What can i write in: "Additional options" that can be assumed?
The "language" it's the same that we read in media info, for example?

Like this one: --deblock=1:-2:-2 --me_range=64 --subme 10 --vbv-bufsize 48000 --vbv-maxrate 40000

Since there's no options to change in x264 parameters directely, i'm asking this here to you or to someone who may help.

I'd like to be abble to change some final results like those settings above.

If there's no chance at all it's ok anyaway, this a great tool.
Congrats for all your work on this man.

Cheers.

Note: If my english is bad, i'm sorry:rolleyes:

[r0lZ]

I really appreciate your appreciation! ;-)
And your English is not bad; don't worry. Mine is probably worse.

You can write any x264 parameter in the "additional options" field, except those that are already defined by BD3D2MK3D. You can easily discover what parameters BD3D2MK3D sets for you just by trying a conversion of a short clip without additional parameters. Load the _ENCODE.cmd file in a text editor to examine the x264 parameters that have been added automatically to the command line.

Deblock, subme and me_range are never set directly by BD3D2MK3D. You can therefore define them yourself.

The vbv-bufsize and vbv-maxrate parameters are set accordingly to your level setting. For example, if you select level 4.1, BD3D2MK3D adds automatically --vbv-bufsize 78125 --vbv-maxrate 62500 to be compatible with the selected level (assuming profile high). If you want to specify other vbv params, then you should NOT specify the level. (Use "do not force"). In that case, the level, the profile and the vbv parameters are up to you.

The preset, the encoding mode and the CRF/CQ/bitrate value are always set according to your selection.

The frame-packing is also defined, depending of the selected SBS or T&B mode.

A default qpfile is also defined, to force an I frame at the beginning of each chapter. (It's necessary to avoid problems when seeking from chapter to chapter with some players.)

Other parameters are automatically set, of course: --output and --frames. (You can overwrite --frames if you wish to encode only the beginning of the movie to do a quick test: just specify it in the additional parameters field, and BD3D2MK3D will skip its automatic setting.)

Note that you can save your default settings with Settings -> Save Settings Now. (You should not tick Save Settings on Exit, as otherwise they will be overwritten each time you change them.)

The language is not defined by an x264 setting, but by the muxing options of mkvmerge. It is automatically retrieved from the original BD. (You can change it if you wish by editing the _MUX_3D_OPTIONS.txt file.) And yes, it's the language that will be displayed by any player, or by MediaInfo. No language code is associated with the video stream (that is undefined by default).

[RipFan]

Thank you for your quick response:)
Now i'll be able to choose some settings myself.

Thanks for all and good luck for your projects and for your life too;)

Best regards

[r0lZ]

Thanks.
Have fun watching 3D movies! :-)

BTW, I forgot to explain that if you tick the "BD compatible" option, a bunch of options are specified automatically. But I suppose that you don't want to encode for a BD.

[RipFan]

Thanks for the additional info:thanks:

[bottom]

Hi

first of all:
Thanks, it's really a fabulous software!!!

Here are some minor things i noticed:

- The subtitle resize filter is selected/displayed as "lanczos3" in the GUI,
but the log-file always says: "Resize filter: Mitchell"

- Subtitle creation:
If "Both" (IDX and SUP) and "3D first, then 2D" are selected,
the resulting batch file ("Mux3D") often didn't match the subtitle files/streams that were actually created:
(forced subtitle files were missing completely,
filenames of 2D streams were missing the "2D" string, ...)

- There seem to be updates available for some of the tools:
tsMuxeR, mkvmerge, x264
(yes I know: 'newer', doesn't always mean 'better'!)

- There are some movies, where Left and Right View seem to be swapped.
The problem is already on the BluRay itself!!!
...but can this be handled / fixed by BD3D2MK3D somehow?
(Using "FRIMDecode" and the commandline option "-swaplr"
I could manually (and laboriously) create a working SBS video stream)


Thanks again!

bottom

[r0lZ]

Hi

first of all:
Thanks, it's really a fabulous software!!!
Thanks!


Here are some minor things i noticed:

- The subtitle resize filter is selected/displayed as "lanczos3" in the GUI,
but the log-file always says: "Resize filter: Mitchell"
I have to verify, but there are 2 methods to convert the subtitles to 3D. The simplest one uses the filter defined in the Settings menu, and is based on suppe3d, itself using BDSup2Sub for some conversions and the resize. That method cannot generate the subtitles with the correct depth, and is therefore not used any more during the main process. It is still present in the Tools menu, because it is faster and easier than the other method, and still good if you want to convert a subtitle file downloaded from the internet and you don't have a 3D-plane.

The second method is based on ImageMagick, and it uses the 3D-planes to generate 3D subtitles with the correct depth. It's the conversion used during the main process. The resize is made with ImageMagick itself, during the conversion to 3D, and BDSup2Sub is used only to convert the 3D XML/PNG files to SUP or SUB, but not for the resize. The filters are therefore different. The default resize filter for that method is Mitchell. You can change it if you use the GUI from the Tools menu, but currently, it is not possible to modify it when the conversion of the subtitles to 3D is made during the main process. I'll add an option to control that setting too, but IMO Mitchell is excellent for the subtitles (probably better than Lanczos; Read the ImageMagick doc about the resize filters if you are not convinced. Anyway, don't be too picky for the quality of the subtitles. They are just subtitles after all!)


- Subtitle creation:
If "Both" (IDX and SUP) and "3D first, then 2D" are selected,
the resulting batch file ("Mux3D") often didn't match the subtitle files/streams that were actually created:
(forced subtitle files were missing completely,
filenames of 2D streams were missing the "2D" string, ...)
Strange. I have verified that part recently, and I didn't find any problem. I'll have a look anyway, but you can perhaps help me. Can you provide a concrete example (with the list of streams that have been selected and their options or a screenshot of tab 2, and the resulting file names of the created subtitle files, as well as the MUX_3D_OPTIONS.txt file)? Thanks.


- There seem to be updates available for some of the tools:
tsMuxeR, mkvmerge, x264
(yes I know: 'newer', doesn't always mean 'better'!)
I just did the update of MkvMerge yesterday. The next version will be up to date.
I will probably never update tsMuxeR 3D any more, because its development has ended, and the latest versions are full of bugs. AFAIK, the version currently distributed with BD3D2MK3D is the best one. You can try to replace that version with a more recent one, but do it at your own risk!
I have to verify for x264...


- There are some movies, where Left and Right View seem to be swapped.
The problem is already on the BluRay itself!!!
...but can this be handled / fixed by BD3D2MK3D somehow?
(Using "FRIMDecode" and the commandline option "-swaplr"
I could manually (and laboriously) create a working SBS video stream)
Well, if the blu-ray can't display the views in the correct order, then BD3D2MK3D cannot do it either. It trust the flag in the playlist.
However, if you need to swap the views manually, it's easy: open the _ENCODE_3D_MOVIE.avs file in a text editor, and locate these lines:
left = SelectEven(interleaved)
right = SelectOdd(interleaved)
And just swap the "left" and "right" words:
right = SelectEven(interleaved)
left = SelectOdd(interleaved)
That will work regardless of the MVC decoder used.
I can't do much more. Adding an option in the GUI to control the inversion of the views will be more confusing than useful.

Thanks for your bug report.

[bottom]

Hi

thanks for the fast reply!

1) subtitle resize filter:
Actually I don't care which filter is used as long as it's the one that the developer suggests. I just noticed that „Mitchell“ is printed out several times into BD3D2MK3D.log while „lanczos“ never shows up. Still the results look really good!

2) Creation of idx AND sup fails:
Don't know the best way yet how to supply you with my screenshot/log-files, but I think the behaviour can be reproduced quite easily:
On the 2nd tab I additionally always check/select the “forced” streams. The problem I described happens exactly for those streams for which no forced subtitles exist (which seems to be the case quite often).

So in my example at the end of demuxing there's the message:
* No forced captions in "00037.track_4608.Deu_forced.2D.idx". Skipped.

And when trying to mux (using '_MUX_3D.cmd') there's the message:
Warning: '00037.track_4608.Deu.3D.sub': A track with the ID 0 was requested but not found in the file. The corresponding option will be ignored.
Warning: '00037.track_4608.Deu.2D.sub': A track with the ID 0 was requested but not found in the file. The corresponding option will be ignored.

The problems are:

a) There's no file name “00037.track_4608.Deu.3D.sub”
According to the “_MUX_3D_OPTIONS” this should be a “0:German 3D (BD SUP)” track!?
In my understanding the entry should be “00037.track_4608.Deu.3D.sup”. This file exists/was created but is never referenced from anywhere inside the batch file.
(Actually I edited the options-file according by changing “sub” to “sup” and the result looked good)

b) Same is for the missing file “00037.track_4608.Deu.2D.sub”
“_MUX_3D_OPTIONS” states it as “0:German 2D (BD SUP)”
Here the file available is “00037.track_4608.Deu.sup”.
Renaming “Deu.2D.sub” to “Deu.sup” in the options-file seemed to do the trick.

3) updated tools:
Nice to hear, thanks!
I can confirm that x264 r2491 (x64) worked fine for me, but I haven't checked the latest release r2525 yet.

4) swap left/right view:
This is of course no problem/bug of the software!
And the solution you provided is perfect

Thanks!


bottom

[r0lZ]

OK, thanks for the explanation about the subtitle problem. I think I'll be able to fix the bug easily now.

Of course, as you have probably guessed, the warning * No forced captions in "00037.track_4608.Deu_forced.2D.idx". Skipped. is normal in most cases. The problem is that BD3D2MK3D can't know if there are forced subtitles in a particular stream without demuxing it first. Since demuxing a stream is very time consuming, I prefer to leave the option to extract the forced subs anyway, and issue the warning when that option has been ticked and the stream has been demuxed and analysed and it appears that there are no forced subtitles in the stream. When it's the case, the forced subtitles are simply skipped, and of course not included in the MUX file.

Anyway, that should not produce the bug you have described. Apparently, the bug is caused by a wrong file extension, and that should be easy to fix. I'll do it right now...


Where do you download your versions of x264? There are many builds/mods available, and I must admit that I don't know what build is the better one for BD3D2MK3D. Usually, I get the Komisar version (http://komisar.gin.by/), but I don't know if it is updated regularly and it it is the best one. Plus, I find the site very confusing. Do you have another suggestion?

[bottom]

Thanks (again)!

i'm no expert!
I just check for updates here:
http://www.videohelp.com/tools/x264-Encoder

using the links from there I usually download (the non-10bit) binaries from here:
http://download.videolan.org/x264/binaries/

but videohelp also links to the page you mentioned... and yes, it's kind of confusing!
the "clear" builds on the upper left should be fine
but i have no idea if any of the patches (lower right)
that are built into the "kMod" versions could be useful (or 'dangerous') for BD3D2MK3D ...

bottom

[r0lZ]

OK, thanks.

I've just fixed the bug of the wrong .sup filename extension. It was caused by a stupid typo, and indeed, it happens only when "both" (VobSub + BD SUP) is selected in tab 2. Thanks again for submitting that important bug.

I will now finalize the new version and I'll release it as soon as possible, probably still today...

[r0lZ]

OK, I've finished the new version. BTW, the latest Komisar build of x264 is dated from yesterday! It cannot be more up to date.
I haven't tested the new version of BD3D2MK3D much, and especially the new x264, but I have fixed all problems reported by bottom above. (Funny, "bottom above" sounds strange) ;)
Thanks again.

[r0lZ]

# v0.56 (December 22, 2014)
# - Added tab 4: Cover Art to define the images to mux and use as cover art and thumbnails. (To view them under Windows, install Media Preview or Icaros.)
# - Added Tool -> Add Current Cover Art to MKV File to add the cover art currently defined in tab 4 to any existing MKV file.
# - Added Settings -> Output File Name -> Top & Bottom String to use TAB or TB instead of T&B in the file name.
# - Added Settings -> Output File Name -> 3D Format Extension to add automatically the -lrq, -abq, -lr or -ab extension to the filename so that Bino, PotPlayer, KMPlayer... can recognize the 3D format automatically.
# - Added Tools -> Remove subtitles present in another stream (to remove forced subs in a forced-only stream).
# - Added Settings -> 3D Subtitles Resize Filter -> For Method Using ImageMagick (With 3D-Planes) to define the filter to use during the main process. (Default: Mitchell)
# - Bug fix: Wrong .SUB instead of .SUP extension in _MUX_*D_OPTIONS.txt files when "both" (IDX/SUB and BD SUP) is selected in tab 2 (Thanks bottom!)
# - Updated x264 to the latest version (v0.144.2525)
# - Updated MkvMerge to the latest version (v7.0.4 'Circles')
# - Added MkvPropEdit (v7.0.4 'Circles') in the Tools folder, necessary for the new Add Current Cover Art to MKV File tool.

As you can see, it's not only a bug fix release. I have also added a tab to define the cover art if you wish to include a preview image and/or thumbnail for your MKV file, as well as a tool to add a new cover art to any existing MKV/MK3D or MKA file. Note that the MKV/MKA formats are not recognised automatically by Windows, so if you want to see the cover art or thumbnails in the Windows Explorer, you have to install BabelSoft's Media Preview (http://babelsoft.net/products.htm) or Shark007's Icaros (http://shark007.net/tools.html). Both are free. I prefer Media Preview, because Icaros requires some additional codecs to work with MKV files, but Icaros seems to be somewhat more powerful.


There is also a tool to remove all subtitles of a 2D or 3D XML/PNG subtitle stream that are present in another XML/PNG stream. That tool is similar to the existing "Extract unforced subtitles from XML/PNG" tool, but it works when the forced subtitles are authored in a specific stream. It is useful if you want to hardcode the 3D forced subtitles on the video AND you want to include the normal subtitles as a stream that can be turned on or off AND there are two subtitle streams in the original BD: one with all subtitles and another one with the forced subtitles only. With the new tool, you can remove the forced subtitles from the complete stream, and include the resulting subtitle stream in the final MKV instead of the original one. Without that tool, the forced subtitles were displayed twice: once because they are hardcoded on the video, and once because they are present in the subtitle stream.

Please note that the forced subtitles are NOT removed automatically during the main process when the forced subtitles are hardcoded on the video. If you want to remove them, you have to use the new tool and convert the resulting XML/PNG stream to 2D or 3D SUP or SUB, and either overwrite the original SUP or SUB file with the new one, or edit the _MUX_3D_OPTIONS.txt file to change the file name of the subtitle stream.


Another useful change is the possibility to include a new extension to the file name, that is used by some 3D players to recognize automatically the 3D format of the file. For example, PotPlayer, Bino and KMPlayer are unable to recognise the 3D format with the existing MKV Stereoscopy tag or with the x264 frame-packing flag and they ignore completely the .MK3D extension, but they can enable the right 3D mode automatically if you add the special string "-lrq" (for Half-SBS) or "-abq" (for Half-T&B) or -lr and -ab (for Full-SBS or Full-T&B) just before the .mkv file extension, like in "Movie Title-lrq.mkv". The new BD3D2MK3D adds now that extension automatically, but you can remove it if you wish with the new "Settings -> Output Filename -> 3D Format Extension" option.

Currently, I have implemented that option for PotPlayer, KMPlayer and Bino only. If you know other extensions that work for other software or hardware players, please let me know. I'll add them too. For example, I have read that some models of Samsung 3D TVs can use similar extensions, but my TV can't, and I haven't found the doc about that possibility. So, if you have such a TV, please let me know what its doc says about the automatic recognition of the 3D formats. Thanks in advance!


Download latest version: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)
Enjoy!

[mini-moose]

the latest Komisar build of x264 is dated from yesterday! It cannot be more up to date.
I haven't tested the new version of BD3D2MK3D much, and especially the new x264

komisar builds are updated regularly. Usuaully within 24h after a new binary has been compiled (with latest changes) by VLC.

the new revisions usually contain what seem to me like minor improvements/fixes mostly, I can't really understand most of the stuff mentioned in the changelogs:). The latest rev has a new/additional aq mode though.

At any rate they should work just as well as the previous version, unless they have some bug that would usually result in a fixed revision soon after.

[r0lZ]

Thanks for the precision. Do you know what is that new aq mode? Should I implement it? Where can I find a description of how it works, its usage and its parameters?

[Sharc]

....... Do you know what is that new aq mode? Should I implement it? Where can I find a description of how it works, its usage and its parameters?
Little info perhaps here (http://forum.doom9.org/showpost.php?p=1703357&postcount=2044) .
I understand that it refers to aq mode 3 i.e. "auto-variance AQ with bias to dark scenes" which has so far been experimental only. I didn't try this mode yet.

[mini-moose]

I understand that it refers to aq mode 3 i.e. "auto-variance AQ with bias to dark scenes" which has so far been experimental only.

Yes, that's it. I guess it might be recommended for darker movies or at least for people who split a movie encode into lots of smaller segments with each having it's own settings. I didn't try it yet either.

x264 help doesn't give a lot more info:

--aq-mode <integer> AQ method [1]
- 0: Disabled
- 1: Variance AQ (complexity mask)
- 2: Auto-variance AQ
- 3: Auto-variance AQ with bias to dark scenes

[r0lZ]

OK, thanks. It seems to be a too complex option to be put in the GUI of BD3D2MK3D. Knowledgeable persons can use it anyway if they want so by typing it in the "Additional options" field.

[well076]

Hi.
I pushed Do it! button and program started demux process. After demuxing then the program convert subtitles I have some errors. (win7x64,last java x32 and avisynth installed) I choose all subtitle types and formats (with bdsup2sup.jar in settings) but always getting these errors. If I ignore this errors program start encoding and then muxing. Muxed mkv (movie Avatar custom blu-ray 3d) look great but I don’t have subtitles. Please help. Thanks.
Screenshots and logs are in archive and download here (https://yadi.sk/d/K04sYDfgdmuVm).
p.s. What x264 encoder options I have choose for the best (like remux) quality of the movie (I played with CRF 15-23 mode,medium,none. With CRF 15 I have big file size, next time try 17-18)?

[r0lZ]

Hi, and welcome to the Doom9 forums.

It seems that the subtitle streams of your BD contain errors. I can't tell exactly what's wrong, because the error messages are coming from BDSup2Sub.jar, and not from BD3D2MK3D itself, but if I understand correctly, BDSup2Sub hangs because there is (at least) one subtitle that is referenced but missing in the original SUP file. I have never seen that kind of error, but I can have a look if you send me the two original SUP files. You can also contact the author of BDSup2Sub.jar if you wish. He should understand the error messages better than me. Anyway, something is wrong with your BD. Are you sure it has been correctly ripped to ISO and that it doesn't contain read-errors? (BTW, have you already converted successfully other BDs with subtitles? If you have the same problem with all BDs, that could mean that BdSup2Sub or Java are badly installed.)

I have also seen in your screenshot that you wonder what is the usage of the "Hardcode Subtitle on Video" option in the last tab. If you select a subtitle stream in that field, it will be "hardcoded on the video". That means that the subtitle stream will not be muxed with the video and audio streams, but "burnt" physically "in" the video image when the 3D-T&B video stream will be encoded by x264. That has advantages and drawbacks. The advantage is that you can be sure that the 3D subtitles will be displayed exactly where they should, at the correct position and with the correct depth relatively to the surface of the screen. Most players (especially hardware players) do not support the 3D subtitles streams at all, or they move or resize them, and the depth effect is either lost or wrong. For these players, the only way to have correct 3D subtitles is to hardcode them. The drawback of the hardcode method is that you cannot turn the subtitles on or off. They are definitively in the video stream, and cannot be modified. Therefore, I suggest to use that function for movies you want to watch anyway in their original languages with Russian 3D subtitles. For the other movies, it might also be a good idea to hardcode the forced subtitles only, so that you can watch the movie with the Russian audio and see the translation of the words spoken or written in other languages with the correct 3D effect. (You can do that, for example, with the forced subtitles of Avatar, containing the translations of the sentences spoken in the Navi language.)


I have no definitive answer for your question about the CRF value. There is no "best quality", except perhaps CRF 0, because with CRF 0, your encode will be lossless, but of course, the file size will be extremely big. CRF 15 is indeed a very low value. Some peoples encode with low values such as CRF 17, but IMO that produces still too big files. The default (CRF 23) is IMO a good compromise between quality and file size. Usually, that produces files between 3 and 10 GB, depending of the duration and complexity of the movie. I prefer to use a lower value (around 20) for movie where the quality of the image is very important, but CRF 23 is OK for most movies. I have read somewhere that the file size is multiplied by approx 2 when you lower the CRF value by 3. I have never tried to verify if it's correct, but if it's true, that means that the video stream computed at CRF 20 should be approx twice as big as the stream computed with the default value 23. It's why I think that using values under 20 is somewhat exaggerated. Similarly, using CRF values greater than 26 can degrade the video quality too much. IMO, values between 19 and 26 should be used most of the time, but of course, it's my opinion only.

Note also that you can reduce the file size without changing the CRF value if you select a slower preset. Presets veryslow and placebo are too slow for me, but I like the preset Slower. Note however that using a pseset slower than the default "medium" changes the level automatically. Since most hardware players do not support levels 5.0 or higher, you may need to force level 4.1 (or 4.2) if you use a slow preset.

You can also compress better the "classic cartoon" movies, with large areas of flat colors (not CGI animation!) if you select the Animation tune. But selecting the Film tune has the opposite effect. It makes the image sharper, but that increases the file size.

Personally, I use almost always preset slower, tune none and level 4.1. The CRF depends of the movie, but it is usually between 20 and 23.

[Nico8583]

@well076 : Personally I allways use CRF 18, preset Slower, level 4.1 and tune film, even for animation. File size is important but I prefer to keep better quality than size, so I think CRF 18 is the good compromise if you want to keep your movie as collection ;)

[well076]

Hi, and welcome to the Doom9 forums.
It seems that the subtitle...

Big thanks for your detailed response and bd3d2mk3d tool. I dont converted other BDs but I will try.

@well076 : Personally I allways use CRF 18, preset Slower, level 4.1 and tune film, even for animation. File size is important but I prefer to keep better quality than size, so I think CRF 18 is the good compromise if you want to keep your movie as collection ;)

Thanks. Next time i`ll try with your preset.

[frank]

BD3D2MK3D v0.56
# - Added Settings -> Output File Name -> Top & Bottom String to use TAB or TB instead of T&B in the file name.
# - Added Settings -> Output File Name -> 3D Format Extension to add automatically the -lrq, -abq, -lr or -ab :thanks: Very useful!!!

But I think 3D-abq or 3D-lrq is sufficient in the file name. No need for SBS and TAB when these extensions are used.

Can you remove the time stamps from chapter names? It is ugly and very annoying because most players show the time stamps in addition. I suggest 2 digits as chapter names like 01, 02, 03,... Then we can easily edit and expand the chapter names, if necessary.

And... the extension .ogm is the extension of .ogg media files not of simple chapter text files. OGM is a container format that can store video, audio and subtitle streams. Not common for editors, better would be .txt. The freeware tool Chaptergrabber only recognizes .txt. This is a very important tool for chapter grabbing and converting (ANSI <-> UTF8, 25 <->23.976, timeshift etc).
mkvToolnix uses .txt properly for simple chapter text files.

Now I only use PotPlayer because it has the lowest cpu load and can show scene pictures at chapter marks.

[r0lZ]

I agree that -abq and T&B are redundant, but IMO T&B (or TB) is more understandable than -abq. BTW, IMO, 1080p is somewhat useless too, since normally all 3D movies are encoded in 1080p. IMO, the resolution should be added only when it is NOT 1080p.

Anyway, I plan to implement a new method to build automatically the file name with anything that can be useful, based on a template provided by the user. Something like "%title (%director, %date) 3D-%stereoscopy 1080p (%author)%binoext.mkv" by default to generate a file name similar to the current one. It will be easy to change the output format if you wish. I'll try to do it soon...

I may add an option to use "NN - time" or only "NN" for the chapter names. My hardware players do not add the times and I like to have it automatically added in the chapter names.

I have already noticed the discrepancy of the .ogm extension. I have used it originally because MkvExtractGUI2 uses that extension when it exports a chapter file, but I know now that it's not the correct extension. I will replace it with .txt. Thanks for the remainder!

[r0lZ]

OK, finally, here is the new version. I have totally rewritten from scratch the part that opens the 3DBD and parses the MPLS files to display the available streams. Previously, that part was made with tsMuxeR, but it was necessary to launch it for all playlists (2D and 3D) of the BD. That was very slow, and there are a lot of bugs in the streams reported by tsMuxeR, so eac3to was used to verify the tsMuxeR output, and I had to write several workarounds for several bugs (like, for example, the bug of the wrong 3D-planes assignments to the subtitle streams). Now, I use my own MPLS parser. It is much much more rapid, and hopefully it has less bugs. The user should not notice major differences, except that the BD is now opened almost instantly. Also, previously, tsMuxeR displayed all streams present in the M2TS (or SSIF) file(s), regardless of the streams referenced in the MPLS file. (That was at the origin of the 3D-planes bug, and after having implemented the workaround, the additional streams were labelled "phantom track" in the BD3D2MK3D GUI.) Now, BD3D2MK3D displays only the streams really referenced in the playlists (without any phantom track). As a consequence, with some BDs, the same movie (with the same angle) can appear several times, with different streams. This is the most notable difference with the previous versions.

Please note that the change described above has many consequences on the internal code, because I have used a more suitable way to store the information internally than the somewhat complex tsMuxeR output. That means that I have had to modify the code in many parts of the program, to adapt it to the new structure. It is therefore possible that new bugs have been introduced, although I've spent much time in verifying everything. Of course, if you find a bug, please report it in this thread. Anyway, use this version with care.

There are also a lot of other changes, most of them minor. They include changes to the way the final file name is built (suggested by Frank above), some new options in several tools and in the settings, and minor bug fixes.


# v0.57 (February 1, 2015)
# - Huge change: BD3D2MK3D uses now its own MPLS parser instead of TsMuxeR 3D. Way faster and less bugs!
# - Opening a BD3D is now very fast.
# - Changes in the global label and the streams labels within the MKV container.
# - A lot of minor changes.
# - Better errors handling in case of damaged input files or ISO.
# - Tool -> Convert Audio File to AC3: Added an option to speed up or slow down the audio to adapt it to another frame rate.
# - Changed the extension of the subtitle files from .ogm to .txt.
# - Added Settings -> Chapter Names -> Include chapter times (enabled by default)
# - Added Settings -> Output file name -> Do not add "1080p" (disabled by default)
# - Added Settings -> Output file name -> Do not add "SBS" or "T&B" (disabled by default)
# - "3D" is now added in the output file name only if it is not present in the movie title or when Do not add "SBS" or "T&B" is not ticked
# - When a XML subtitle file is created, the file is now patched with the correct frame rate (instead of the BDSup2Sub default 25 fps)
# - Bug fix: The Add Current Cover Art to MKV File tool was unable to delete an existing cover art attachment before adding the new one
# - Updated MkvMerge and MkvPropEdit to the latest version (v7.5.0 'Glass Culture')
# - Updated Avs2yuv to the latest version (v 0.24bm3)


As usual, download the latest version here: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[r0lZ]

It's mainly a release to fix two bugs introduced in the previous version. Please download it, as these bugs are relatively important (although they have some bad effects only on some rare BDs).

# v0.58 (February 11, 2015)
# - Convert Subtitles tools: Better detection of the language from the filename when converting a BD SUP stream.
# - Workaround for a bug in some subtitle files that contain only full-width subpics, normally impossible to convert to 3D.
# - Bug introduced in v0.57: The conversion of the subtitle streams was aborted without notice if the 3D-planes were missing.
# - Bug introduced in v0.57: Some chapter times were wrong with some (rare) BDs, notably Dragon Gate 3D.
# - Added the possibility to use Pistacho's MVCSource (only available if BDtoAVCHD is installed). It works fine with Pacific Rim and Dragon Gate.
# - Updated mkvmerge, mmg and mkvpropedit to the latest version (v7.6.0 'Garden of Dreams')

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[zaphodalive]

Hi, I used to use DVDFab for encoding my 3D blurays but switched to your tool so as to get depth on the subtitles (DVDFab didn't support any subtitle depth). I prefer to burn-in subtitles as I've had numerous issues with players using external or muxed subtitle streams.

I trialed BD3D2MK3D with my Thor 2 bluray and everything worked out perfectly except that the subtitles are out of sync, trailing the video by about 1.5-2 seconds. Any thoughts on why this might have happened? It didn't happen when encoding with DVDFab, and I know it's not much information to go by but if you have any suggestions that would be great.

I'll try to encode another film with subtitles and see if the issue occurs again or if it's specific to the Thor 2 bluray.

Appreciate the effort that's gone into this tool, thanks.

[r0lZ]

Welcome to the Doom9 forums and thanks for your kind words, zaphodalive.

I have never had any subtitle sync issue, and I don't know what could be causing that problem. Have you created the MKV with BD3D2MK3D itself, or have you muxed the streams yourself? Normally, there should be no subtitle delay in the original BD, but of course, if you have used a non-zero number of seconds of black at the beginning of the video (in the last tab), that delay must be taken into account for the mux. BD3D2MK3D takes care of that automatically, but you have to add the delay yourself if you use the MkvMerge GUI.

If you still have the project files, can you send me the _ENCODE_3D_MOVIE.avs, _MUX_3D_OPTIONS.txt and the BD3D2MK3D.log files (to pgcedit dot g m a i l dot com)? I'll have a look, but I can't promise to find something wrong. Also, what version of BDSup2Sub did you use? (See in the Settings -> BDSup2Sub menu.)

Last question: I'm not really fan of the Marvell movies, and I don't know exactly what movie is Thor 2. Is it Thor, The Dark World? If it's the case, I have that BD here, and I'll try to encode it with hardcoded subtitles. What version of that BD did you have? Sold in which country? And what subtitle stream (language) have you hardcoded?

[r0lZ]

Wait! Forget my previous post. I've just verified with my BD, and indeed, some subtitle streams have a one second delay (exactly 1001 ms). I did not know that a delay was possible in the subtitle streams, and therefore there is a bug in BD3D2MK3D. I will fix it as soon as possible. It's easy to do for the muxed subtitle streams, but less easy for the hardcoded subs. I may need some time...

In the meantime, to sync the muxed subs properly, you can edit the _MUX_3D_OPTIONS.txt file and add 1001 to the "sync" value of the affected subtitle stream. Then, simply launch the _MUX_3D.cmd file to remux the final MKV file. Unfortunately, it's not as simple for the subtitles hardcoded over the video, as afaik there is no way to specify a sync offset with the SupTitle command of the avisynth script. I'll try to find a solution and will explain it here...

Thanks for your message. You have found an important bug!

[zaphodalive]

Hey

It was indeed 'Thor - The Dark World', but I have also tested with 'Teenage Mutant Ninja Turtles' which was also out of sync. I graphed the times in Excel and it appears that there is a linear variation through the films, e.g.:
- 1m25s - minimal variation (Thor - The Dark World)
- 12m - 0.8s variation (Teenage Mutant Ninja Turtles)
- 33m - 1.9s variation (Thor - The Dark World)
- 1h15m - 4.5s variation (Thor - The Dark World)

These times were very roughly recorded, but based on how close they appear to be to a linear variation I suspect the framerate of the subtitles is different from the framerate of the video... in fact with a rough run through the calculator is looks like it could even be the difference between 23.976fps and 24fps.

It certainly doesn't seem to be a fixed 1001ms variation in my encode as the variation gets larger through the video file. Hope that helps track the issue down.

[r0lZ]

OK, apparently, there is also a problem with drop vs non-drop frame timecodes. Damn! It's even more difficult than I thought. But thanks again.

Here is the MediaInfo output about the subtitle streams for Thor 2. As you can see, the subtitle streams have a delay of 1001 ms. But all audio streams have no delay.

General
Complete name : G:\BDMV\PLAYLIST\00800.mpls
Format : Blu-ray Playlist
File size : 1.04 KiB
Duration : 1h 52mn
Overall bit rate mode : Variable
Overall bit rate : 1 bps

[...]

Text #1
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : English
Source : 00939.m2ts

Text #2
ID : 4609 (0x1201)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : French
Source : 00939.m2ts

Text #3
ID : 4610 (0x1202)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : Spanish
Source : 00939.m2ts

Text #4
ID : 4611 (0x1203)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : Portuguese
Source : 00939.m2ts

Text #5
ID : 4612 (0x1204)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : English
Source : 00939.m2ts

Text #6
ID : 4613 (0x1205)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : French
Source : 00939.m2ts

Text #7
ID : 4614 (0x1206)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : Spanish
Source : 00939.m2ts

Text #8
ID : 4615 (0x1207)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 834ms
Delay relative to video : 1s 1ms
Language : Portuguese
Source : 00939.m2ts

[...]

So, it is strange that you have no delay in your test of Thor2 at 1m25s. If MediaInfo is right, it should be one second and a couple ms.

I'm pretty sure that the drop-frame problem doesn't occur with all BDs, as there is no sync problem with all BDs that I have tried. Perhaps the problem occurs only when hardcoding the subtitles. Anyway, I'll do tests here when I'll have some time...

[r0lZ]

OK, I think I've found the origin of the problem. In v0.57, I have added a patch to fix a bug in BDSup2Sub (both versions). When BDSup2Sub converts an original BD SUP file to XML/PNG, it writes <Format VideoFormat="1080p" FrameRate="25" DropFrame="False"/> in the XML file. The frame rate is obviously wrong, and therefore I have added a function in BD3D2MK3D to fix it:

# v0.57 (February 1, 2015)
[...]
# - When a XML subtitle file is created, the file is now patched with the correct frame rate (instead of the BDSup2Sub default 25 fps)
[...]

After the fix, the XML contains <Format VideoFormat="1080p" FrameRate="23.976" DropFrame="False"/>. It's better. But obviously, it was not a good idea to fix that bug, as the fix introduces a new bug.

In BD3D2MK3D, to convert the subtitles to 3D, the original SUP is first converted to XML/PNG and the frame rate is fixed. Then, the PNG files are converted to 3D, and the XML file is modified (with the new positions of the stereo subtitles) and copied with the new PNG files. Then that copy (containing the right frame rate 23.976) is converted again to BD SUP and/or VobSub format. For whatever reason, during that conversion, the time codes are modified, and they give the wrong timings you have noticed. Curiously, with the original wrong time codes of 25fps, the conversion works well. So, it seems that BDSup2Sub REQUIRES a wrong frame rate in the XML file to work properly!

I have also tried to change the DropFrame="False" to DropFrame="True", but that has absolutely no effect when converting the XML to another format. It seems that BDSup2Sub ignores completely that option.

Strangely, converting the XML to another XML works perfectly well. Probably because the time codes are simply copied from the original file.

In fact, there is a way to fix the conversion bug while keeping the real frame rate of 23.976fps in the XML. When converting the XML, it is sufficient to add "--convert-fps 24p 24" in the command line of the java version of BDSup2Sub, or "--fps-target 24" for BDSup2Sub++. Note that the bug happens also if you use the correct target fps of 23.976 (or 24p, an alias for 23.976). It's really strange. I don't understand at all the way BDSup2Sub handles the frame rates and time codes. But I understand that it is better to leave its output XML file unchanged, as otherwise strange things happen. I have therefore removed the fix added in v0.57. I will release a new version tomorrow, but I want to test it before.

The fact that the bug has been added in a very recent version explains why I have never noticed it. Note also that the 2D subtitles are correct (because they are never converted to XML/PNG).

Thanks again for the bug report!

[zaphodalive]

Looks like those sub streams with the 1001ms delay belong to 00939 which precedes 00800 in the 00800.mpls. I believe 00939 is an audio test that says "Left rear, left surround" - looking at MediaInfo the sub streams from 'Text #9' onwards belong to 00800 and are 1h52m in duration with no delay is listed.

The 01800.mpls excludes the audio test and only encodes 00800, and this is what I encoded on my last attempt. I think I'll do a quick encode of both the 00800 and 01800 mpls's just to check if the 1001ms delay in the 00939 sub stream actually affects the timing of the subs in the subsequent (00800) stream, or if it can be safely ignored.

[r0lZ]

I was wrong when I posted about the 1001ms delay. It is reported by MediaInfo (for 00800.mpls as you can see in the 2nd line of the MediaInfo log posted above) but the delay is not necessary. I guess that tsMuxeR adapts the time codes automatically when it demuxes the track. tsMuxeR does not report any delay, and it is correct. BD3D2MK3D "sees" only the streams referenced in the MPLS (unlike tsMuxeR and MediaInfo) and therefore it can process only the first 8 subtitle streams.

The problem was not related to an initial delay, but as you have correctly explained, it is a progressive de-synchronisation due to the wrong frame rate in the XML file.

I have not tried to convert 01800.mpls, because it has been removed from the list of the useful 3D playlists by BD3D2MK3D. BD3D2MK3D uses a complex method to remove all useless MPLSs, that are either not 3D, or dupes of another MPLS, or parts of another MPLS, or shorter than 1 minute, or referencing the same M2TS parts than another MPLS but with less audio or subtitle tracks or with missing 3D-plane information. You can however use the "Show all 3D playlists" option if you wish, but normally it's never necessary. In this case, I'm sure that 00800.mpls is the correct MPLS to process. (00800.mpls is the main movie in many 3DBDs, although it's not always the case.)

[zaphodalive]

In case there was any doubt I have confirmed the same variations at the same points in both the 00800.mpls and 01800.mpls encodes - i.e. the audio test in 00939 at the start of the playlist has no effect on the sub synchronisation. Figured I may as well still check it in case the Thor 2 bluray happened to be abnormal and the main playlist was adding a secondary issue.

Just found this from 0xdeadbeef in relation to BDSup2Sub:
Regarding the SRC/TRG frame rates: AFAIK the SUP file doesn't contain any info about the frame rate. Therefore, if you want to convert the frame rate, you have to select the source and target frame rates manually. The 23.976 as source and 25fps as target is just the default setting as this is my typical scenario (PAL speedup from 24p). Indeed the source and target frame rates are only used to calculate a speedup/slowdown factor that's used to manipulate the time stamps.

So it seems that the FrameRate="25" in the XML is needed to match the default target framerate of 25, keeping the source and target framerate ratio 1:1. If you adjust one but not the other then the sub time stamps are contracted/elongated. Not sure if I've quite got that right but I'm sure you understand it better - hopefully it helps clear up what's happening.

I have a small request for BD3D2MK3D; I have a 4K TV as my monitor and so I do all my encodes as full-SBS and would prefer to keep a 32:9 aspect ratio, but the MKV container settings (in _MUX_3D_OPTIONS.txt) specify the aspect ratio as 16:9. I can obviously manually adjust the txt (which is what I have been doing) but it would be good if there was an option to keep it as 32:9 (or presumably 16:18 for top & bottom). I don't use the TV's native 3D processing (I use Stereoscopic Player to interleave the output) so have no requirement for it to display half-SBS, and full-SBS helps me assess encode quality.

Thanks again for your help - much appreciated.

[r0lZ]

Thanks fore the quote by 0xdeadbeef. I have figured out myself that the --convert-fps option is made to adjust the frame rate, but that doesn't work correctly at all. The frame rate is included in the XML and IDX files, and therefore I suppose it is read and used as the default input file rate. So, for example, if I use a XML with FrameRate="23.976 and I specify --convert-fps 24p 24p, the output file should have the same time codes than the input file. But it's NOT the case! Note also that the --convert-fps option gives DIFFERENT RESULTS depending of the output stream format!

I suppose too that the input frame rate must be specified when converting a BD SUP file, because BDSup2Sub has no frame rate information in the file. But regardless of the input frame rate specified on the command line, it is ALWAYS mandatory to use 24 (and not 23.976!) as the target frame rate to force BDSup2Sub to not change the timings is the input XML is tagged with 23.976! Omitting completely the --convert-fps option doesn't work either. So, the XML must be tagged with a wrong frame rate (25fps) AND the --convert-fps must specify the wrong 24 fps as the output frame rate to work properly! It's a serious mess. To make things even more confusing, there is also a --fps-target option that you can specify, but it seems to have no effect. And BDSup2Sup++ doesn't have the --convert-fps option, but it has the --fps-target and the --fps-source options, that can be combined to work similarly (with the same bugs) than the --convert-fps of the java version. Anyway, I have decided to leave BDSup2Sub do its conversion without specifying any parameter, and without changing the default 25fps in the XML or IDX files. That works, but it's really strange.

There is also a problem with the standalone subtitle conversion tools (in the Tools menu of BD3D2MK3D), as you can specify the output frame rate if you want to force a conversion. But you have to select wrong target fps to obtain the right conversion! Difficult to explain! But I'll try to solve the problem of the conversion tools later. Currently, I want to release a version that works well when doing the main job.

For the aspect ratio, what you want is strange. The AR of a 3D movie MUST be 16:9, regardless of its (full or half) resolution, because the final movie is always displayed in 16:9. Specifying other ARs leads to distorted images on all devices I have tested so far. In your case, Stereoscopic Player should keep the original 16:9 AR after its conversion to interleaved frames, because it knows that it's a 16:9 movie, and therefore that the AR is the AR of the final result. If it doesn't do that correctly, it's a bug in Stereoscopic Player, and not in BD3D2MK3D. However, I can add an hidden option in the config file if you wish. You will have to edit it manually, because I don't like much to add potentially confusing options in the GUI. And also because I want to release the fix rapidly and I haven't much time to modify the GUI.

[zaphodalive]

The aspect ratio with Stereoscopic Player doesn't need to be 16:9, it is fully capable of dealing with a 3840x1080 video with a 1:1 pixel ratio and convert it to a 16:9 interleaved output because each of the left and right images is still stored as 16:9 (for a total 32:9 in SBS) - so yes, the output has to be 16:9 as you say but the input doesn't. I'm not sure in what order video processing occurs, so I'm concerned that a 3840x1080 video with a 1:2 pixel ratio - i.e. displaying as 1920x1080 (16:9) - would be rendered with a Directshow filter and then split into two 960x1080 images (for left and right eye) and then scaled up to two 1920x1080 images and interleaved for the output. Essentially this would mean that half of the horizontal data is lost in the conversion process, just as if I'd encoded it in half-SBS to begin with. Of course this may be completely wrong and the full 3840x1080 image may be used, but I don't know if that's the case.

To avoid that issue I prefer to encode in full 3840x1080 with the full 32:9 aspect ratio, then I know that whatever process sequence Stereoscopic Player uses to get to the interleaved output should use the full image quality. In addition it allows me to open up the file easily in MPC and check the quality of the encode.

Reading over what I just wrote I realise it's a bit hard to follow so I'm not sure if you'll get exactly what I'm saying. Either way it's no big deal, as I mentioned I can edit the mux options txt manually to remove the container aspect ratio as I've been doing so far, so you don't need to add anything extra to the config file.

[r0lZ]

I have added the new config option anyway. But IMO it is useless as the aspect ratio stored in the MKV header should normally be the output aspect ratio (16:9) regardless of the full or half encoding. Anyway, if you prefer to use the full source AR, it will be possible to insert it in the mux options file automatically.

I did just a test with the new version of BD3D2MK3D, but there is still a desync problem with the 3D subtitles. I have to work again on that problem, and I'll release the fix as soon as possible...

[r0lZ]

OK, here is the fix for the sync problem of the 3D subtitles.

I have also fixed another (less important) bug related to the subtitles. The forced flag was sometimes set on all subtitle files in the MKV file without reason.

I have also added the hidden option to set the aspect ratio to 32:9 or 16:18 in Full-SBS or Full-T&B modes respectively. You have to open the new version, save the settings (with Settings -> Save Settings Now), then quit BD3D2MK3D, edit the BD3D2MK3D.cfg file (look for the option "full_ar_in_full_mode" near the end and change it to true) and restart BD3D2MK3D.


# v0.59 (February 18, 2015)
# - Bug fix: Removed the fix (introduced in v0.57) for the wrong frame rate written by BDSup2Sub in the XML files because it introduces major sync problems with the 3D subtitles.
# - Bug fix: Some subtitle tracks were erroneously tagged as forced when the Forced option of at least one stream has been ticked in tab 2.
# - Added the hidden option "full_ar_in_full_mode" in BD3D2MK3D.cfg to specify the 32:9 or 16:18 aspect ratios respectively for full-SBS or full-T&B in the _MUX_3D_OPTIONS.txt file

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[zaphodalive]

Thank you very much for that, I'll be giving it a whirl later today.

I'm sure most 3D devices aren't capable of using wider images than they are able to output, but that's not a limitation in Stereoscopic Player (and probably other software 3D media players). You're absolutely right that the output needs to be 16:9, but the video file we're using should be considered as an input, e.g.:
Input video -> 3D processing -> output video (16:9)

So SS player can do:
Input MKV (32:9 - full-SBS@ 16:9 x2) -> 3D processing -> output video (16:9 - interleaved)

In that way it uses the full 1920x1080x2 video frame to create the 3D output, so I'm assured the maximum quality on my 4k TV. It's possible that the full 1920x1080x2 video frame is used in the 3D processing even if the container is set to a lower aspect ratio, but I don't know that, so this is a way for me to be sure without doing laborious testing.

Hopefully this clears up why it's useful to me, but regardless I really appreciate the effort and the sub fix, tyvm.

[r0lZ]

OK. Anyway, now, you have the new option in the config file. I may add it in the GUI too, for a future version, but I'm still not sure.

Please confirm that the subtitle sync problem is fixed. I did some tests and for me the new version works fine, but it is always difficult to do several long demuxing and encoding operations just to test a fix with several different movies, so my tests are always somewhat limited.

[zaphodalive]

I did another encode of Thor 2 overnight and the subs are perfectly in sync at the start, first third, and second third points in the movie so it looks like it's all fixed, nice work. I'll be re-encoding some other films with subs over the next week or two, I doubt there will be any sync issue snow but I'll let you know if there is - thanks.

[r0lZ]

Thanks for the confirmation, and again for the original bug report!

[frank]

3D-planes.log shows 2 planes with fixed depths 2 and 4.
BD3D2MK3D uses 3D-Plane-00.3dp with depth 4.

I need to use the Tools to move subs into the picture using Convert Subtitles to 3D...

Issues:
-Analyse currently selected 3D-planes
shows other depth values than the xml. (analyse 2 - xml 4)
- Additional depth is ignored.
- Selection of BD SUP does not persist.

Tested with Flying Swords...

[r0lZ]

Damn! I don't have the same 3D-pland than yours. I have probably another edition. It is therefore difficult to test the problems here.
With my version, only one 3D-plane is not empty: plane 0. It has a fixed depth of 20. (Confirmed with an hex editor.)

Analyse:

I have no idea why you have obtained different analysis results. I can't verify here, because I have only a single 3D-Plane. But are you sure that you have selected the right plane? Can you send me the 3D-planes and the logs? (You know my email address already.)

Note that the 3D-planes.log file is created by MVCPlanes.exe (with the subtitles assignments added at the end of the log by BD3D2MK3D itself). MVCPlanes is used to extract the planes from the MVC stream, and it generates the log on the fly. In the other hand, the Analyse Currently Selected 3D-Plane button does a new analysis of the 3D-Plane data, and doesn't use the original log to retrieve the values. With my version, both methods give the same result: fixed depth of 20.

Additional depth:

I did a new conversion with the tool, using the 3D-plane 0 (depth 20) and an additional depth of 100. (It's a very high additional depth, but it's easier to verify the effect). The result is correct, and the additional depth is taken into account. However, there is a little discrepancy in the way the two depths are taken into account. The depth from the 3D-plane is added in both views. In other words, if the depth is 20, that means that the left subtitle is shifted by 20 pixels to the right, and the right subtitles by 20 pixels to the left. (In previous versions of BD3D2MK3D, there was a bug here and the depth was divided by 2.) But the additional depth is more precise and is spread across the two views. That means that my additional depth of 100 pixels was divided by two: the left subtitle is shifted to the right by 50 pixels, and the right one to the left also by 50. Therefore, an additional depth of 100 is equivalent to a depth of 50 in the 3D-plane. But as far as I know, it is correctly added to the depth from the 3D-plane to produce the final result. (Note that in SBS, the subtitles are squashed horizontally, and therefore the X positions and width of the bitamps are divided by 2. I haven't taken that into account in my explanation above.)

So, IMO, the conversion works fine. The fact that the additional depth is not treated the same way than the depths of the 3D-planes is questionable, but if you remember that it must be multiplied by 2 to obtain the same result, it works as expected.

Perhaps you have experienced a bug if you convert an XML/PNG stream? Can you confirm that your input stream is in BD SUP format?

Selection of BD SUP:

The default selection of the output format should persist during the current BD3D2MK3D session, but is is forgiven when you quit the program. The default selection in a new session depends of your setting in tab 2 of the main GUI: it should be VobSub or BD SUP depending of the "Subtitle stream format" option in that tab. But I agree that there is a little bug here. If in tab 2 you select "both", no format is selected by default in the GUI of the conversion tool. I will fix that bug immediately. Thanks for the report! [EDIT: Done.]

[r0lZ]

Sorry for replying so late. I have had a look at your files, and I can certify that there is no bug. However, I must agree that there is a big discrepancy.

As I have explained in my previous post, the depth stored in the 3D-plane must be used in the two views of the movie. For example, if the depth is 4, that means that the left view must be shifted to the right by 4 pixels (without the resize in SBS mode). And vice-versa for the right view. That means that the total offset between the 2 views is 8 pixels. (A 2D subtitle with its original X position being 500 will therefore be placed at position 504 in the left view, and at 496 in the right view. 504 - 496 = 8)

Unfortunately, when I have learned how to use the 3D-planes, I was convinced that the value stored in the 3D-plane was the total offset. Therefore, I have written the functions that shift the planes so that the left plane is shifted to the right by the depth / 2 (therefore by 2 in my example), and vice-versa for the right view. That was wrong, as Thalyn has discovered. V0.45 fixed that bug.

When I realized that that was a bug, I have simply multiplied the value of the depth passed to the function by 2, so that it is correct again when it is divided by 2. It's also that value multiplied by 2 that is stored in the temp 2D XML file. That has the advantage that it is possible to use an odd value for the total offset. For example, if you specify 5 as the additional depth, the left subtitle will be shifted to the right by 2 pixels, and the right subtitle will be shifted to the left by 3 pixels, giving the exact total offset of 5 pixels. (Same thing if you edit manually a <Depth> value in the XML.) It's why you see also doubled values in the log of the conversion functions. I agree that it's not at all intuitive, but I did that that way for historical reasons, and currently I like to keep it as it is for the possibility to specify odd depth values. The result IS correct, although the depth really used is twice the one stored in the 3D-planes.

I may change that later, but honestly, I think that it works correctly now, and I don't want to risk to introduce new bugs. However, I will add a warning in the 3D-planes logs to explain that the 3D-planes contain actually the full offset divided by 2, and that BD3D2MK3D uses internally the full offset, not divided by 2.