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

[Tenker]

Thank you rOIZ ,

__ENCODE_3D_LAUNCHER.cmd started unsuccessfully

https://www2.pic-upload.de/thumb/34000849/Image4.jpg (https://www.pic-upload.de/view-34000849/Image4.jpg.html)

I start to test CRF encoding mode with automatic "__ENCODE_3D_LAUNCHER.cmd" start and reports.


EDIT 15:48

unfortunately the same result
The file 00098_3D.264 is only 13.368 KB large and black content.

https://www2.pic-upload.de/thumb/34001268/Image5.jpg (https://www.pic-upload.de/view-34001268/Image5.jpg.html)

[r0lZ]

Damn! That's strange. Are you sure the BD has been correctly decrypted?

[frank]

The same error with Wonder Woman here on my Dell XPS 9560. dgMVCSource (deleted: and FRIMSource) decode black frames in HW-mode (Intel CPU).
Use software mode, that works. (You have to edit __ENCODE_3D_MOVIE.avs to force SW mode. Standard is auto -> selects HW mode on Intel machines -> error)
AFAIK I also had this issue with The Martian 3D.

[Tenker]

@frank

I changed the "__ENCODE_3D_MOVIE.avs" accordingly, unfortunately also without success.


...
LoadPlugin("D:\!_Video\BD3D2MK3D\toolset\LoadHelper.dll")
LoadPlugin("DGMVCDecode.dll")
#LoadPlugin("FRIMSource.dll")

#LoadPlugin("VSFilter.dll")
##LoadPlugin("SupTitle.dll")

# Load the two video streams (203220 frames per stream)
interleaved = DGMVCSource("00098.track_4113.264", "00098.track_4114.mvc", view = 0, frames = 203220, mode = "hw") # Old syntax for mode: hw = 0
#interleaved = FRIMSource("mvc", "00098.track_4113.264", "00098.track_4114.mvc", num_frames = 203220, cache = 2, platform = "")
# Current base view: left eye.
# The views are in the common order: AVC stream = left view, MVC stream = right view.
left = SelectEven(interleaved)
right = SelectOdd(interleaved)

# Build Side-by-Side stream
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
AssumeFPS("ntsc_film")

# Hardcode subtitles
#VobSub(".sub")
##SupTitle(".sup")

# Return the 3D clip.
Return(last)#.Info()


https://www2.pic-upload.de/thumb/34011010/Image6.jpg (https://www.pic-upload.de/view-34011010/Image6.jpg.html)


@rOIZ
I have sent the one PN ...

[frank]

Oh, man

mode="sw"

is the SW mode!!

[frank]

After new tests with Wonder Woman I have managed to start the encoding with FRIMSource decoder in HW mode. (platform = "hw")

But I needed several attempts to start. Something goes wrong with Intel drivers...
After successfully start of encoding the speed increased by 6 fps to 36 fps and the results are ok.

___________________
Win 10 Pro 64 bit v1703

[von Suppé]

...you can try to replace BDSup2Sub.jar with the fork developed by...
I haven't replaced the .jar file but just used the enhanced fork manually. Damn. Thinking I'd be sure enough.
When exporting SUP to XML_PNG, BDSup2Sub Enhanced 0.0.9 changes timecodes. My subs got out of sync. I found out that clicking the "Reset" button (FPS Target going to 23.976) was not enough to do it right (in BDSup2Sub 5.1.2 it always worked).

I reminded a way (like ages ago) to solve easySUP's 24fps bug with BDSup2Sub. After a quick test I realized that you have to tick "Change frame rate" and then set both FPS Source and FPS Target to 23.976. It somehow forces the right timecodes then and output will be in sync with input.

Strange to experience that I have to do the same now in the enhanced fork. It's absolutely tricky and something to keep a sharp eye on.

[Tenker]

@frank

Thanks, with FRIMSource decoder runs also without platform = "hw"

https://www2.pic-upload.de/thumb/34017868/Image7.jpg (https://www.pic-upload.de/view-34017868/Image7.jpg.html)

[r0lZ]

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

[r0lZ]

I haven't replaced the .jar file but just used the enhanced fork manually. Damn. Thinking I'd be sure enough.
When exporting SUP to XML_PNG, BDSup2Sub Enhanced 0.0.9 changes timecodes. My subs got out of sync. I found out that clicking the "Reset" button (FPS Target going to 23.976) was not enough to do it right (in BDSup2Sub 5.1.2 it always worked).

I reminded a way (like ages ago) to solve easySUP's 24fps bug with BDSup2Sub. After a quick test I realized that you have to tick "Change frame rate" and then set both FPS Source and FPS Target to 23.976. It somehow forces the right timecodes then and output will be in sync with input.

Strange to experience that I have to do the same now in the enhanced fork. It's absolutely tricky and something to keep a sharp eye on.
It's a well known bug of BDSup2Sub (old, new and ++ versions). I have reported it to the author of the recent fork, but he don't understand that it's really a bug, and he has rejected my request to fix it. Perhaps you will have more chance to convince him that there is indeed something totally abnormal? See this post (https://forum.doom9.org/showthread.php?p=1812419#post1812419) and the following in the BDSup2Sub thread for more info.

[Tenker]

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
:thanks:

[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é]

See this post (https://forum.doom9.org/showthread.php?p=1812419#post1812419) 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 (http://msystem.waw.pl/x265/).
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 (http://x265.ru/en/builds/), 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 (http://komisar.gin.by) (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. :scared:
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 (https://www.videohelp.com/software/x264-Encoder) 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 (https://forum.doom9.org/showthread.php?p=1820011#post1820011).)

[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 (https://forum.doom9.org/showthread.php?p=1752513#post1752513). 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 (https://www.virustotal.com/en/file/644b19d2e0b77bc6fc3f19a8f7d7eb2b7fce5c2b1713c0cc809ea088682c61eb/analysis/). 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 (https://www.tcl.tk). TCL (https://en.wikipedia.org/wiki/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]

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).

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 ?

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.

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.

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.

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).

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.

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 (https://en.wikipedia.org/wiki/SubRip#Formatting) (as well as other sites like this one (https://www.visualsubsync.org/help/srt)), 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 (http://download.videohelp.com/r0lZ/tmp/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)

[konikpolny]

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.:) Sorry, I always thought that the font change tag is standard in SRT. If it is not, and as it seems only MPC-HC will read it, there is not much reason for the SRTtoASS3D tool to support.

[r0lZ]

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)
Oops, yes, it might disappear if the color change is on the first line and the restore it is on the second line. It's because I try to remove the {/c} when it is useless, but I suppose that it is better to keep it anyway. After all, {/c} will just do nothing if it doesn't follow a color change, and it should not hurt.

I'll fix that in the final version...
:) Sorry, I always thought that the font change tag is standard in SRT. If it is not, and as it seems only MPC-HC will read it, there is not much reason for the SRTtoASS3D tool to support.
No worries. For me, it's much more simple to not implement it, as otherwise big 3D problems can arrise with large font faces.

[konikpolny]

SRT is obviously a basic subs format. I think that originally it was meant to have only basic formatting and in time developers considered it could also support font change as well. It's just there is nobody to care about writing an updated spec :). So it's up to the player whether to implement the font change tag or not. I just tried PotPlayer and just as MPC-HC it respects font change in SRT and displays the change correctly. It seems that both players consider font change tag an important addition and a tag worth having for SRT format. :).
I don't know about any other 'unusual' tags like font size (I've never seen it) but it seems that positioning, even though mentioned in the SRT specs there (https://www.visualsubsync.org/help/srt), is not supported by MPC-HC or PotPlayer.

[konikpolny]

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 boxThis is exactly what I meant.
Anyways, I will have more tests for positioning with the 2Dxml guides in my future projects, now that I understand it.
Thanks

[konikpolny]

Talking about subtitles, as regards pic based subtitles they are kind of too big for my use and I've always wondered if the players can reduce their size. Do you know if any players provide control over the size of the sup or idx/sub format subtitles? I haven't been able to find ... :confused:

[r0lZ]

No. Normally, the size of the graphics subtitles is determined by the author, and cannot be changed. It's a important advantage for the 3D subtitles, as otherwise, if the player shrinks (or expands) them, the offset between the two views will change, and therefore the subtitles will appear at the wrong depth. That can and certainly will ruin the 3D experience.

Of course, the problem is different for 2D subtitles, and it may be more pleasant to reduce them somewhat, especially if the movie is played on a computer. You can of course demux them, use the scale feature of BDSup2Sub, and remux the modified subtitle in the MKV, but AFAIK you cannot do that on the fly. And of course, I don't recommend to do it with the 3D subtitles.

[konikpolny]

Thanks for the info. True about 3D pic subtitles ;)

[r0lZ]

I just tried PotPlayer and just as MPC-HC it respects font change in SRT and displays the change correctly.I use PotPlayer often, especially to watch the 3D movies on my PC. It is very good, but it doesn't support the ASS subtitles well, and especially the 3D subtitles produced by SRTtoASS3D. The problem is that for a 3D movie, two subtitles must be displayed at the same time. And PotPlayer is unable to do that. It shows only one of the two subtitles. Of course, the effect is very bad, even worse than 2D subtitles. It's a pity, as otherwise, PotPlayer is very good. MPC-HD does a better job for the 3D ASS subtitles, but doesn't support the 3D movies well. [EDIT: This bug has been fixed.]

I have replaced the SRTtoASS2D.tcl script with a new version that fixes the problem of the </FONT>. Now, </FONT> is replaced anyway with {\\c}, even if it follows a font change that has been removed. That means that a subtitle can contain an useless {\\c} if it follows a font face change that has been removed. It should not hurt, and given the fact that the font face changes are not officially supported by the SubRip specs, and extremely rarely used, you should normally never see an useless {\\c}.

I haven't changed the version number (still 0.5) since the previous beta has never been released officially, but this version is dated November 11, 2017. It should be the version that will be distributed with the next version of BD3D2MK3D.
Download: SRTtoASS3D.tcl (http://download.videohelp.com/r0lZ/tmp/SRTtoASS3D.tcl)

As a conclusion for the whole discussion about the formatting options of the SubRip/SRT format, I suggest to use ONLY ASS (or SSA) subtitles if the formatting and font changes matter. After all, all video players sophisticated enough to respect complex formatting options are certainly able to support the ASS format, and therefore I see no advantage in using the old, deprecated SRT format. And if, per chance, you want to use a SRT containing complex formatting like font changes, I suggest to use AegiSub to convert it to the more powerful ASS format. SRTtoASS3D is only a basic tool to convert true SRT files to ASS 3D, and it does it well as long as the SRT respects the limitations of the format.

[sheppaul]

The problem is that for a 3D movie, two subtitles must be displayed at the same time.
I just don't understand it. Why does it require to display two subtitles if the player can display it properly with 3d depth? What's the exact case of yours for 3d playback? mkv3d + srt? or Half-SBS 3D?

[r0lZ]

In a 3D BD, the video format is AVC+MVC. The subtitle stream for a specific language contains only one subtitle, and the MVC video stream contains the information necessary to control the depth of the subtitles in real time. That information is stored in Offset Sequences (the so called 3D-Planes), and BD3D2MK3D extracts it and store it in .OFS files during the creation of the project.

Unfortunately, when the movie is re-encoded in another 3D format (Full or Half SBS or T&B or frame sequential) the MVC stream is lost, and of course the offset sequences are lost too. Furthermore, as far as I know, no player is able to directly use the OFS files to mimic the behaviour of a real BD3D player.

To be able to display the subtitles in 3D with the correct depth, it is therefore necessary to build a single stream of subtitles with the two "views" of the subtitle. It's what BD3D2MK3D does when it converts the subtitles to 3D. For example, for a subtitle shown at a specific timing in Half-SBS, it takes in the corresponding OFS file the offset to apply at that timing, and then it duplicates the image of the subtitle, and combine them side by side with the right offset. The combined image is then resized. (Its width is divided by 2 for Half-SBS.) That operation is repeated for all subtitles in the stream with different offsets for all subtitles. Finally, the whole subtitle stream is re-created with the new images, to obtain the final Half-SBS subtitle stream.

Indeed, when working with graphic subtitles like the BD sups, the two streams are combined to form a single stream with double images, exactly like the two video streams are combined to form a single SBS stream. But things are somewhat different when the subtitle stream is text based. When a SRT stream is converted to 3D, there is no way to combine the two views of the same sentence in the same image, since the stream is not image based. Therefore, it is necessary to place the text for the left eye at a specific position on the screen, and the text for the right eye at another position. Since with the ASS format, it is not possible to specify that a part of the text must be shown at a specific position and the rest of the same text at another, it is necessary to split the stereoscopic subtitle in two parts: one for each eye. Each part has different X positions (for SBS), as you can see in this extract of an ASS stream produced by BD3D2MK3D:

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:04:27.10,0:04:28.51,Default,,8,968,8,,{\pos(481,867)}Regardez, des étoiles filantes.
Dialogue: 0,0:04:27.10,0:04:28.51,Default,,968,8,8,,{\pos(1439,867)}Regardez, des étoiles filantes.
Dialogue: 0,0:04:29.14,0:04:30.76,Default,,8,968,8,,{\pos(479,868)}Vite, vite, faites un vœu.
Dialogue: 0,0:04:29.14,0:04:30.76,Default,,968,8,8,,{\pos(1437,868)}Vite, vite, faites un vœu.

The ASS format specifies that several subtitles can be displayed at the same time, so it's normally not a problem, but obviously, some players do not implement that possibility, and of course, if only one subtitle is displayed, it is not possible to see the subtitle at the right depth, and the effect is terrible, since the subtitle is seen by one eye only ! (The SRT format cannot show two subtitles at the same time, and anyway, there is no possibility really implemented to force a subtitle to be printed at a specific position. It's why it is necessary to convert SRT to ASS to obtain 3D subtitles.)

Of course, the problem affects only the 3D subtitles in ASS (text) format. As explained above, the graphics subtitles converted directly to 3D from the BD are not affected. Luckily, the 3D movies in 3DBD must have their subtitles in BD SUP (graphics) format, and the problem concerns therefore only the peoples who want to convert SRT files downloaded from the internet to 3D ASS.

I don't use the MKV3D format produced by MakeMKV, but in that case, the video is not re-encoded, and therefore is still in AVC+MVC format. That means that the offset sequence are still present in the AVC, and of course, if is theoretically possible for a good 3D player to use them to display ANY KIND of subtitle at the right depth, including SRT files. I don't know if Stereoscopic Player can already do that, but anyway, that MKV3D format is very specific, not supported by any standalone player, and IMO, due to its large file size, not suitable for other things than archiving of your original BDs.

[konikpolny]

for a 3D movie, two subtitles must be displayed at the same time. And PotPlayer is unable to do that
my PotPlayer displays both 3D lines correctly for the ASS subtitles.

the problem concerns therefore only the peoples who want to convert SRT files downloaded from the internet to 3D ASS.This may be an off the subject note now, but, I use the SRT2ASS3D conversion for the SRTs OCRed by myself from the BD3D2MK3D project subtitles streams, not the internet.

And as far as the Font Face change is concerned I obviously have to add this information by hand and it is much easier to change the font face in a single subs line (SRT) rather than in 2 as in ASS subs and then do the conversion. However rarely I have done it. I did it when I wanted to get the same effect as in the orginal BD3D where for some subtitles the color change went along with a Font change.
However old and simple the SRT format is, it is the most widely used. Here it is a great format for achieving good quality text 3D ASS subtitles.
If I have time I may look in the code of SRTtoASS3D.tcl and modify it according to my needs. :)

[r0lZ]

I've just verified, and indeed, PotPlayer is now able to show the two subtitles of a 3D ASS stream correctly. An old bug has been fixed. Yet another good point for that excellent player (IMO the best).

If you use PotPlayer and the original subtitles from the BD, why do you convert them to ASS 3D ? PotPlayer can show the 3D SUP streams without problem. Is it because you encode in Full-SBS (or Full-T&B or Frame Sequential) ?

Also, if you keep only a single audio and a single subtitle stream and you need the subtitles anyway, I suggest to use the option to hardcode (burn) the 3D subtitles in the movie itself. That works with all players, and with all 3D formats ! :-)

[konikpolny]

There are 4 reasons why I prefer the ASS 3D subtitles to the graphic ones:
1) I do indeed encode full-SBS, :)
2) As I said earlier the graphic subs are a bit too big for my use. (But I will try resizing with the BDSup2Sub+remux and see how that works for me. I know this will work even for full-SBS 3D in at least MPC-HC :sly:).
3) In general I prefer having text than graphic even if it takes a bit more work to get (I have good regexes to fix OCR errors :sly:)
4) I am a bit crazy but I like having control on how subtitles look, like colour and font :).

I suggest to use the option to hardcode (burn) the 3D subtitles in the movie itself.
:) I think this is the worst thing that one can do ever. It damages and injures the movie irretrievably and forever leaving the user with no choice but to accept a decision once made. I am strongly against it! Also, I am outraged when an original BD burns in the forced english subtitles on all available playlists / video streams as if everybody just wanted to use the english subtitles! This is horrible. :mad:

[r0lZ]

:) I think this is the worst thing that one can do ever. It damages and injures the movie irretrievably and forever leaving the user with no choice but to accept a decision once made. I am strongly against it! Also, I am outraged when an original BD burns in the forced english subtitles on all available playlists / video streams as if everybody just wanted to use the english subtitles! This is horrible. :mad:
I agree that forced subtitles burned by the author of the movie or by the author of the BD are terrible, because you don't have the choice of your preferred language any more. But if it is YOU who burns the subtitles YOU have decided to watch anyway, things are totally different.

Like you, I prefer to leave the movie "fresh", without subtitles, and I just want to turn them on when I need them. But if that works perfectly for 2D movies, things are different for 3D movies, especially if you want to play them with a specific standalone player, such as a 3D TV. Usually, there is no way to display correctly the 3D subtitles with hardware players. (My Samsung TV, for example, can only display 2D SRT files NOT inside the MKV container! It is totally prehistoric!) Therefore you have to support the 2D subtitles (and that's the most horrible thing you can imagine) or just watch the movie without any subtitle at all (and that's not a solution if you don't know at all the original language).

The big benefit of burning the 3D subtitles is that the movie will be watchable with all kind of 3D equipment, including any 3D TV with bad subtitle support. Therefore, I burn the subtitles when the movie doesn't have a sound track I can understand and it has a good 3D subtitle track in French or English. In that case, I have to turn the subtitles on anyway, so why not burn them, and avoid all possible player related problems? IMO, it's certainly the best solution.

[sheppaul]

therefore is still in AVC+MVC format. That means that the offset sequence are still present in the AVC, and of course, if is theoretically possible for a good 3D player to use them to display ANY KIND of subtitle at the right depth, including SRT files.

It works well with Potplayer. I tried with ISO backup of blueray + srt.

[r0lZ]

An ISO of a BD is not a 3D MKV produced by MakeMKV. The player expects the 3D offsets in a 3D BD, not necessarily in a MKV (where it doesn't normally expect the MVC stream at all).

But anyway, the info is interesting. I did not know that. Being able to show external SRT with the 3D offsets that have not been created specifically for that subtitle track is a very good point for PotPlayer (although I suspects that the 3D is not always perfect, because the SRT subtitles are not always at the right place on screen). Thanks for the info!

[sheppaul]

I tried again with 3D MKV by MakeMKV + SRT and it seems to work too. Probably with blu-ray folder (didn't test) if the 3d depth is coming from MVC streams.

One tip for opening blu-ray folder + srt subtitles.

D:\movies\example
D:\movies\example\BDMV
D:\movies\example\CERTIFICATE

Assuming that there is blu-ray folder named example, Potplayer will open the following srt files automatically with Open Folder menu (F2) or drag-and-dropping the blu-ray folder (example) to the player.

1. D:\movies\example\BDMV\bdmv.srt
2. D:\movies\example\example.srt

[r0lZ]

Great info again. But I wonder how PotPlayer selects the offset sequence to use, since an external SRT is not associated with a specific 3D-plane. I know that the first plane is often pure garbage (containing only null bytes, or a constant depth) and it is somewhat difficult for an human to choose within the available planes the best one for a specific SRT or language. I don't think that PotPlayer can do an analysis of the available planes to reject the ones that are obviously not suitable for the given SRT file, as that would require much time. Also, the first non-null 3D-Plane is usually made for the subtitle in the original language of the movie, and has therefore usually no 3D values for the forced subtitles of the other languages, and is therefore not really suitable either. So, does it take the next available plane, blindly? Or can it use several planes, and automatically switch to another plane if a specific subtitle has only a null 3D value in the default plane?

I don't have a 3D graphic card, so I can't test, but if you can figure out how PotPlayer selects and handle the 3D-plane for the external SRT files, please let us know.

[sheppaul]

I don't know the technical details but it seems to get the info from mvc streams on the fly. There is one more thing from the latest beta version. I contacted the developer of the player to adjust the relative pixels to 3d depth for text subtitles and it seems to be implemented.


ps. Actually, I made a feature request to use OFS file with text subtitles for re-encoded 3d videos as it looks possible and rather easy compared to get the info from mvc streams. However, failed to make him understand. :p If the OFS info were merged in mkv container, it would be more practical and accessible information.

[r0lZ]

... to adjust the relative pixels to 3d depth ...What do you mean? It it to add the possibility to globally move all subtitles a bit more toward the spectator or behind the screen?

If the OFS info were merged in mkv container, it would be more practical and accessible information.
I agree. It's why BD3D2MK3D includes the OFS files in a ZIP archive in the final MKV, just in case...

Perhaps you should try again to explain the idea to the developer, or direct him to this thread. It would be indeed a nice addition to PotPlayer if he could support the 3D depth from external or muxed OFS files. At least, it will be possible to play SBS or T&B files with SRT subtitles and the (more or less) correct depth.