Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph

[r0lZ]

Not sure why there are 2 additional frames. Anyway, the trim command should not be necessary, since you have forced 500 frames in the ssifSource command. (Perhaps you need to specify the last frame number (499) instead of the number of frames, but I don't think so.)

The crop lines are wrong. Currently, they are identical, so the left and right images will also be identical. No 3D anyway!
Remember that the input video is made of two full-resolution images stacked vertically (normally, with the left eye view on top). So, to extract the left image without the black borders, you should use:
left =Crop(0,132,0,(1080+132)*-1)
and, for the right image:
right=Crop(0,1080+132,0,-132)

[EDIT] I haven't read carefully your post. There are 72 additional frames, not 2. Obviously, it's because my GUI adds them automatically, as you have guessed.

[mini-moose]

Not sure why there are 2 additional frames. Anyway, the trim command should not be necessary, since you have forced 500 frames in the ssifSource command. (Perhaps you need to specify the last frame number (499) instead of the number of frames, but I don't think so.)

The crop lines are wrong. Currently, they are identical, so the left and right images will also be identical. No 3D anyway!
Remember that the input video is made of two full-resolution images stacked vertically (normally, with the left eye view on top). So, to extract the left image without the black borders, you should use:
left =Crop(0,132,0,(1080+132)*-1)
and, for the right image:
right=Crop(0,1080+132,0,-132)

ok, I know some avisynth but apparently not enough to figure out that crop cmd. now it's fine!
the extra 72 frames are evidently cause I didn't disable the "Add 3 seconds of black at the end" bit from your original script. what are those 3 seconds for by the way?

[r0lZ]

Well, I've added them just because there are many DB movies that stop abruptly (even sometines before the end of the audio stream), and anyway I don't like to see the GUI of my TV immediately after the end of the movie. Black frames are very well compacted, so these 3 seconds cost almost nothing in term of disc space, so I've added them anyway, even if they are not always necessary. You can remove them if you wish.

Note that the 3rd and 4th arguments of the crop commands can be positive or negative. When you specify a negative number, the size is computed from the right or bottom edge of the image. Positive arguments do the crop relatively to the left or top side. So, the following commands should work also:
left =Crop(0,132,0,1080 - 132)
right=Crop(0,1080+132,0,1080*2 - 132)

[mini-moose]

Well, I've added them just because there are many DB movies that stop abruptly (even sometines before the end of the audio stream), and anyway I don't like to see the GUI of my TV immediately after the end of the movie. Black frames are very well compacted, so these 3 seconds cost almost nothing in term of disc space, so I've added them anyway, even if they are not always necessary. You can remove them if you wish.

Note that the 3rd and 4th arguments of the crop commands can be positive or negative. When you specify a negative number, the size is computed from the right or bottom edge of the image. Positive arguments do the crop relatively to the left or top side. So, the following commands should work also:
left =Crop(0,132,0,1080 - 132)
right=Crop(0,1080+132,0,1080*2 - 132)

ok, gotcha :) thanks.
How would srt subs work with 3d encodes? regularly? they are a lot of work to do yourself but a lot of them are made available on the web by dedicated translators. I personally prefer vobsubs but the issue is that some players would not read them from mkv.

[r0lZ]

You can mux the srt files in the MKV file, or leave them alone. In the second case, they must have the same file name than the movie (although some players accept an additional language extension).

My Samsung TV recognizes them and displays them in 3D almost well (but only if they are outside the container). The problem is that it is not possible to force my TV to display them with a 3D depth effect, and they appear to be always on the surface of the screen. When they are displayed over objects that are "outside the screen", they are impossible to read, the display is horrible, and it's a torture for the mind. It's why I have added the option to hardcode the subtitles on the video, with a configurable 3D depth effect.

Note that you can also hardcode srt files. Just change the VobSub command to TextSub and the file name. Of course, given the lack of coordinates values in the srt format, they will be always displayed at the default position, but the 3D effect will be preserved.

Note also that you cannot use an external player to generate the video stream (for example a multimedia HDD connected to the 3D TV via HDMI), as it doesn't know that the video is in 3D, and it displays the non-hardcoded subtitles once, at the bottom centre of the 3D image. The TV then combines the images to show them in 3D, but the subtitles are completely messed up. It should be possible to create 3D SUB/IDX files, with the subtitles already scaled, duplicated and placed at the correct positions for the two images, but currently, there is no app able to transcode BD SUPs to 3D SUB/IDX. A solution may come soon with BDSup2Sub++...

[r0lZ]

Here is the new version of BD3D2AVS. It fixes the x264.exe not found problem, and I've added an item in the Help menu to download the Microsoft Visual C++ 2008 Redistributable Package, as well as a message displayed only the first time the program is run telling that the package is required. (If you want to see it, delete the BD3D2AVS.cfg file.) I have also updated the "requirements" section of the doc.

Unfortunately, I haven't found a reliable way to check if the package is already installed, and more strangely, I have tried to uninstall it (with success), but ldecod has continued to work as expected. (Perhaps because I have the x64 version installed, or because there are already two M$ updates for the 32-bit package, that I have not uninstalled.) Anyway, the first-time dialogue should be sufficient.


# v0.4 (July 8, 2012)
# - Fixed: the "set path" command in _ENCODE.cmd was wrong.
# - Added a Help menu item to download the Microsoft Visual C++ 2008 Redistributable Package, necessary for ldecod.exe.
# - Added message to warn the user that the vcredist 2008 package is required the first time the program is run.


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

The next update will probably use BDSup2Sub++.exe instead of the old java version of BDSup2Sub, as it has now the possibility to shift the subs to the left or right, and it will be much simple and rapid to use that new CLI option than the current method to hardcode the subtitles with a 3D depth effect, requiring to play with Crop and Stack commands in the AVS script. However, the current version of BDSup2Sub++ is still a somewhat unstable beta, and I will wait for v1.0.

BDSup2Sub++ v1.1 should add the possibility to generate true 3D subs, so that it should be possible to hardcode them in one shot, or to include them in the container, for a better compatibility with multimedia HDDs. But that's for later...

[mini-moose]

You can mux the srt files in the MKV file, or leave them alone. In the second case, they must have the same file name than the movie (although some players accept an additional language extension).

My Samsung TV recognizes them and displays them in 3D almost well (but only if they are outside the container). The problem is that it is not possible to force my TV to display them with a 3D depth effect, and they appear to be always on the surface of the screen. When they are displayed over objects that are "outside the screen", they are impossible to read, the display is horrible, and it's a torture for the mind. It's why I have added the option to hardcode the subtitles on the video, with a configurable 3D depth effect.

Note that you can also hardcode srt files. Just change the VobSub command to TextSub and the file name. Of course, given the lack of coordinates values in the srt format, they will be always displayed at the default position, but the 3D effect will be preserved.

Note also that you cannot use an external player to generate the video stream (for example a multimedia HDD connected to the 3D TV via HDMI), as it doesn't know that the video is in 3D, and it displays the non-hardcoded subtitles once, at the bottom centre of the 3D image. The TV then combines the images to show them in 3D, but the subtitles are completely messed up. It should be possible to create 3D SUB/IDX files, with the subtitles already scaled, duplicated and placed at the correct positions for the two images, but currently, there is no app able to transcode BD SUPs to 3D SUB/IDX. A solution may come soon with BDSup2Sub++...

thanks a lot for all the valuable info and infinite patience.
Hardcodding is something I don't like as it's set in stone so I guess vobsubs exterrnal or internal are the best way at the moment.
I was certain I saw some app that claims to be purposed for 3d subs but I can't find it now. As you say there is non than I would assume that even if there is one that claims to be it must not be very good :)

[r0lZ]

Hardcodding is something I don't like as it's set in stone so I guess vobsubs exterrnal or internal are the best way at the moment.
I fully agree, but since there is no good solution for my TV, I have to hardcode the subtitles in some cases. I'm sure I'm not the only one needing that.

I was certain I saw some app that claims to be purposed for 3d subs but I can't find it now. As you say there is non than I would assume that even if there is one that claims to be it must not be very good :)
Yes, there is a "3D Subtitle Editor" referenced by frencher here (http://forum.doom9.org/showthread.php?p=1574724#post1574724), but it can only generate SUB/IDX files from SRT text files. Since my app uses the original BD SUPs as input, and because the subtitle editor has no CLI option, I can't use it for BD2D2AVS. (However, you can try it if you have a srt file as input. It has also the possibility to define the 3D depth effect.)

[frencher]

3DBD's Free - v0.0.0.0005 (2012-07-09) - See my signature

- FIXED - All the problems of false positives with "G_ComboBox*.dll" New Plugin

Do you still have the problem with "libflac.dll" or other problem ?

[mini-moose]

Here is the new version of BD3D2AVS.

nice:)

a few more things I wanted to mention:

1) If I do not choose any streams to extract (i,e disable the DTS extraction) I think you said the program will use xporter.exe. The popup window goes immediately goes to "not responding" mode but it does work and finishes + files are created. It may confuse some people into thinking the process has died if they don't have the patience to wait and see it actually didn't.
Still using the same test subject it reports an extra frame over eac3to (165210 vs 165211 with xporter), not really a huge issue.

2) I think it's worth adding a --level switch. specifically set it to level 4.1. high@level 4.1 is the bluray standard and will control the ref setting. without it your encode will use whatever ref the preset uses and may cause some compatibility issues. Level 4.1 ensures it doesn't go over the compatible ref setting (e.g ref 4 for 1:1.78).

3) Resize - set to bicubic by default. That's a bit of a simple resizer for high res sources. I'm guessing it's faster than the sharper ones which might be the reason it's set as default as many users would like a faster job.

4) --tune - I think that should maybe also have a "none" option.

5) It would be great if there was a crop option that can insert the correct crop values into the AVS. I know you can't support a crop tool window to allow users to check the crop but perhaps an "advanced" option can be added for the people who know how to get the values using some external program. Obviously that would also require and "advanced" option to change the resize. maybe too much hassle but it's something that can be useful.

[r0lZ]

1) I know, but I can't avoid that problem. It's because xport.exe doesn't have a "GUI mode" that prints the progress % numbers to stdout. So, when the GUI launches the command, it has to wait until it finishes the job, and cannot refresh the GUI. Windows is the real culprit, as it "thinks" that the program is dead when it is not responding, but in fact, it is waiting for a command-line tool to exit. (I know that that Windows limitation can be avoided by creating another process to control just the refresh of the GUI and reply to Windows, but it's not possible to implement it with Tcl/Tk.)

2) As far as I know, the level is auto-detected, and should be level 4.1 since the input is a BD, unless you overwrite it with another option. But I'm not a specialist in h264 encoding, and I can certainly add that option in the next version. In the meantime, you can specify the level in the additional options.

3) Don't forget that the resize divides the width or height of the original picture by exactly 2. Complex (and slow) resizes are necessary when the resize is also complex, but when exactly two pixels are merged into a single pixel, simple resizes such as the Bicubic or even the Bilinear resize are usually sufficient. I've picked the Bicubic one for the default because it is fast and IMO largely sufficient. Of course, if I'm wrong, I can change it, but I don't want to enter in an infinite debate about the respective qualities of the different resize algorithms. Anyway, you can change it easily enough, and it's an option that is saved with your preferences.

4) As far as I know, there is no "none" preset for tune. I suppose that if it is set to "none" in the GUI, I should simply remove the --tune option from the command. Right?

[mini-moose]

1) I know, but I can't avoid that problem. It's because xport.exe doesn't have a "GUI mode" that prints the progress % numbers to stdout. So, when the GUI launches the command, it has to wait until it finishes the job, and cannot refresh the GUI. Windows is the real culprit, as it "thinks" that the program is dead when it is not responding, but in fact, it is waiting for a command-line tool to exit. (I know that that Windows limitation can be avoided by creating another process to control just the refresh of the GUI and reply to Windows, but it's not possible to implement it with Tcl/Tk.)


ah i see.

2) As far as I know, the level is auto-detected, and should be level 4.1 since the input is a BD, unless you overwrite it with another option. But I'm not a specialist in h264 encoding, and I can certainly add that option in the next version. In the meantime, you can specify the level in the additional options.

I did a clip test to mkv so I can mediainfo the header settings and it doesn't. You have to use the level switch for that.

cmd used:
x264.exe --preset slower --tune film --profile high --crf 19
medainfo:
Format profile : High@L5.0
settings: ref=8 / me=umh / subme=9

same cmd with --level 4.1 added:
Format profile : High@L4.1
ref=4 / / me=umh / subme=9


3) Don't forget that the resize divides the width or height of the original picture by exactly 2. Complex (and slow) resizes are necessary when the resize is also complex, but when exactly two pixels are merged into a single pixel, simple resizes such as the Bicubic or even the Bilinear resize are usually sufficient. I've picked the Bicubic one for the default because it is fast and IMO largely sufficient. Of course, if I'm wrong, I can change it, but I don't want to enter in an infinite debate about the respective qualities of the different resize algorithms. Anyway, you can change it easily enough, and it's an option that is saved with your preferences.

fair enough. as I said I don't have experience with 3D encodes yet so most of my assumptions comes from standard ones.

4) As far as I know, there is no "none" preset for tune. I suppose that if it is set to "none" in the GUI, I should simply remove the --tune option from the command. Right?
exactly. reason I'm suggesting it is that some of the tune options may confuse people who just use defaults. for example using film instead of animation when the movie is animation. Grain I noticed boosts the file size considerably and should prob only be used for movies with high grain levels. ssim and psnr are not self-explanatory from their name and mostly change the aq mode setting + disable psy tuning.

[r0lZ]

5) It would be great if there was a crop option that can insert the correct crop values into the AVS. I know you can't support a crop tool window to allow users to check the crop but perhaps an "advanced" option can be added for the people who know how to get the values using some external program. Obviously that would also require and "advanced" option to change the resize. maybe too much hassle but it's something that can be useful.
Well, the script is already very complex (especially when it has to hardcode subs). Furthermore, if the video is cropped, I would have to adapt the position of the subtitles, as they will be positioned by default at a wrong position. (It's impossible with the current java version of BDSup2Sub, although the new C++ version should have an option to move the subs vertically.) Also, as I said above, most 3D TVs require true 16:9 as input, so the black bars are necessary in many cases, and I don't want to encourage newbies to crop their videos, as this tends to produce files with wrong aspect ratios, difficult to view with a player that has not enough options to fix the AR manually or automatically.
So, sorry, but I don't think I will implement that possibility.

[r0lZ]

I'm currently working in the implementation of the "none" preset and the --level switch.

BTW, according to the x264 doc, permissible levels are 1 1b 1.1 1.2 1.3 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 5 and 5.1
But "Level 4.1 is often considered the highest level you can rely on desktop consumer hardware to support. Blu-ray Discs only support level 4.1, and many non-mobile devices like the Xbox 360 specify level 4.1 as the highest they officially support. Mobile devices like the iPhone/Android are a totally different story."
Do you think I must support the whole list, or just from 1 to 4.1?
4.1 will be the default anyway. (I will add also a pseudo-level "auto" to let x264 decide which level to use.)

Also, according to the doc, "specifying the level does not automatically set the --vbv-maxrate or --vbv-bufsize, however it will warn if the level specific properties are exceeded." Does it mean that I have to add the --vbv-maxrate and --vbv-bufsize options according to the selected level? If it's the case, do you know where I can find the values for these parameters, for each level?

(doc source (http://mewiki.project357.com/wiki/X264_Settings#level))

[mini-moose]

Well, the script is already very complex (especially when it has to hardcode subs). Furthermore, if the video is cropped, I would have to adapt the position of the subtitles, as they will be positioned by default at a wrong position. (It's impossible with the current java version of BDSup2Sub, although the new C++ version should have an option to move the subs vertically.) Also, as I said above, most 3D TVs require true 16:9 as input, so the black bars are necessary in many cases, and I don't want to encourage newbies to crop their videos, as this tends to produce files with wrong aspect ratios, difficult to view with a player that has not enough options to fix the AR manually or automatically.
So, sorry, but I don't think I will implement that possibility.

understood :) thanks.

[mini-moose]

I'm currently working in the implementation of the "none" preset and the --level switch.

BTW, according to the x264 doc, permissible levels are 1 1b 1.1 1.2 1.3 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 5 and 5.1
But "Level 4.1 is often considered the highest level you can rely on desktop consumer hardware to support. Blu-ray Discs only support level 4.1, and many non-mobile devices like the Xbox 360 specify level 4.1 as the highest they officially support. Mobile devices like the iPhone/Android are a totally different story."
Do you think I must support the whole list, or just from 1 to 4.1?
4.1 will be the default anyway. (I will add also a pseudo-level "auto" to let x264 decide which level to use.)

from what you quoted level 4.1 is the one most likely to not present compatibility issues on most devices, so I think further levels are not required. If someone wants higher/lower levels than he is either has advanced knowledge most likely and can manually edit the cmd or a newbie who thinks setting to the highest levels will result in a super-great encode.
As for mobile phones...anyone who watches high res stuff on a 6" display should be spanked :) so I wouldn't even consider them. I believe mobile phones are more suited for mp4 than mkv anyway.

Also, according to the doc, "specifying the level does not automatically set the --vbv-maxrate or --vbv-bufsize, however it will warn if the level specific properties are exceeded." Does it mean that I have to add the --vbv-maxrate and --vbv-bufsize options according to the selected level? If it's the case, do you know where I can find the values for these parameters, for each level?

(doc source (http://mewiki.project357.com/wiki/X264_Settings#level))

sorry, I don't have any useful input on that. I never used vbv switches nor have I ever gotten warnings about them. I know they are defaults on megui. I'll have a look if I can find such info. crf does have an unpredictable nature as it doesn't really have bitrate limitations per se.

edit: megui has a "target playback device" on the x264 configuation dialog box. you can try the devices there and see how the levels/profiles change accordingly. for example if you choose iphone it changes to baseline/level 3
.

[r0lZ]

According to this site (https://sites.google.com/site/x264bluray/home/1080i-p), BD compliant x264 encodes need these parameters:
--bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
So, I think I will add a checkbox "BD compatible", and force these options if it is ticked.

The options --bitrate XXXXX --preset veryslow --tune film --pass 1 (then 2) are also specified in the article, but I suppose that they are used only to control the quality of the encoding, and not really necessary for BD compliance.

I will not force any option if the BD compatible checkbutton is not ticked. After all, the advanced user can specify what he wants in the additional options box.

BTW, I wonder if that "BD compatible" checkbox is really necessary. Users who have a BD-3D and want to convert it to SBS or TB format do it to have a standalone MKV file, not to create a new BD. But IMO that option can be useful anyway. What do you think?

[mini-moose]

According to this site (https://sites.google.com/site/x264bluray/home/1080i-p), BD compliant x264 encodes need these parameters:
--bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
So, I think I will add a checkbox "BD compatible", and force these options if it is ticked.

The options --bitrate XXXXX --preset veryslow --tune film --pass 1 (then 2) are also specified in the article, but I suppose that they are used only to control the quality of the encoding, and not really necessary for BD compliance.

I will not force any option if the BD compatible checkbutton is not ticked. After all, the advanced user can specify what he wants in the additional options box.

BTW, I wonder if that "BD compatible" checkbox is really necessary. Users who have a BD-3D and want to convert it to SBS or TB format do it to have a standalone MKV file, not to create a new BD. But IMO that option can be useful anyway. What do you think?

I don't think any encode will go over 40mbit tbh and if it does it means the movie is very grainy or something. if your mkv turns out to be a the size of a blu-ray you might as well just use the blu-ray itself :) I suppose it can't hurt to have it but I doubt it's really necessary. Maybe someone else on the forum has input on that matter.
I rechecked megui and the vbv set to are set to 0 by default. I thought they aren't. maybe some players/gfxs have limitations as to what buffers/bitrates they can handle.

[r0lZ]

Hum, I've added the BD compatible checkbox anyway, and when it is ticked, I will force the options above. I agree that the maxrate will probably never exceed 40000 (although it's possible in specific scenes, for a short time), but it doesn't hurt to specify it anyway, and the other options are probably necessary.

Note that when using the BD compatible options, the user specified Level will not be taken into account (since the level is forced to 4.1 anyway), but also the additional parameters field will be ignored, as it is difficult to ensure that the user has not typed already a parameter incompatible with the BD specs, or a parameter that is already forced. The ignored fields will be disabled in the GUI to reflect that fact.

[mini-moose]

According to this site (https://sites.google.com/site/x264bluray/home/1080i-p),

have a look here:

http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#VBV_Encoding

[r0lZ]

Yeah, it's the site I've found immediately. It is valuable, but apparently, not complete. For example, I've found this thread (http://forum.doom9.org/showthread.php?t=154533). Seems that some options depend of the resolution. :(

[mini-moose]

Yeah, it's the site I've found immediately. It is valuable, but apparently, not complete. For example, I've found this thread (http://forum.doom9.org/showthread.php?t=154533). Seems that some options depend of the resolution. :(

yes but this one is more for blu-ray compliants. I think the main use for vbv is how you play your files. if you do it local than you shouldn't have any limitations. if you stream it then it would depend on you bw. for example if you stream it on a local network that is 100mbit/1gbit it should be able to handle blu-ray bitrates easily as those are around 40mbit max.

[r0lZ]

OK, the new version is ready. (I've also fixed a bug introduced in v0.4. The dialogue about the necessity to install vcredist was displayed each time the program starts.)


# v0.5 (July 9, 2012)
# - Bug introduced in v0.4: the message about the vcredist 2008 package was displayed each time the program is run.
# - Added the x264 Preset "none" to disable the --preset option in the x264 command. None is now the default.
# - Added the x264 Level option (by default 4.1). "auto" disables the --level option.
# - Added the "BD compatible" checkbox to overwrite the Preset, Level and user options with options suitable for blu-ray authoring.


As usual, the download is here: http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2AVS.7z

I'm not sure the options to encode in BD compatible mode are right. Maybe some of them are not necessary, or there are missing ones. Anyway, that will be easy to modify later.
If someone can help with that subject, that will be much appreciated.

[mini-moose]

OK, the new version is ready. (I've also fixed a bug introduced in v0.4. The dialogue about the necessity to install vcredist was displayed each time the program starts.)


# v0.5 (July 9, 2012)
# - Added the x264 Preset "none" to disable the --preset option in the x264 command. None is now the default.


great :)

you mean --tune not --preset I assume?

[r0lZ]

Yes, of course. It's a bug in the version history! ;)

[mini-moose]

Yes, of course. It's a bug in the version history! ;)

hehe.

I have another question.
on the mux 3d option you have this part:

0:3D side-by-side (left first)
--stereo-mode

is this flag necessary? if I use mkvmerge gui with this flag it will mux the final result into a .mk3d file not .mkv (yours is set to be .mkv). I had a friend test a 3d encode, one muxed without this flag and one with and he said both play the same way.
I'm sure that flag doesn't harm anything, I'm just interested to know if you know it makes any difference.

From what I read on mkvmerge it appears to be an option mostly meant for 2 separate video files (left/right) and not a ready made in one file encode:
"Stereo mode: There's a technology of providing pseudo three dimensional images by playing back two video tracks that have been filmed from slightly different positions simultaneously. Each eye only sees one of those tracks. This is called stereo mode. Most users should leave this empty. "

and another thing regarding mux:
--default-duration
0:24000/1001p

is that flag generated according to the movie fps or it's always set to that? As some movies can be 24fps/25fp/29.970fps too. Basically your avs already ensures the correct fps is used using the AssumeFPS switch so there's no real need to specify it in mkvmerge as well. It doesn't do any harm either as long as it takes the switch from the source and it isn't defaulted which I assume it isn't.

[r0lZ]

Stereo mode: It's not a simple flag, but a setting for the MKV container. It is supposed to be used by the TVs or 3D players to switch automatically to the right stereo mode. Very few TVs take that setting into account, but it doesn't hurt, and it's also an info easy to examine to know how the stereo images are encoded. My GUI creates only SBS and TB (left eye first in both cases) and sets the correct mode, but the MKV container has a bunch of other modes as well (including the 2 separate video files). IMO, if nobody set that setting correctly, the 3D TV makers will never try to respect it.
I think however that the .mk3d extension is not as useful, and is not recognised by the 3D TVs either, so I've decided to use the standard .mkv extension. It is easy to change it if you wish.

The default duration is taken from the information returned by eac3to (when the streams of the current title are retrieved by the GUI), and should be the real frame rate of the input video. According to the mkvmerge doc, it is usually useless to specify it except for h264 streams, because the frame rate is not included in the stream itself. MkvMerge GUI warns you if you try to mux a h264 stream without specifying it, and sets it by default to 25fps. (Things may have changed in recent implementations of h264, as I have not seen that warning recently, but I remember I've turned off that message.) Anyway, specifying the correct frame rate should not hurt, even if it is not needed.
(However, I have no way to be sure that the video is really progressive and not interlaced. The frame rate should not change, but the "p" in the syntax may be wrong in some cases. I think it is used by the mkvmerge parser to determine the format of the --default-duration parameter, as you can specify the frame rate or the duration between two frames in ms or ns. The "p" should be ignored after the parsing, but I'm not totally sure.)

[mini-moose]

Stereo mode: It's not a simple flag, but a setting for the MKV container. It is supposed to be used by the TVs or 3D players to switch automatically to the right stereo mode. Very few TVs take that setting into account, but it doesn't hurt, and it's also an info easy to examine to know how the stereo images are encoded. My GUI creates only SBS and TB (left eye first in both cases) and sets the correct mode, but the MKV container has a bunch of other modes as well (including the 2 separate video files). IMO, if nobody set that setting correctly, the 3D TV makers will never try to respect it.
I think however that the .mk3d extension is not as useful, and is not recognised by the 3D TVs either, so I've decided to use the standard .mkv extension. It is easy to change it if you wish.
I see. I'm sure it doesn't hurt. My thought was that stereo mode was only really effective when you actually use 2 video streams (right and left), when it's a ready-made 1 video it seems not as effective unless as you say it helps some tvs/players.
Have you tried without the flag and witnessed it "confused" the player or tv? Sorry if I seem to be picking at a negligible subject, just curious.
The default duration is taken from the information returned by eac3to (when the streams of the current title are retrieved by the GUI), and should be the real frame rate of the input video. According to the mkvmerge doc, it is usually useless to specify it except for h264 streams, because the frame rate is not included in the stream itself. MkvMerge GUI warns you if you try to mux a h264 stream without specifying it, and sets it by default to 25fps. (Things may have changed in recent implementations of h264, as I have not seen that warning recently, but I remember I've turned off that message.) Anyway, specifying the correct frame rate should not hurt, even if it is not needed.
(However, I have no way to be sure that the video is really progressive and not interlaced. The frame rate should not change, but the "p" in the syntax may be wrong in some cases. I think it is used by the mkvmerge parser to determine the format of the --default-duration parameter, as you can specify the frame rate or the duration between two frames in ms or ns. The "p" should be ignored after the parsing, but I'm not totally sure.)
ah I see, it's cause it's .h264 and may lack header info being a raw format.
so, when you say it uses "information returned by eac3to" you mean a line such as this? :

M2TS, 2 video tracks, 5 audio tracks, 5 subtitle tracks, 1:52:31, 24p /1.001

[r0lZ]

Have you tried without the flag and witnessed it "confused" the player or tv? Sorry if I seem to be picking at a negligible subject, just curious.
My TV ignores the stereo mode setting completely, and is therefore never confused, with or without that setting. Of course, a TV or player that takes it into account can be confused if it is wrong, but BD3D2AVS sets it correctly. :)

ah I see, it's cause it's .h264 and may lack header info being a raw format.
Yes, although some other raw formats have that info.

so, when you say it uses "information returned by eac3to" you mean a line such as this? :

M2TS, 2 video tracks, 5 audio tracks, 5 subtitle tracks, 1:52:31, 24p /1.001
Not exactly. Have a look at the first tab of the GUI. It shows the info returned by eac3to.

The bottom listview shows the two video streams, as returned by eac3to, like this:
- h264/AVC (left eye), 1080p, fps: 24 /1.001 (16:9)
- h264/AVC (right eye), 1080p, fps: 24 /1.001 (16:9)
The height of the video, the frame rate and the aspect ratio are retrieved from these lines.
Audio and subtitle streams are processed the same way, to retrieve the stream type and language.

The MPLS or M2TS file to demux and use for the encoding, and the movie duration (only used in comments and for the intro clip) are retrieved from the selected line in the upper pane.

Note that the stream numbers are retrieved from the bottom pane also, but it is necessary to do the "Get Stream Info" pass to show them. Subtitles streams are also visible only after that pass. It's why the GUI needs to do it when you select another tab (unless you did it manually in the first tab).

[mini-moose]

My TV ignores the stereo mode setting completely, and is therefore never confused, with or without that setting. Of course, a TV or player that takes it into account can be confused if it is wrong, but BD3D2AVS sets it correctly. :)


Not exactly. Have a look at the first tab of the GUI. In the bottom listview, it shows the two video streams, as returned by eac3to, like this:
- h264/AVC (left eye), 1080p, fps: 24 /1.001 (16:9)
- h264/AVC (right eye), 1080p, fps: 24 /1.001 (16:9)

The height of the video, the frame rate and the aspect ratio are retrieved from these lines.

Audio and subtitle streams are processed the same way, to retrieve the stream type and language.

The MPLS or M2TS file to demux and use for the encoding, and the movie duration (only used in comments and for the intro clip) are retrieved from the selected line in the upper pane.

ok. I don't have any to test on but what happens if it would say
24p, 50i or 60i? Your tool knows to convert those to 24/1, 25/1, 30/1.001 ?
I'm sure it does and I apologize if I seem like I'm doubting it, just want to be sure as I have nothing to test with.

[r0lZ]

It will never show the i or p. The frame rate is either a fraction (such as 24 /1.001) or an integer (such as 25). The GUI retrieves everything after the "fps:" and before the "(" of the aspect ratio, and strips the spaces. (It converts the fractions to a floating point number internally, mainly for the fps option of the intro clip, as all tools used by the GUI accept the fractions.)

For the conversion of interlaced material, honestly, I don't know. I would be very surprised if you can find a 3D BD encoded in interlaced mode. In that case, I suppose it will still show, say, 25 fps, as fps means "frames per second", not "fields per second".

[mini-moose]

It will never show the i or p. The frame rate is either a fraction (such as 24 /1.001) or an integer (such as 25). The GUI retrieves everything after the "fps:" and before the "(" of the aspect ratio, and strips the spaces. (It converts the fractions to a floating point number internally, mainly for the fps option of the intro clip, as all tools used by the GUI accept the fractions.)

For the conversion of interlaced material, honestly, I don't know. I would be very surprised if you can find a 3D BD encoded in interlaced mode. In that case, I suppose it will still show, say, 25 fps, as fps means "frames per second", not "fields per second".

hmm ok. Like I said I don't have a non 23.976 to test so I can just look how it is on a a standard 25fps bluray - this is how it looks on one :

2: h264/AVC, 1080i50 (16:9)

on the 3d one I tested it shows:

2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)

50i doesn't mean the video is actually interlaced. pal is always identified as interlaced. In some cases it is in many cases not, i.e the fields pattern is progressive: 1,1,2,2,3,3 and not 1+2,3+4,5+6 etc.

[r0lZ]

I agree. PAL and NTSC are by nature always interlaced, as they are always made of fields, even if the two fields have been shot at the same time, giving the impression that the video is not interlaced. But again, I doubt you can find a 3D movie encoded in PAL or NTSC. (I've seen several NTSC DVD in 3D, where each field contains one of the two eye views, but it's now a 3D format completely abandoned. Anyway, the quality of the 720x240 pictures is terrible!)

I may have to take the "i" at the end of the resolution into account. Currently, I don't do it, as I have supposed that a 3D BD is always progressive. But if the fps returned by eac3to for interlaced material is the "fields per second", as in your example, the frame rate of my GUI may be wrong. If you can find an interlaced 3D movie, please let me know...

[mini-moose]

I agree. PAL and NTSC are by nature always interlaced, as they are always made of fields, even if the two fields have been shot at the same time, giving the impression that the video is not interlaced. But again, I doubt you can find a 3D movie encoded in PAL or NTSC. (I've seen several NTSC DVD in 3D, where each field contains one of the two eye views, but it's now a 3D format completely abandoned. Anyway, the quality of the 720x240 pictures is terrible!)

I may have to take the "i" at the end of the resolution into account. Currently, I don't do it, as I have supposed that a 3D BD is always progressive. But if the fps returned by eac3to for interlaced material is the "fields per second", as in your example, the frame rate of my GUI may be wrong. If you can find an interlaced 3D movie, please let me know...

It's possible there aren't any PAL fps 3D. I would need to find such blu-rays and check to make sure. Flying Monsters with David Attenborough appears to be 23.976 so you might be right.
However I think there can be 24p 3D movies but I'm unsure how the fps will be displayed on eac3to. it's possible it will show 24p and not 24/1.

[r0lZ]

Just tried with a NTSC DVD, and here is that it shows:
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags

And for a PAL DVD:
1: MPEG2, 576p25 (16:9)

So, at least for DVDs, it shows them always as being progressive (even for NTSC!) and it displays the frames per seconds.

[mini-moose]

Just tried with a NTSC DVD, and here is that it shows:
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags

And for a PAL DVD:
1: MPEG2, 576p25 (16:9)

So, at least for DVDs, it shows them always as being progressive (even for NTSC!) and it displays the frames per seconds.

yes but you need to try one that is 24p not 24/1.001. i.e 24 fps not 23.976. I will see if I have such a bluray around.

edit:
ok found one:

2: h264/AVC, 1080p24 (16:9)

24fps sources are the ones eac3to refers to as:

v02 The video framerate is correct, but rather unusual.

I haven't seen 24p 3D discs but since it's progressive it's not out of the question there are such (or will be).

[r0lZ]

it's possible it will show 24p and not 24/1.Anyway, that doesn't matter for my GUI. It can handle the fractions or single integers as well.

BTW, I forgot to say that the output of eac3to is somewhat processed by the program before it is displayed in the GUI. That explain the little differences between the original output and what you see in the GUI. In my GUI, the frame rate is always displayed after "fps:" and before "(16:9)". In case of a single "24", it will show 24.
However, for 50i, it will show "50" and assume (wrongly) 50 frames per second.

[mini-moose]

ok, new subject :)
I ran a test encode overnight. It did not perform the mux at the end but I blamed it on the possible fact that I've tinkered with the original files your tool has generated (I also used an older version of it, v3 I think).
So what I've done is used the latest version to run through the routine and create all the files again and then copied the .h264 to the new project dir.

first off, the console reports this:

WARNING:

BDSup2Sub "9 Subtitle (PGS), English, forced captions only.sub"
ERROR: No forced subtitles found.There was 1 error
BDSup2Sub "10 Subtitle (PGS), English, forced captions only.sub"
ERROR: No forced subtitles found.There was 1 error

() 1 %

understandable as there were no forced english subs to be found (source has a separate sub steam for regular english subs and SDH ones). The 1 % I'm not sure what it means. Def not an issue just that some might think it's stuck in some way as it doesn't progress over 1%, however the process seems to be all done (avs,cmds,audios,subs,sups are all created).

Next thing I tried is running the _MUX_3D.cmd directly. double clicking it from location flashed the cmd window for a brief second and closed so I cd'd into the directory and ran it through console:

C:\\BD3D2AVS\xx2\00799_mpls>_MUX_3D.cmd

that returned nothing either:

C:\\BD3D2AVS\xx2\00799_mpls>REM "C:\\BD3D2AVS\toolset\mkvmerge.exe" @_MUX_3D_OPTIONS.txt | "C:\\BD3D2AVS\toolset\tee.exe" "00799_mpls.mkvmerge.log"
C:\\BD3D2AVS\xx2\00799_mpls>

maybe I'm doing something wrong OR this process only runs as part of the encode cmd routine?

one more thing..what is the function (or when is the no_delay used over the regular one) of chapters_no_delay.txt vs the regular chapters.txt file? from what I can see the difference is that the no_delay one has the timeline repeated without the miliseconds:

CHAPTER02=00:10:38.137
CHAPTER02NAME=

no delay:

CHAPTER02=00:10:38.137
CHAPTER02NAME=00:10:38

edit:

a suggestion regarding mkvmerge - disable header removal compression for audio and video tracks by default. I think the cmd flag is "--compression" "0:none".
header compression is known to cause issues for some players when enabled.

[mini-moose]

Anyway, that doesn't matter for my GUI. It can handle the fractions or single integers as well.

BTW, I forgot to say that the output of eac3to is somewhat processed by the program before it is displayed in the GUI. That explain the little differences between the original output and what you see in the GUI. In my GUI, the frame rate is always displayed after "fps:" and before "(16:9)". In case of a single "24", it will show 24.
However, for 50i, it will show "50" and assume (wrongly) 50 frames per second.

ok great :) Till/if a 50i 3D will show up I guess it's covered.

[r0lZ]

WARNING:

BDSup2Sub "9 Subtitle (PGS), English, forced captions only.sub"
ERROR: No forced subtitles found.There was 1 error
BDSup2Sub "10 Subtitle (PGS), English, forced captions only.sub"
ERROR: No forced subtitles found.There was 1 error

() 1 %

understandable as there were no forced english subs to be found (source has a separate sub steam for regular english subs and SDH ones).

The GUI adds the "forced only" entries in the second tab to allow you to mux (or hardcode) a subpic stream containing the forced subs only. Unfortunately, it is not possible to know if a specific subpic stream has forced subtitles without demuxing it and processing it with BDSup2Sub. So, the GUI has to add them anyway, and it's your responsibility to select them or not. In case one of these "only forced" stream has been selected, the complete SUP stream is demuxed (including the non-forced subs), and processed with BDSup2Sub to extract only the forced subs. It BDSup2Sub cannot find any forced sub, it issues the error that is shown in the console. The GUI sees that message (and that the output SUB/IDX files have not been created) and assumes that it's normal. The missing forced subs are just ignored, and of course, not included in the mux options (or not hardcoded).

The 1 % I'm not sure what it means.
The console is the regular Tcl/Tk console. It's not simply a log window. Like with the DOS command prompt, you can type Tcl/Tk command in that window. The "() 1 %" is just the prompt that indicates that the console is ready to receive input. If you type, for example, "test", it will reply "invalid command name "test"" and the prompt will be changed to "() 2 %", indicating that it is waiting for your second command.
You should never need to type anything in the console, but it is handy to display the output of the CLI commands and error messages, and, for me, to test the internal functions of the program.

Next thing I tried is running the _MUX_3D.cmd directly. double clicking it from location flashed the cmd window for a brief second and closed so I cd'd into the directory and ran it through console:

C:\\BD3D2AVS\xx2\00799_mpls>_MUX_3D.cmd

that returned nothing either:

C:\\BD3D2AVS\xx2\00799_mpls>REM "C:\\BD3D2AVS\toolset\mkvmerge.exe" @_MUX_3D_OPTIONS.txt | "C:\\BD3D2AVS\toolset\tee.exe" "00799_mpls.mkvmerge.log"
C:\\BD3D2AVS\xx2\00799_mpls>

maybe I'm doing something wrong OR this process only runs as part of the encode cmd routine?
That batch file is indeed called by the main _ENCODE.cmd batch, when the encoding is finished (but only if it exists). If you have NOT ticked the "mux to mkv" option in the GUI, then the mux command is commented out, and the batch does nothing. Otherwise, the batch creates the MKV file. I did that this way, as you can change your mind during the encoding, and edit the batch to remove the "REM". In the other hand, if the "mux to cmd" was ticked, you can simply rename that batch to disable the mux phase, and execute it when you want.

one more thing..what is the function (or when is the no_delay used over the regular one) of chapters_no_delay.txt vs the regular chapters.txt file?
If you have ticked the option to create an intro clip, then the chapters have to be shifted by the duration of the intro. The original chapters file created by eac3to is therefore renamed to chapters_no_delay, then read and processed by the GUI to create the definitive chapters.txt file. The GUI adds also the chapters names, missing in the original file. Since there are no meaningful names available, it uses the chapter time, without the decimal part. Some players show the chapters names, others not. Anyway, I think that showing the start time of the chapter is better than nothing.

Note that the no_delay chapter file is used if you mux the 2D version of the movie, as there is no intro, and the original chapter file must be used. It's also why the two chapters files are created anyway, even if there is no 3D intro. It is easier to have different chapter files for the 2D and 3D versions.

[EDIT] BTW, I've just changed the chapter name format. Previously, it was in the form "01:23:45". Now, it is "5 - 1:23:45", where the number before the dash is the chapter number. I've also removed the leading 0 of the time, useless.

[mini-moose]

The GUI adds the "forced only" entries in the second tab to allow you to mux (or hardcode) a subpic stream containing the forced subs only. Unfortunately, it is not possible to know if a specific subpic stream has forced subtitles without demuxing it and processing it with BDSup2Sub. So, the GUI has to add them anyway, and it's your responsibility to select them or not. In case one of these "only forced" stream has been selected, the complete SUP stream is demuxed (including the non-forced subs), and processed with BDSup2Sub to extract only the forced subs. It BDSup2Sub cannot find any forced sub, it issues the error that is shown in the console. The GUI sees that message (and that the output SUB/IDX files have not been created) and assumes that it's normal. The missing forced subs are just ignored, and of course, not included in the mux options (or not hardcoded).


The console is the regular Tcl/Tk console. It's not simply a log window. Like with the DOS command prompt, you can type Tcl/Tk command in that window. The "() 1 %" is just the prompt that indicates that the console is ready to receive input. If you type, for example, "test", it will reply "invalid command name "test"" and the prompt will be changed to "() 2 %", indicating that it is waiting for your second command.
You should never need to type anything in the console, but it is handy to display the output of the CLI commands and error messages, and, for me, to test the internal functions of the program.


That batch file is indeed called by the main _ENCODE.cmd batch, when the encoding is finished (but only if it exists). If you have NOT ticked the "mux to mkv" option in the GUI, then the mux command is commented out, and the batch does nothing. Otherwise, the batch creates the MKV file. I did that this way, as you can change your mind during the encoding, and edit the batch to remove the "REM". In the other hand, if the "mux to cmd" was ticked, you can simply rename that batch to disable the mux phase, and execute it when you want.


If you have ticked the option to create an intro clip, then the chapters have to be shifted by the duration of the intro. The original chapters file created by eac3to is therefore renamed to chapters_no_delay, then read and processed by the GUI to create the definitive chapters.txt file. The GUI adds also the chapters names, missing in the original file. Since there are no meaningful names available, it uses the chapter time, without the decimal part. Some players show the chapters names, others not. Anyway, I think that showing the start time of the chapter is better than nothing.

Note that the no_delay chapter file is used if you mux the 2D version of the movie, as there is no intro, and the original chapter file must be used. It's also why the two chapters files are created anyway, even if there is no 3D intro. It is easier to have different chapter files for the 2D and 3D versions.

great, all understood now. I completely missed the mux to mkv box somehow. remved the rem bit and now I can indeed execute the cmd fine. thanks :)

note I added a bit to my post after some minutes in case you missed it.

[r0lZ]

a suggestion regarding mkvmerge - disable header removal compression for audio and video tracks by default. I think the cmd flag is "--compression" "0:none".
header compression is known to cause issues for some players when enabled.
Not a bad idea, but IIRC the latest versions of mkvmerge have that compression disabled by default. Or am I wrong?

[EDIT] The mkvmerge doc says:

The default for some subtitle tracks is 'zlib' compression. This compression method is also the one that most if not all playback applications support. Support for other compression methods other than 'none' is not assured.

So, it appears that I was wrong for "some" subtitle tracks. Not sure what "some" means, but I will add the --compression none option anyway.

[mini-moose]

Not a bad idea, but IIRC the latest versions of mkvmerge have that compression disabled by default. Or am I wrong?

I don't think so but I'm not sure. if I compare a cmd generated without disabling the compression there is no compression flag at all. such a flag only shows when you set it to disable.
I think the best way to test it is to install mkvtoolnix on a pc that never had it before and see what it says in options regarding that option by default. I assume that can tell if it's set to "no" by default or not. Or maybe the help files will tell us.

[r0lZ]

Look at the edit of my previous post.
(I have added that option only to the subtitle tracks. I suppose it's not necessary for audio tracks.)

[mini-moose]

Look at the edit of my previous post.
(I have added that option only to the subtitle tracks. I suppose it's not necessary for audio tracks.)

zlib is showing on my muxes and a couple others I tried. Friend of mine has a variety of players and non of them could see or display vobsubs. He tried with both muxed vobsubs and extrenal vobsubs (which shouldn't have any compression issues I would think). I will have him try again with subs set to no compression.

the issues I'm aware of are with the video/audio header compression. the bit about vobsubs is actually new to me. I know friends who can't play videos that had the audio headers compressed.

I can't see any reference to it on mkvmerge help or on mkvmerge gui help (need to look more carefully into it though).

[r0lZ]

I've added the --compression 0:none for audio tracks as well. That doesn't hurt.

I'm not sure I have to add it also to the video track. As far as I know, all MKV files are playable with all payers that support the MKV format. Subs are another matter. (My Samsung TV doesn't show the SUB/IDX files, nor the SUP files, in or out the MKV container. Luckily, I have also a LaCinema HDD that can show them, even embedded in the MKV container. Unfortunately, I can't use it for 3D videos with subs, as explained previously.)

[mini-moose]

I've added the --compression 0:none for audio tracks as well. That doesn't hurt.

I'm not sure I have to add it also to the video track. As far as I know, all MKV files are playable with all payers that support the MKV format. Subs are another matter. (My Samsung TV doesn't show the SUB/IDX files, nor the SUP files, in or out the MKV container. Luckily, I have also a LaCinema HDD that can show them, even embedded in the MKV container. Unfortunately, I can't use it for 3D videos with subs, as explained previously.)

yes, I think the audio compression is the issue not the video.
My friend has Dune, popcorn and oppo. non of them display vobsubs. I think he said 2 of those can see they exist but don't display them and one doesn't even acknowledges their existance.
I find it very unfortunate that such popular standalone players don't support what I consider to be a basic format, while freewares such as xbmc/mpc/vlc have 0 issues showing them.
In any case I gave him a clip with the subs compression disabled to see if that makes any difference. not holding my breath though :)

[r0lZ]

OK, let me know if that changed something.

(Side note: Please do not quote the entire previous post. It's useless, and theoretically prohibited by the forum rules.)

[mini-moose]

will do.

As we discussed before, I'm reluctant to hardcode the entire subs but just the forced subs (say I'm native english speaking and a movie has non-english parts that I need), using the "hardcode subtitles stream" feature on your tool.
What I'm unsure of is the option below it "Subtitles 3D depth" - I have no clue what value to use as I have almost no experience with that. Is there some value you can recommend for that?
how is that done anyway? using the current version of bdsup2sub++?

ok, I didn't know it's not allowed to quote. I find that it helpful to follow especially if there are several people discussing different things at the same time.

[r0lZ]

Unfortunately, there is no good way to guess what's the best subtitle 3D depth. It depends of the movie. If there are often objects "outside" the screen, then you should set that value high enough to position the subs so that they do not appear "inside" the objects, but not too high, as subtitles too far of the screen are unpleasant and tiring for the eyes. The problem is that you cannot easily know the right value for that effect, and if you're wrong, you must change the value and encode the whole movie again. (BTW, you can change it in the AVS script easily. There is no need to launch BD3D2AVS and demux again.)

Currently, you should use the java version of BDSup2Sub because the CLI syntax of BDSup2Sub has changed recently and my GUI doesn't take it into account yet. It is also in beta phase and may contain bugs.

BDSup2Sub.jar doesn't have the option to shift the subpics horizontally, so I had to do it by cropping the video, applying the subs, and restoring the cropped part in the avs script. With BDSup2Sub++, it is possible to generate two different SUB/IDX streams, one for each eye, and apply them directly to the non-cropped left and right parts of the input video. That will be easier and faster (but it will be more difficult to change the 3D depth), and I will implement that method when I'll have some time.

Also, BDSup2Sub++ v1.1 should have an option to generate the 3D subs directly in one single stream (by duplicating the original sub and placing the copies at the right positions for the two images), and it will be possible to hardcode them directly on the input video, without any need to crop it. It will also be possible to mux the 3D subs in the MKV file, to display them with a hardware that doesn't support 3D video, such as my LaCinema. The TV will not know that there are subs, but since they will be already at the right place, it will show them correctly, exactly as if they were hardcoded. With that solution, it will be sufficient to regenerate the 3D subs and remux to change the 3D depth when it is wrong. I'm waiting for v1.1 with great impatience, but v1.0 is not out yet! :(

ok, I didn't know it's not allowed to quote.You can quote, but only some part of a message (like I did here), or a previous message if you reply specifically to that one and there are new posts.