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

[Wolfy59]

Thanks r0lZ

[thahandy]

Originally Posted by r0lZ

@thahandy

Yes, BD3D2MK3D include the audio and subtitle streams in the calculation, as well as the muxing overhead. I have changed already slightly the calculation, because someone else has reported that it was off, and the last tries I did were perfect. So I don't know how you obtain a wrong file size. I'll check again. Perhaps it happens when the audio streams are converted to AC3 or AAC?

Tbh. I didn't encode with that value, as it was a bit high acording the calculator and calculated the size

I've let it run again it its tells 11485Kbit @ 161min. With 2080MBytes to add I get ~15900MBytes calculated (14.8GByte)
So i guess you're using byte (2^) instead bytes?! Which clears a lot of things. Bytes is the thing I'm after!

10.5Mbit + DTSHD-MA +SUBs -> 13,6 GB (14.674.780.160 bytes)
10,8Mbit + DTSHD-MA +Subs -> 13,8 GB (14.845.025.940 bytes) (target 14305MB)
11.1Mbit + DTSHD-MA +SUBs -> 14,3 GB (15.408.095.232 bytes)
11.4Mbit + DTSHD-MA +SUBs -> 14.8 GB (15.900.000.000 bytes) (estimated by BD3D2MK3D)

The encoding settings are included in the tags.xml file (as well as the tags defined by the user in tab 3).

thank you!!!!

The fact that the subtitles are placed at different positions in some 3DBDs is intentional.

[...]

So, you are lucky if your 3DBD has subtitles in different positions. The author did a great work! It's usually much better than the subtitles in the bottom center, even if they are placed in front of the foremost objects. And of course, I have no intention to create another tool to destroy the correct 3D positions!

Now u mention it it makes sens Thanks for this extended explanation.
All the non-naive languages (dutch) are subtitled by default on TV and Disk as long I can remember and seems we're used to look down for text. The funny thing is when it ran in the cinema, the subtitles where at the bottom center like we used to and this BD is the first the subtitles are placed where we're looking as you mentioned.
(note that our subtitles are simplified of whats actually being said. Otherwise you're only reading the whole movie. Sadly not everyone sticking to this "rule")

Perhaps it's possible with BDSup2Sub, but I don't think so. IMO, the easiest way to do what you want would be to convert the original SUP to SRT (with SupRip), and then re-create a SUP file from the SRT (with SubtitleEdit). But again, I do not recommend to do that!

I can only fix horizontal to center, vertical it seems to refuse to fix(to all subs). I assume vertical is the easy things to fix, as it has only one offset from top.

Guess I'll just leave the subtitle it is, as it's just one movie. Thanks for the input!

[r0lZ]

Originally Posted by thahandy

So i guess you're using byte (2^) instead bytes?! Which clears a lot of things. Bytes is the thing I'm after!

Sorry, but for me it's still terribly obscure. What do you mean? Bytes is the plural of byte, and nothing else.

In your example above, what is your target MKV file size?

[thahandy]

Originally Posted by r0lZ

Sorry, but for me it's still terribly obscure. What do you mean? Bytes is the plural of byte, and nothing else.

15GB = 1.536MB = 15.728.640KB = 16.106.127.360Bytes
So in my case at the moment need to set it at 13969MB to get a output around 15.000.000.000Bytes

In your example above, what is your target MKV file size?

MKV set at 15000MB which was given an estimated 11485Kbit to be used

[r0lZ]

Ah, OK. BD3D2MK3D uses the real (computer) sizes, as it should. A GB is therefore 1024 * 1024 * 1024 bytes. And your final MKV file size should be around 15,728,640,000 bytes. (BTW, the right column in your illustration should not exist. There is officially no KB at 1000 bytes, or mega at 1000000. The industry of the CD-R, DVD-R, BD-R had adopted these wrong values for commercial reasons only. But it's a lie, and no program should use these values.)

BTW, I did just two very rapid tests on a small clip. The duration of the clip is 0:03:24, and the audio file size is 4788 KB. When I ask for a target file size of 300MB, the computed bitrate is 11571 kbps, and the final MKV size is exactly 300.098 MB. Not too bad!
If I ask for a final file size of 1000 MB with the same clip, the bitrate is 39006 and the final file size is 1001.361 MB. I agree that the bitrate is slightly too high, but only a little. I'm not sure I need to try to obtain a better value. Computing the overhead is extremely difficult, perhaps impossible. I can't guarantee extremely accurate results.

I am currently encoding a longer movie, but even with the superfast preset, the two passes will take some time. I have requested a final file size of 10 GB (10240 MB in the GUI). I'll report the result tomorrow. If it is true that the final size is really too different, I'll try to improve the formula...

[EDIT]

Originally Posted by thahandy

15GB = 1.536MB = 15.728.640KB = 16.106.127.360Bytes

Correct.

Originally Posted by thahandy

So in my case at the moment need to set it at 13969MB to get a output around 15.000.000.000Bytes

If you want a final file size of 15,000,000,000 bytes, you have to compute the right number of real MBs: 15,000,000,000/1024/1024 = approximately 14305 MB, not 15000 (and not 13969 neither).

[thahandy]

Originally Posted by r0lZ

Ah, OK. BD3D2MK3D uses the real (computer) sizes, as it should. A GB is therefore 1024 * 1024 * 1024 bytes. And your final MKV file size should be around 15,728,640,000 bytes. (BTW, the right column in your illustration should not exist.There is officially no KB at 1000 bytes, or mega at 1000000. The industry of the CD-R, DVD-R, BD-R had adopted these wrong values for commercial reasons only. But it's a lie, and no program should use these values.)

The picture was just random to get the idea.

yup, byte to GB is a but a mess in compute land
CD 700 = 734.000.000Bytes (700MB)
dvd-r 4.7 = 4.700.000.000Bytes (4.5GB)
16GB flashdisk = 14.700.000.000Bytes (13.7GB)

Thats why I was after the real Bytes.
I just need to make a 1,024^2 compensation in BD3D2MK3D, no worries

BTW, I did just two very rapid tests on a small clip. The duration of the clip is 0:03:24, and the audio file size is 4788 KB. When I ask for a target file size of 300MB, the computed bitrate is 11571 kbps, and the final MKV size is exactly 300.098 MB. Not too bad!
If I ask for a final file size of 1000 MB with the same clip, the bitrate is 39006 and the final file size is 1001.361 MB. I agree that the bitrate is slightly too high, but only a little. I'm not sure I need to try to obtain a better value. Computing the overhead is extremely difficult, perhaps impossible. I can't guarantee extremely accurate results.
[..]

Its off by 0.1%, no need to change

[EDIT]

[EDIT]

Correct.

If you want a final file size of 15,000,000,000 bytes, you have to compute the right number of real MBs: 15,000,000,000/1024/1024 = approximately 14305 MB, not 15000 (and not 13969 neither).

You're correct. A 1024 to much

http://www.dr-lex.be/info-stuff/videocalc.html

[r0lZ]

The CDR is correct and it uses the right (binary) size. 4,700,000,000 bytes for the DVD-R is not 4.5GB but 4.377 GB and not the false 4.7 GB! (BTW, when you select 2-pass in file size mode in BD3D2MK3D, the default value is 4470 MB, because it's a bit less than the size of a single layer DVD. It's handy if you want to burn a 3D movie on a DVD.)

And I didn't know that the flashdisks have adopted the wrong (decimal) values too. That's really stupid.

Since all file and disc sizes are displayed in Windows (and, afaik, also in Linux, Mac, Android and other OS) in real binary sizes, it is normal to use the same units in BD3D2MK3D. There is no reason to mix binary sizes for the audio and subtitle files, and decimal sizes for the target disc.

[frank]

At end of project creation I got an error message:

Warning: There is only 17.09 GB of free space on your target disc.
You may still need 21 GB...

You cannot cancel that window and return to the main. The Abort button does the same as the Return button.
To end the program you must kill it's process in task manager.

[r0lZ]

Oh, I have added that warning recently, but I don't remember if I have tested it in real circumstances. I'll have a look.

Anyway, don't worry. It is displayed at the very end of the project creation and the project should be usable without problem (at least if you have enough disc space).

[EDIT] Indeed, there was a bug here. It is fixed, and I will release a new version soon...

[r0lZ]

Originally Posted by thahandy

Its off by 0.1%, no need to change

For your information, I have finished the test of the full movie (1:25:31). I have requested a final size of 10 GB and obtained exactly 9.997 GB. The difference is minimal, and therefore I will not change the formula. Especially because with the two first tests (with the short clip) the final file was slightly too big, and with this test, it is slightly too small. It will be probably very difficult to obtain a formula that gives perfect results in both cases.
Anyway, I have slightly changed the "MB" label in the last tab to make it obvious that it means "real MB" (1024KB).

[thahandy]

Sorry to poke you again

I get a subtitle error when converting with BDSup2Sub.
On the other hand, it's working fine when I select bdsup2sub++ at Settings.
(these X/Y position errors are a real issue with bdsup2sub++ ?

*** Converting "00800.track_4608.Eng.sup" to 3D VobSub. Please wait!
*** Converting subtitle file "00800.track_4608.Eng.sup" to 3D SBS using 3D-plane "3D-Plane-00.3dp" and additional depth 0...
Subtitle language: eng (English)
*** Converting subtitle "00800.track_4608.Eng.sup" to "temp_2D.xml"...
> "C:\\ProgramData\\Oracle\\Java\\javapath\\java.exe" -Xmx256m -jar "T:\\TOOLS\\BD3D2MK3D\\toolset\\BDSup2Sub.jar" "00800.track_4608.Eng.sup" -o "00800.track_4608.Eng.3D_2D/temp_2D.xml" --palette-mode keep --minimum-time 1 --language en --convert-fps 24p,24p
Loading d:\test2\00800\00800.track_4608.Eng.sup
#> 4 (00:00:24.449)
WARNING: Multiple PDS/ODS definitions: result may be erratic
#> 7 (00:00:29.371)
WARNING: Multiple PDS/ODS definitions: result may be erratic

[....]

#> 782 (01:12:07.790)
WARNING: Multiple PDS/ODS definitions: result may be erratic
#> 784 (01:12:13.296)
WARNING: Multiple PDS/ODS definitions: result may be erratic
Detected 0 forced captions.
There were 73 warnings
Writing d:\test2\00800\00800.track_4608.Eng.3D_2D\temp_2D.xml
WARNING: Problems during RLE decoding of picture OBJ at offset 0x001e2544
Writing d:\test2\00800\00800.track_4608.Eng.3D_2D\temp_2D.xml
There was 1 warning
Conversion finished.
*** Found 816 captions, including 0 forced captions.
*** Adding 3D depth info from "3D-Plane-00.3dp" to "temp_2D.xml"...
Source 3D-plane: 3D-Plane-00.3dp
Min depth: 2
Max depth: 64
Average depth: 13.41
Number of warnings for undefined frame's depth: 1
Number of subtitles processed: 816
Number of forced subs: 0
Frame rate of the stream: 24.0
Frame rate used to convert the drop frames timecodes to frame numbers: 24.0

*** Converting "temp_2D.xml" to 3D...
Error verifying input PNG "temp_2D_0147.png": Image is monochrome. Histogram: 0,0: (0,0,0,0) #00000000 graya(0,0)
The output stereoscopic PNG image may have been created, but it is not included in the XML file.
Input file: temp_2D.xml
Stereoscopy mode: Side by Side (left view first)
Additional depth: 0
Resize filter: Mitchell
Number of subtitles processed: 816
Conversion of 2D XML/PNG files to 3D using ImageMagick took 103 seconds (00:01:43)
*** 1 ERRORS converting 816 subtitles to 3D!
* Can't convert "00800.track_4608.Eng.sup" to 3D VobSub!

-------------------------------------------------------------------------------

*** Converting "00800.track_4608.Eng.sup" to 2D VobSub. Please wait!
No captions found in "00800.track_4608.Eng.sup" or conversion error. Stream skipped.

-------------------------------------------------------------------------------

Subtitle 147 and 148 are duplicates with bdsup2sub++ (also showing on the raw m2ts file)
Subtitle 147 is blank with BDSup2Sub.jar


http://tempsend.com/3CBEBC55CB

Also is there a way to change some minor settings w/out demuxing everything again?

I'm using v0.70

[tebasuna51]

@thahandy
I delete your attached image because was empty.

Seems a BDSup2Sub.jar problem, the log at that subtitle is:

#> 147 (00:09:37.919)
WARNING: Palette animation: result may be erratic
#> 148 (00:09:40.296)

Using SubtitleEdit:

147
00:09:37,919 --> 00:09:38,420
No!

148
00:09:38,587 --> 00:09:39,087
No!

149
00:09:40,297 --> 00:09:42,299
I said, no!

Seems BDSup2Sub.jar don't read 147 and skip the 148 duplicated (see time)

[r0lZ]

I have recently added the check for monochrome (black) subtitles. You can turn it off in the Settings menu if you wish, but at your own risk. Anyway, it seems that that malformed subtitles are not frequent, but they exist. There is no perfect way to avoid that problem, except by simply removing the bad subtitle during the conversion to 3D.

However, BD3D2MK3D should not stop completely, as it did in your case. The error concerns only a single subtitle in the whole stream, and therefore a warning should be sufficient. I will fix that bug immediately. Thanks for having reported it.

I do not recommend using the ++ version, as you can see when you select it in the Settings menu. The main bug is that it cannot process full-size PNGs. They are frequent in Asian films, and it is very dangerous to assume that it will work correctly. Anyway, even if it saves two times the same PNG (instead of a monochrome PNG), that doesn't mean that there are no bugs when ++ tries to process that malformed subtitles. In many cases, it saves a bunch of images, all for the same subtitle, and unfortunately BD3D2MK3D doesn't have a way to know what image is should retain. Therefore the final stream can be terribly bad. Usually, the java version gives much better results, although it has also some bugs.


You can modify an existing project without starting over. Most of the files that you can easily edit start with an underscore (plus tags.xml). For example, if you want to add an external subtitle stream (or, in your case, the 3D subtitle stream correctly processed with BDSup2Sub++), you should edit the _MUX_3D_OPTIONS.txt file and add an entry for the new subtitle. If you don't know the syntax, I suggest to create a project with a short clip, rapid to demux and with a subtitle stream. You can then easily copy the stream definition of the first clip. Be sure to change the file name, the language code and the label if necessary.

You can even do that after having encoded the final video stream with _ENCODE.cmd. To mux the MKV without re-encoding the video stream, just launch _MUX_3D.cmd.

[EDIT] tebasuna51 has replied when I was typing this post. Indeed, he is right. The "palette animation" is probably a bug of the java version. Unfortunately, none of the two BDSup2Sub versions are still developed, and we have to live with their bugs.

[tebasuna51]

The .xml created by BDSup2Sub seems correct because add the time for the duplicated (too short) 147-148

<Event InTC="00:09:37:23" OutTC="00:09:39:02" Forced="False">
<Graphic Width="70" Height="39" X="865" Y="924">00800.track_4608.Eng_exp_0147.png</Graphic>
</Event>

Maybe you can replace your extracted png empty whit this edited one:

[r0lZ]

I haven't seen the film, but IMO, the ++ version is right. There are probably really two "No!" repeated rapidly, and hence the two subtitles. (IMO, 0.5 second is not too short to read a short word like this.)

For your information, the error message of BDSup2Sub.jar is exactly this:

WARNING: Problems during RLE decoding of picture OBJ at offset 0x001e2544

Since I can intercept that message, I will probably modify the code to call BDSup2Sub++ automatically if that message is displayed by the java version. That should be sufficient to avoid most problems.

[EDIT]
Oh no! The conversion of the original SUP by BDSup2Sub++ is terrible. Full of errors! For many subtitles, it creates several PNG images, some of them purely black. And there are several <Graphic> definitions for the same subtitle. For example, subtitle # 5 produces temp_2D_0005_0.png (with the correct image of the subtitle) and temp_2D_0005_1.png (same dimensions but totally black). But in the XML, the position and size of the first image is wrong: all values are 0. The second image is correctly referenced... but is black. Therefore, when the image is converted to 3D, BD3D2MK3D skips the first definition and uses only the second one. And the result is a black frame.

There are other problems too. Subtitle 23, for example, is converted in 3 identical (and correct) PNG images: temp_2D_0023.png, temp_2D_0023_0.png and temp_2D_0023_1.png. (Why 3?) But the definition in the XML is totally wrong. BDSup2Sub (both version) can't display that subtitle because temp_2D_0023_2.png doesn't exist.

    <Event InTC="00:01:04:22" OutTC="00:01:06:04" Forced="False">
      <Graphic Width="0" Height="0" X="0" Y="0">temp_2D_0023_0.png</Graphic>
      <Graphic Width="0" Height="0" X="0" Y="0">temp_2D_0023_1.png</Graphic>
      <Graphic Width="392" Height="49" X="843" Y="924">temp_2D_0023_2.png</Graphic>
    </Event>

Conclusion: IMO, it is still better to use BDSup2Sub.jar, even if some subtitles disappear. At least, it creates an usable subtltle stream.
Perhaps later I'll try to remove the bad entries created by BDSup2Sub++, and change the image to use the good one, but currently I will simply fix the bug of the error and return only a warning when the java version can't decode a subtitle.

[r0lZ]

OK, I've found a workaround for the workaround!

When BDSup2Sub.jar is used to convert the subtitles to 3D and it has problems decoding some subtitles, BD3D2MK3D launches BDSup2Sub++ to convert the original SUP file. It's the first workaround.

However, if ++ is used to convert the original SUP directly to XML/PNG, there are many problems (described in my previous post). But it can convert the SUP to another SUP without problem, and it stores the correct bitmaps, positions and sizes in the target SUP. Therefore, when that new SUP is converted to XML/PNG, there are no problems any more, and all subtitles are correct. (However, there is only a single "No!" any more. Not sure why.) It's the second workaround.

So, currently, when the java version is selected, BD3D2MK3D uses it to decode the SUP to XML/PNG. If it detects the RLE decoding error message, it deletes the target XML/PNG directory, and converts the original SUP to a temp SUP with ++, and then the temp SUP to XML/PNG, again with ++. Finally, the conversion to 3D is made with ImageMagick as usual, and then the 3D XML is converted to SUP (or VobSub) with BDSup2Sub (java version). That means that 4 conversions are made with BDSup2Sub instead of 2, but at least the result is more or less correct.

If the ++ version is selected by default, there is another test, that detects if some subtitles have been converted in several PNGs, and when it's the case, the conversion is discarded, and the ++ version is used again to convert to the temp SUP, and the temp SUP to XML/PNG. Again, there are no errors and 4 conversions instead of 2. (That workaround was already present in the current version of BD3D2MK3D, and it's why you have not noticed the problem when converting with ++.)

I think it's the best solution, as everything is correct (except perhaps the missing second "No!"). Anyway I can't do a better job.

Note also that currently, there is no check for these bad subtitles when the original SUP is converted to 2D SUP or VobSub (because they are never converted to XML/PNG and I have no way to analyse the bitmaps).

I would like to know what is the BD that has produced that subtitle errors. Is it a Chinese movie? They have often many problems with the subtitles.

I will release a new version soon, with this fix and the fix for the problem of "not enough free disc space" dialog...

[r0lZ]

OK, here is the fixed version.

The problem of the disc space dialog is certainly fixed.

The workarounds for BDSup2Sub's RLE decoding errors should work, and it works fine with the subtitle stream posted by thahandy, but it is difficult to be sure that it works in all cases.

Anyway, now, the program should not reject a subtitle stream any more just because one or two subtitles have not been correctly decoded.

v0.71 (August 16, 2015)
- Fix: Error after having displayed the "not enough free disc space" warning at end of project creation.
- Workaround for RLE decoding errors wnen converting subtitle files to XML with BDSup2Sub.jar.
- Small cosmetic changes.

Download: BD3D2MK3D.7z

[MaistroX]

Hi r0lZ




I get the following on Insergent 3D BD when I push "Do it!"

"invalid character "*"
in expression "round (112*201*535*488 / 1024.0..."
invalid character "*"
in expression "round (112*201*535*488 / 1024.0..."
(parsing expression "round (112*201*535*...")
invoked from within
"expr round ($discspace1 / 1024.0 / 1024.0 / 1024.0 * 100.0) / 100.0"
(procedure "GenerateAvs" line 722)
invoked from within
"GenerateAvs"
invoked from within
".nbf5.gf.gen invoke "
invoked from within
".nbf5.gf.gen instate {pressed !disabled} { .nbf5.gf.gen state !pressed; .nbf5.gf.gen invoke } "
(command bound to event)"


Any ide:as ?

Regards MaistroX

[r0lZ]

Damn! Again an invalid character in the string returned by the DOS command DIR.

Can you please open a command prompt, then CD to your HDD containing the project, and type DIR.
Then, copy the output here. I'll try to understand what's wrong.

In the meantime, you can simply open the console (with File -> Show Console), and paste this code in the console:

proc GetFreeDiscSpace {} {return 1000000000000}

Then press Enter. You can now close the console if you wish.

That will disable the check for the available disc space, and you should be able to generate the project without problem. But be sure to verify if you have enough disc space manually!

And don't forget to apply the same trick if you close BD3D2MK3D and re-open it. The change is not permanent.

[Airmiles]

r0IZ, I use CRF 16 all the time, but with very different results in file size. Avatar ended up with 23,85GB, but Lion King ended up with only 5,14GB. With exactly the same settings. Now I know LK is 1:29h and Avatar is 2:42h, but even if you double the GB of LK, you still don't get to 23 GB, so what am I missing here?

I have 6TB of LaCie storage, so I am more worried about the quality of the LK file, then I am about the space that Avatar takes up, but some more explanation would help my future rip decisions.

Hope you can enlighten me on this.