...No, they are stored in "[project folder]\[movie title]\[MPLS number]"... ...are extracted only when they are needed to convert the subtitles to 3D

Then I think to know why I don't have these files/folders. I was doing a "Frame Sequential" mkv. If my understanding & memory serves me right, in that case only 3D subs can be done if you hardcode a subtitle on both left- and right-eye streams. Eventhough the "Subtitles type" in tab 2 was set to "3D only", I left the option in "Hardcode subs on video" on tab 5 to "None".
I do wonder however, why the created "**.2D.sup" files aren't an exact match of the demuxed (2D) sups. They don't have to be altered, my guess?

As for the 3D-planes extraction tool:

Quote:

Originally Posted by r0lZ

...the tool to extract them works only on the elementary MVC stream. You must therefore demux the MVC stream from...

Can't help myself for trying out, but in the 3D-planes extraction tool's browser window it is however possible to select the ssif file as input (setting the "filetype" box to "All files (*.*)". And it will output. I compared this output to the result of demuxed mvc file as input.
Both show 6 same-named *.ofs files that are the same size, but not bit-equal (checked with hash-checker). Both "3D-Planes.log" files do show same summary data for the first 5 planes, but Plane 6 is very different indeed.
Of course, from now on I will always run the 3D Planes extractor with the firstly demuxed mvc as source.

Edit:

Quote:

Originally Posted by r0lZ

...Generating a whole project with BD3D2MK3D just to have its full 3D-Planes log may be overkill...

Maybe, but once a project is finished, to me it proved very educational to look at the project folder.
Seeing all these files created and used, specially when you choose the windows explorer column "Date created", you can almost chronologically step-by-step follow what steps were taken. Very informative.

Of course I'll do a lot more testing and will certainly use the enormously handy subtitle tools.

I have noticed several times some problems with the original (2D) subtitle streams, especially in Asian films. They contain often bad or empty subtitles, that can and should be removed. Also, BDSup2Sub merges identical subtitles if the gap between them is very short. So, I've decided to load and save the 2D subtitles anyway, just to clean them up. It's also during that first conversion that BD3D2MK3D analyses the stream, determines if there are forced subtitles, and see if the stream can be directly converted to 3D.

However, using the 2D version saved by BDSup2Sub may be a bad thing in some precise circumstances, notably when two (or more) different subtitles are displayed at the same time. It seems that the standard version of BDSup2Sub cannot properly handle them, as it removes the two subtitles. If you want to avoid this, you can try to replace BDSup2Sub.jar with the fork developed by Scorpius666 and available here. Or, if you are confident enough, just use the demuxed stream as it is. (It's the stream without the 2D or 3D extension in the BD3D2MK3D project directory.) Since you don't need to convert them to 3D, the original stream should be OK if it is displayed without problems when you play the original BD.

I haven't written MVCPlanes2OFS.exe myself, but I helped its author. The problem is that the detection of the SEI messages is fairly basic, and I cannot assume that the extraction works correctly when used on a complex file with a lot of multiplexed streams. So, IMO, extracting the 3D-Planes from the SSIF or dependent M2TS may work fine, but it may also fail, depending of the mux and the situation. It is at least safer to extract them from the demuxed MVC elementary stream, so it is a good idea to do it.

...you can try to replace BDSup2Sub.jar with the fork developed by Scorpius666 and available here

I'm sorry, something is not clear. I downloaded the latest version here: https://github.com/mjuhasz/BDSup2Sub/wiki/Download
but it's the same version you have already in your toolset folder.
Can you please confirm this is the proper, latest "fork"?
I have always been using this version as latest download from Videohelp site.

So, reading this, I think it would be proper custom to always load a demuxed SUP in BDSup2Sub or its fork and export again, just to make sure that errors are cleared out.
I was surprised to see how many warnings there were with SUP from Avatar, for instance.

The fps than you show are the encode speed: 110 encoded frames per second.
Not related with fps to play than is a correct 24000/1001

The problem is when the first pass finish with a bitrate of 14 Kb/s instead something like the 15 Mb/s selected.
I don't know for what, the command line to encode seems fine.
Put the __ENCODE_3D_MOVIE.avs to see anything wrong.

I don't understand. Indeed, even with a powerful i7 CPU, an encoding speed of 115fps is very fast! And the final file size is also abnormal.

IMO, there is something wrong with the decoding of the video. Have you played the final MKV? Does it contain video, or just black frames? Verify if the end of the movie contains real images too.

I have already noticed that sometimes, x264 encodes the beginning of the movie correctly, but suddenly all encoded frames are totally black, without reason, and up to the end of the movie. I have never understood what is causing that (rare) problem, but that seems related to an x264 bug. Anyway, when that happens, relaunching the encoding is sufficient, and the second time the movie is encoded successfully.

I suspect a problem with the PC going in Sleep mode during the encoding, or something like that. There is a well known x264 bug that makes it fail to encode properly when it wakes up from sleep mode. Do you encode with a portable computer? Are you sure you have launched __ENCODE_3D_LAUNCHER.cmd and NOT directly __ENCODE_3D.cmd ? __ENCODE_3D_LAUNCHER.cmd ensures that the computer will not go to sleep mode during the encoding.

Also, I suggest to use only the CRF encoding mode. It produces ALWAYS a slightly better quality than 2-pass for the same overall bitrate, so 2-pass should be used ONLY when the final file size must be precisely controlled (for example to burn the MKV on a DVD). Since the CRF mode requires only a single pass, it has less chances to encounter a problem, and it works very well.

Also, are you sure that the original BD has been properly decrypted? You cannot encode directly the original protected BD.

Anyway, I did Wonder Woman without problem myself, so it should not be a problem to encode it.

I have started the process automatically (then "__ENCODE_3D_LAUNCHER.cmd" started) and the file "__ENCODE_3D.cmd" was started without success.

DVDFab has converted the 3D ISO without problems, abe I ALWAYS use your software.

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

OK, so it seems that you have encountered the rare "black frames" bug. As I wrote, I don't know its cause, so I can't help you more.

Just retry.

Quote:

Originally Posted by Tenker

What file and how do I have to change it so I can encode CRF instead of 2-pass?

There are a lot of files to modify slightly. It is better to start over. But before doing so, just relaunch __ENCODE_3D_LAUNCHER.cmd, and let it run for a couple of minutes. Then, have a look at the encoding process. If it's again above 100fps, then the bug happens again. Kill the encode and redo the whole project, this time in CRF mode. Verify also when the second pass is running. The first pass may be OK, and the bug may happen only during the second pass.

Otherwise, if the encoding speed is normal, let the encoding run, and carefully verify if the final MKV is OK, especially near the end of the movie. As far as I know, the black frames bug can occur at any point in the movie, but it continues always up to the end of the movie. Therefore, if the end of the credits is OK, the rest should be OK too.

Sorry for the wasted time. Unfortunately, I have no way to reproduce the bug, and I cannot understand exactly why it happens and how to implement a workaround to fix it. Anyway. I'm sure it's not a bug in BD3D2MK3D itself, and therefore I am probably unable to fix it myself, even if I could understand it.

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.

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 and the following in the BDSup2Sub thread for more info.