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

[Tenker]

Originally Posted by r0lZ

So, it seems that FRIMSource is definitively better than DGMVCDecode. Should I set FRIM as the default MVC decoder in BD3D2MK3D?

From my present experience, I say YES

[frank]

So, it seems that FRIMSource is definitively better than DGMVCDecode. Should I set FRIM as the default MVC decoder in BD3D2MK3D?

Better? Only very few BD's have this issue (I only know 2). FRIMSource is compiled with latest Intel Media SDK 2017 but doesn't start reliably on that BD's in HW mode. The culprit is Intel. User can set SW mode.
In the past I preferred DGMVCSource because it was a little bit faster (on my old machine). Now they are probably equally fast.

[von Suppé]

Originally Posted by r0lZ

See this post and the following in the BDSup2Sub thread for more info.

Will do. I'm gonna read that whole thread btw.

[r0lZ]

This version is mainly an update of the third-party tools. It has also some little improvements and bug fixes.

Unfortunately, I am not able to understand what's wrong with some versions of the Wonder Woman 3DBD, so there is no fix for that problem. Anyway, I don't think there is something wrong in BD3D2MK3D itself. The problem comes probably from the BD itself, or from x264.

v1.2 (October 7, 2017)
- Updated FRIMSource to the latest version (v1.27). It should work correctly. Let me know if you experience crashes.
- FRIMSource is now the default MVC decoder.
- Removed the LoadHelper() trick and added the full paths in the LoadPlugin() commands for compatibility with some Avisynth forks.
- Added tab 3 -> Web -> Search TCM for title.
- Adapted to the new distribution of x265 as a single exe file instead of the previous 3 exes (one for each color depth).
- Fix: Workaround for the wrong character encoding of the AVS and CMD scripts.
- Fix: The path to java.exe was not correctly detected in some circumstances.
- Fix: Some typos.
- Updated x265 to the latest version (v2.5+8)
- Updated the Mkvtoolnix exes to the latest version (v16.0.0)

Please note that the way x265 is distributed has changed. Previously, a different exe was available for each color depth (8, 10 or 12-bit). And, of course, it was necessary to have a different version for the two CPU architectures (32 and 64-bit). That gave a total of 6 different exe files just for x265. Now, all color depths are available with the same unified exe, and therefore only two different exes are still necessary. I have adapted BD3D2MK3D to reflect that change. So, if you update BD3D2MK3D simply by overwriting the files in the BD3B2MK3D installation folder with the content of the new 7Z archive, you can safely delete the previous versions of the x265 exes. They are not needed any more.

The distribution of x264 has not changed, and there are still 4 different exes for the 2 color depths and 2 CPU architectures. The x26*.exe files to keep in the toolset folder are therefore:

x264_8bit_x64.exe
x264_8bit_x86.exe
x264_10bit_x64.exe
x264_10bit_x86.exe
x265_x64.exe
x265_x86.exe

[frank]

You should link to x265 builds for Windows.
Latest x265 build is 2.5+25 and latest stable build is 2.5 +5.
Compiled with VS 2017 or GCC 7.2.

[r0lZ]

Thanks for the info, but I'm not sure that builds are "better" than others. Unfortunately, there is no coherent information about what release or build to use, and a site that offers good and recent builds can be outdated one or two months later (like this one, that was linked by BD3D2MK3D previously, and that is now completely outdated).
But I agree that your link seems good (although somewhat confusing for the newbie). I will try it, and if it is confirmed that it is updated regularly, it will be the "official" download site for BD3D2MK3D, and I will include the latest stable/GCC/none/multi-color-depth builds in the toolset.

Luckily, things are more straightforward for x264. Do you think I should link to the same site for x264 too, or should I keep komisar (clear builds)?

[frank]

I have the link from videohelp https://www.videohelp.com/software/x265-Encoder
and it is very up-to-date. You can read the version history.
In my case (Kaby Lake) I prefer the AVX2 VS2017 binary (C++ with ASM parts), because I have a feeling it is faster. I use x265 10 bit with my UHD encodings. On UHD BD they dropped the 3D support.

I havn't tested the x264 binaries yet from that site. In the past komisar's binaries were a good choice.

[frank]

I have repeated the BD3D2MK3D test with The Martian 3D.
Sorry, neither FRIM nor DGMVC work in hw mode with this movie.
Only endless loop that can be interrupted.

[r0lZ]

Damn! That's really strange. I have never has any problem, including with Wonder Woman and The Martian.
Of course, it is extremely difficult for me to fix a bug that I cannot reproduce and that occurs in a decoder that I have not written myself.
The only thing that I can do is to configure the MVC decoder in software mode by default. But it's a pity for the users lucky enough to have an Intel CPU supporting the hardware mode.
And I can add a red warning here. (DONE)

Thanks for the x265 link at Videohelp. Since the home of PgcEdit is already at VideoHelp, I think I will definitively adopt it. But it's only a redirection to http://msystem.waw.pl/x265/ and https://builds.x265.eu, so I don't think that it's more useful that linking directly to that sites. At least, I don't have to take care myself of the out of date sites. And, for coherence, I have decided to adopt the VideoHelp link for h264 too.

[r0lZ]

If you experience problems when decoding a 3DBD with BD3D2MK3D, such as black frames at the end of during the whole movie or infinite loops, please configure the MVC decoder to use SOFTWARE mode instead of hardware or automatic.
Select Settings -> MVC Decoder -> Hardware Acceleration -> Software (use if Auto crashes)

And please report here if you have had that kind of problems, with what movie and if using the software mode has solved the problem.

(If you are interested, that problem has been reported for the first time here.)

[fszecsei]

Hello r0IZ,

I am using this tool since 2016; fully satisfied and impressed. It is GREAT!!

Now, Norton Security reported a risk with _ENCODE_3D_LAUNCHER: “blocksleep.exe contained Heur.AdvML.B”. It seems, the heuristic algorithm has been updated in Norton recently…

I instructed my Norton Security to release blocksleep.exe from quarantine. No weird symptoms detected up to now.
However, might be this exe really dangerous?

[r0lZ]

Thanks for your kind words and welcome to the Doom9 forums, fszecsei.

__ENCODE_3D_LAUNCHER.cmd and blocksleep.exe have been added when I have received complains of some users about encoding problems. Blockssleep has been written by Slavanap and officially released here. As you can see, it is open source.

As its name suggests, blocksleep.exe is used to prevent Windows from going to sleep mode during an encoding. It is used by __ENCODE_3D_LAUNCHER.cmd to launch __ENCODE_3D.cmd. It doesn't do anything by itself. It just sets a flag telling the system to not go to sleep mode while __ENCODE_3D.cmd is running. Without that, most laptops and some desktop PCs go normally to sleep mode after some time, and of course the encoding stops. It has also been reported several times that x264 has often some trouble to continue the encoding when the laptop wakes up, and that can result in a damaged or incomplete video stream.

I don't know why Norton considers blocksleep as dangerous. Perhaps it's because it is designed to launch other exes or batch files? Anyway, it's a false positive. You can even delete it if you wish, and launch __ENCODE_3D.cmd directly, if your PC uses a power plan with sleep mode disabled, or if you accept to take the risk of a bad encoding. (Note that __ENCODE_3D_LAUNCHER changes also the priority of the _ENCODE_3D process to low, so that you can still use your PC to do other things with a reasonable speed when the encoding is in progress, but it's not absolutely necessary.)

Finally, as an evidence that blocksleep is harmless, have a look at its VirusTotal report. It has a score of 1/63, and only Cylance (an obscure antivirus) flags it as unsafe (and unsafe doesn't mean infected).

[fszecsei]

r0IZ,

Many thanks for the detailed explanation; fully understood.

[konikpolny]

Hi r0lZ,
I found some bugs/shortcomings in the "convert SRT to ASS 3D" tool:

1)
color restore after a color change should be simply {\c} rather than quoting the default color literally. \c is shorter, cleaner and more obvious. According to ASS specs override code (like \c) without any parameter is defaulting to 0 meaning it's already given the default value.
2)
substitution for "<font color=" may not always work as SRT also supports changing Font face, so 'font' doesn't always refer to a color change only. MOreover, to complicate it a bit more it can have the 2 attributes - color and fontname at the same time like:
<font face="Times New Roman" color="#a38c22">
The font name change tag for ASS is \fn followed immediately by the Font Name like {\fnTimes New Roman} and should be closed with {\fn}.
In case for having both color and font name change, the ASS override can be within one set of braces eg.: {\fnTimes New Roman\c&H228ca3&} and closed with {\fn\c} (the order of the tags is not important and may not be in the same order as for the opening override)

Do you think you can add support for the font name change?

By the way what language is SRTtoASS3D.tcl written in?


Oh, and there's another thing I wanted to bring up for some time now. BD3D2MK3D opens to the last saved state and if it was using for instance 10bit color encoding or Full SBS/T&B stereoscopy it always displays the warnings. It would be great if we could have a checkbox at the bottom of the dialogues to tick to acknowledge reading the warning and so not to display the warnings any more. Having that we could also have an option somewhere to reset the warnings settings to make them appear again.

[r0lZ]

Well, I don't use the ASS format myself. I have written the SRTtoASS3D function for a specific user, and also because it was a nice challenge to convert simple SRT files to ASS with the correct 3D depths.

OK for point 1. It is easy to implement the modification yourself (in case you are in a hurry). Just edit line 1147 of SRTtoASS3D.tcl and change it from set restorecolor "{\\c&H[SrtColorToAssCode $color]&}" to set restorecolor "{\\c}"

Indeed, it's a simpler syntax. I did not know it, as I have simply analysed a couple of ASS files to understand the syntax, but I have never studied that format.

I will try to fix the problem described in point 2, although I have never seen a SRT file with a font change (other than its color, and even that is extremely rare). I agree that the color change in a SRT may be missed if it follows a font name change, but it's so rarely the case that I don't think it's really a problem. After all, almost all SRT files have no formatting at all, and when they have some kind of formatting, it's usually limited to italics. But I will do it anyway.

I'm not sure I can easily change the font name. Not because writing the code is difficult, but because usually the font type or name is not specified at all in the original SRT, and above all because if it is specified, I cannot be sure that the same font exists in the computer, TV or player that will be used to play the final MKV. Can I simply copy the font name from the SRT and insert it in the ASS, with the risk of specifying a font that the player can't use? Perhaps the player may even crash.

Also, I don't understand why I should implement the font name change, but not the font size. Is it because the SRT format doesn't permit to change the font size? And anyway, the font size is dependent of the font, and the user should select the right size according to the "XML guide file" and the font he has selected in the GUI (as you can see when you use the Analyse the subtitle guide option). If the font (name or size) changes in the middle of the stream and if the resulting subtitle is too large, the 3D depth may not be suitable any more, because the subtitle may enter into the objects in the foreground. Don't forget that this tool converts the SRT to 3D, not simply to ASS, and that introduces some difficulties. So, to reply to your question, I'm not sure I will implement the font changes, but I will certainly fix the possible bug with the font color.

SRTtoASS3D.tcl is written in Tcl/Tk. TCL is the main programming language, and TK the ToolKit that has motivated me to use that language to code most parts of BD3D2MK3D. It's an interpreted language, somewhat slow, but TK is very powerful to build complex GUIs, and since BD3D2MK3D is essentially a GUI, IMO Tcl/Tk was a good choice.

I agree that the warnings about the color depth or the Full stereoscopy should not be displayed each time BD3D2MK3D starts, but I can't change the dialog to add the option to not show it any more, because it's a standard system dialog that cannot be modified. I will try to disable the warnings when BD3D2MK3D starts, but that will not be an option. You will still see it if you manually change these options again.

BTW, you wrote "BD3D2MK3D opens to the last saved state". That's only partially true. You can change that by disabling the "Save tabs settings on exit" option, and BD3D2MK3D will be opened each time with the settings you have saved explicitly with "Save tabs settings now". (The options available in the menus are saved immediately anyway.)

[konikpolny]

OK for point 1. It is easy to implement the modification yourself (in case you are in a hurry).

Yes, I studied the SRTtoASS3D.tcl and already changed it before I wrote that post but the font name was more complicated so I decided to ask you.

I'm not sure I can easily change the font name. Not because writing the code is difficult, but because usually the font type or name is not specified at all in the original SRT, and above all because if it is specified, I cannot be sure that the same font exists in the computer, TV or player that will be used to play the final MKV. Can I simply copy the font name from the SRT and insert it in the ASS, with the risk of specifying a font that the player can't use? Perhaps the player may even crash.

Well in my opinion if font change is allowed by SRT, and if the SRT file being converted have a font change tag, the conversion to ASS 3D should respect that. Otherwise the tool is limited and doesn't support SRT in full. The SRT to 3D ASS conversion itself should always be tested for specific use. We cannot or shouldn't try to have a foolproof tool at the expense of its functionality because it will never be foolproof. You already have a number of warnings to advise about the 'safe' settings.
So everything here is at the user's own risk.
Also, as you said the font name change is extremely rare, and the chances are if present it is probably put there in purpose, most probably, as in my case, by the very user who is doing the conversion. You cannot ignore it.
To ensure the user has more control over the formatting you could replace the existing "keep formatting" checkbox by or even better add the new checkboxes permitting for individual formatting from SRT: italics, bolds, underline, color, fontName.

You cannot be sure and to be honest it is not you who should worry if the font exists. It is the user's responsibility to make sure the conversion setting is what he/she wants. Most of the time, it is for personal use and should be tested, otherwise the 'keep formatting' box should be deselected or specific formatting removed from the originating SRT file. The fact is that if the font face change is present in the SRT file, the conversion needs to do something about it (one or the other). Currently it's doing nothing with it. If you are afraid it could crash the player you should normally remove it from the resulting ASS file (I vote for having a chance to choose). The funny thing about it is that the conversion leaves the tag untouched and my player Media Player Classic respects the original code written for SRT even if it's embedded in the ASS file and displays the font change correctly !

Also, I don't understand why I should implement the font name change, but not the font size. Is it because the SRT format doesn't permit to change the font size? And anyway, the font size is dependent of the font, and the user should select the right size according to the "XML guide file" and the font he has selected in the GUI (as you can see when you use the Analyse the subtitle guide option). If the font (name or size) changes in the middle of the stream and if the resulting subtitle is too large, the 3D depth may not be suitable any more, because the subtitle may enter into the objects in the foreground.

I don't understand why you mention the font size. If it is not supported by SRT, the conversion cannot consider it as it cannot respect illegal tags. I never used the individual position from the guide file setting as it offers me the settings I don't personally like, and I know what I like and how I want it. If you have doubts about font name or size working unreliably you could disable font name change tag formatting support for guides (only) or better warn the user, or best, as I said earlier, have a checkbox for individual formatting types.

By the way I often come across subs in which dialogs in one sub picture are placed in different X position and without the usual hyphens to denote different persons talking. The XML/PNG guides from the project don't seem to honor that X position difference. I originally thought that was what having the guides were for.

I agree that the warnings about the color depth or the Full stereoscopy should not be displayed each time BD3D2MK3D starts, but I can't change the dialog to add the option to not show it any more, because it's a standard system dialog that cannot be modified. I will try to disable the warnings when BD3D2MK3D starts, but that will not be an option. You will still see it if you manually change these options again.

That's OK, the most noticeable (and irritating) warning is the one upon the start. The others when I change a setting I don't mind so much .

[r0lZ]

Originally Posted by konikpolny

Well in my opinion if font change is allowed by SRT, and if the SRT file being converted have a font change tag, the conversion to ASS 3D should respect that.

The primary goal of SRTtoASS3D is to convert text based subtitles to 3D, not to convert SRT to ASS. However, I agree that if it's possible, the conversion should preserve the formatting (in the extremely rare cases where formatting is present in the source SRT).

Originally Posted by konikpolny

Otherwise the tool is limited and doesn't support SRT in full. The SRT to 3D ASS conversion itself should always be tested for specific use. We cannot or shouldn't try to have a foolproof tool at the expense of its functionality because it will never be foolproof. You already have a number of warnings to advise about the 'safe' settings.

Yes again, but IMO the conversion should produce the best 3D. The liability to the original SRT formatting is not as important, especially because it is almost never specified (except italics, well supported). Anyway the font type and size are usually not specified, and the only way to produce good 3D subtitles is to select an easily readable font and a font size more or less compatible with the guide.

In the font selector of the GUI, there are only 3 fonts offered by default, because they are the 3 font faces present in all incarnations of Windows, Mac and Linux, and I can probably safely assume that all players can deal with these fonts. But with that 3 fonts, I have already faced a big problem. As you can see when you use the selector, they have not at all a similar width for the same height. When the user analyse the subtitle guide, the program suggests the best font size for the current font. But if the user changes the font after the analyse, he should change the font size as well, as otherwise some subtitles may not fit any more in the empty space between the objects in the foreground. To remain compatible in most cases, it is therefore necessary to keep the same font during the whole movie, even if that means that the original formatting is abandoned.

Of course, it is possible to keep the font changes in the final ASS file, but I will have to add a big warning explaining that it's dangerous and strongly not advisable. Is it really necessary to do that, especially when we take into account that 99.99% of the SRT files do not specify any font ?

Originally Posted by konikpolny

To ensure the user has more control over the formatting you could replace the existing "keep formatting" checkbox by or even better add the new checkboxes permitting for individual formatting from SRT: italics, bolds, underline, color, fontName.

If I implement the font change, I will be forced to do it, because of course the font name change must be disabled by default.

Originally Posted by konikpolny

You cannot be sure and to be honest it is not you who should worry if the font exists.

Well, I'm not sure. I know that it is possible to embed a font in the final MKV if it must be used by an ASS stream. But that option is currently not implemented, and will probably never be. So, in the best case, when the specified font is not available, the player will use the default font specified in the header of the ASS file, or it will use its own default font, with unpredictable results. Again, I don't think it's a good idea.

Originally Posted by konikpolny

I don't understand why you mention the font size. If it is not supported by SRT, the conversion cannot consider it as it cannot respect illegal tags.

I don't know if SRT supports the font size change. IMO, it is terribly stupid to support the change in the font type, color and other formatting but not the size, probably the most important thing to control. But the SRT format is totally stupid anyway, so I guess it might be the case. I wonder simply if I have to support the font size change, and if it's the case, what is the SRT syntax for the font size.

Originally Posted by konikpolny

I never used the individual position from the guide file setting as it offers me the settings I don't personally like, and I know what I like and how I want it.

The guide file is used ONLY to position the subtitles on screen, and I strongly suggest to use it, except when the analysis tells you that all subtitles are approximately at the same Y position and centered horizontally. In that case, as long as they are at approximately the right Y position, the resulting subtitles should never enter in the foreground objects (if the font size is not to big of course).

I have added the analysis to offer to the user the possibility to produce the ASS subtitles as close as possible to the original subtitles from the BD (similar color, size and position), and at least select a font size more or less compatible with the content of the 3D movie. You are of course for forced to do the analysis, or accept its recommended values. (Personally, I use often a much darker color than the original one.) But if you don't remove the subtitle guide from the GUI, it will be used to position the subtitles at their right positions on screen, and that's extremely important when the original subtitles are carefully placed on screen to avoid entering in the foreground objects (like in Avatar, for example).

Originally Posted by konikpolny

By the way I often come across subs in which dialogs in one sub picture are placed in different X position and without the usual hyphens to denote different persons talking. The XML/PNG guides from the project don't seem to honor that X position difference. I originally thought that was what having the guides were for.

I'm not sure I understand you. Indeed, in a 3D movie, the translation of a specific phrase can be placed in a specific position so that it will not enter in a foreground object, or to show clearly that it's the translation of a sentence spoken by a specific person. SRTtoASS3D should respect that. Technically, SRTtoASS3D analyses the coordinates of the bounding box containing the original subtitle (specified in the XML file) to know where it should place the text of the ASS stream.

Of course, when there are TWO sentences displayed at different X positions AT THE SAME TIME on screen, they form a SINGLE subtitle, the box contains the two sentences, and it is impossible for SRTtoASS3D to know that the first subtitle is, say, on the top left and the second on the bottom right side of the box. In that case, the program assumes that the two output subtitles must be centered in the box, and they will appear on top of each other. You may lose the indication of who is telling what, but at least, the subtitles should be in a place where there is only a little risk to enter in a foreground object, and it's what is really important when converting a subtitle in 3D.

In other words, SRTtoASS3D is unable to analyse the actual text of the original subtitles to ensure that his translation is placed exactly at the same X position. That would require a sophisticated OCR and automatic translation of the original text, and of course, it's beyond the scope of this little conversion tool. Therefore, it can only grab the position of a specific subtitle from its bounding box and apply it at the subtitle displayed at (more or less) the same time.

Originally Posted by konikpolny

That's OK, the most noticeable (and irritating) warning is the one upon the start. The others when I change a setting I don't mind so much .

OK, I'll do that. I just hope I will not forget some warnings...

[r0lZ]

I've searched the web for the text formatting options of the SRT format. According to Wikipedia (as well as other sites like this one), ONLY the basic formatting options bold, italic, underline and color are supported. The other file format descriptions I've found on the internet either do not specify the formatting options, or specify only bold, italics and underline. Even the color change seems to be an option that is not widely supported. It is therefore NOT possible to legally change the font face or size in a SRT file. If some players may support non-standard options to do it, it's certainly not a good reason to implement them in BD3D2MK3D. Therefore, I think I will not modify deeply the current implementation. However, I will try to handle better the color change so that if a non-standard SRT contains color AND font face change in the same command, the conversion will detect the new color, and remove the other formatting option. I can't do much more. It is not the responsibility of BD3D2MK3D to support badly created subtitle streams with illegal formatting options, especially given the fact that almost nobody uses them.

Of course, I may change my mind, if someone can certify that the font face option is legal and supported by the vast majority of players. As I've read somewhere, only MPC-HD supports some illegal formatting options, and IMO it's certainly not enough to implement them.

[r0lZ]

OK, I have finished to modify SRTtoASS3D.tcl v0.5. It will be distributed with the next release of BD3D2MK3D. In the meantime, can you (or anybody) test it carefully ? It should now convert the color tags correctly, even when they are specified together with a font change. The font change itself is disregarded, for the reasons explained above.

The reset to the default color has been simplified too, and is now {/c}.

Please note that this is a beta, so please copy the original SRT2ASS3D.tcl file from the toolset folder elsewhere before overwriting it with this version, just in case...

Download: SRTtoASS3D.tcl

[konikpolny]

The the color restore replacing the literal color with {/c} works only for one liners. It doesn't work when the color is over 2 lines (or more I guess)