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

[Thalyn]

C'mon, Moose... we've already had enough hostility in here and there's no reason to start it up again. This being the internet it only takes one semi-sarcastic comment to get things completely off the rails.

I'm not saying that I endorse or even use BDtoAVCHD (I'm currently experimenting with FRIM and DGMVC through MeGUI) but it's still relevant. This is a thread about stereoscopic conversions and his tool does that - even the newer versions. And, besides, now I know there's a new version of TSMuxer available!

[mini-moose]

C'mon, Moose... we've already had enough hostility in here and there's no reason to start it up again. This being the internet it only takes one semi-sarcastic comment to get things completely off the rails.


fair point.

[r0lZ]

# v0.1 to v0.29 (2012 & 2013):
# - Old version using DirectShowMVCSource, ssifSource2 or 3 and eac3to
# v0.30 (January 21, 2013)
# - First version using DGMVCSource or FRIMSource instead of DirectShowMVCSource or ssifSource3.
# v0.31 (January 25, 2013)
# - Crash in 2-pass mode fixed.
# - "Check Java installation" now shows clearly that the 32-bit version of Java is needed.
# v0.32 (January 26, 2013)
# - Wrong syntax of the DGMVCSource() command caused DGMVCDecode.dll to crash.
# - New option in tab 3 to include or exclude the encoder (technical) tags.

As usual, download it here (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z).

The latest version of DGMVCSource seems to work well and has (probably) no more "end of file" bug. However, it doesn't use hardware acceleration yet, so FRIMSource is a better option if you have the Intel hardware supporting the acceleration.

[b0mb]

can't read "pass4": no such variable
can't read "pass4": no such variable
while executing
"foreach entry $pass4 {
set mpls [string trim [lindex $entry 0] ,]
if {[lsearch $alreadyprocessed $mpls] == -1} {
lappend alreadyprocessed $m..."
(procedure "ScanFullBD" line 191)
invoked from within
"ScanFullBD true"
(procedure "OpenBD" line 37)
invoked from within
"OpenBD $r"
(procedure "SelectBD" line 9)
invoked from within
"SelectBD"
invoked from within
".nbf1.tb.open invoke "
invoked from within
".nbf1.tb.open instate {pressed !disabled} { .nbf1.tb.open state !pressed; .nbf1.tb.open invoke } "
(command bound to event)when i try to open a bd structure with latest build i got an error

[r0lZ]

I see. I guess the error happens only with that BD. Right?
Try to enable the option to Show all 3D playlists, but I don't know if it is available after the error.
Anyway, I will fix it soon...

[r0lZ]

Here is the fix.

# v0.33 (January 26, 2013)
# - The can't read "pass4" bug when parsing some BDs should be fixed.
# - The warning about x264 level 5.0 or higher is now displayed only when necessary.

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

Note: That bug should normally never happen. It is caused by the list of 3D titles being empty. So, either your BD has no 3D movies, or it has only 3D movies that are automatically removed from the list, for example because they are too short (less than 1 minute).

If you see nothing after having opened the BD, try the option "Show all 3D playlists". And let me know if you think the program has missed the main 3D movie.

BTW, what BD is it?

[b0mb]

i´ve tried another bd that was working well...

going to get the problem bd read with the new build tomorrow morning ;)

thx!

[sef]

Not tested DGMVCDecode.dll , I have with him slideshow..

[b0mb]

the new version of bd3d2mk3d reads the structure but says that there is no stereoscopic material on the disc?!? :|

when i try show all 3d playlists it scans the half of the files and the tsmuxer crashes

very wicked - i´ve tried old build from 23rd december which is reading the structure now but eac3to gives me an error when i want to select a stream ...

[r0lZ]

Builds before v0.30 are based entierly on eac3to to get and analyse the content of the disc. The recent versions use eac3to and tsMuxeR.

Can you be more specific?

What BD is it?
Can you tell me at what MPLS file tsMuxeR crashes? (Open the Console to view the details of the scan.)
What is the duration and characteristics of the main 3D movie found with the older version?
Does it corresponds to the MPLS that makes tsMuxeR crash?

[b0mb]

it seems like the bd has not been decrypted well - i solved the problem now and the disc (madagascar 3) can be choosed and all seems to work fine but where can i choose full-sbs?

i see only sbs and hou?

[r0lZ]

Full-sbs is not supported any more. Sorry.
But you can easily edit the avs script, and remove the two "HorizontalReduceBy2" commands.
Change this:StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
to this:StackHorizontal(Left, Right)
That should be sufficient.

But note that 3D subtitles (hardcoded or not) are not supported by Full-SBS or Full-T&B.

[b0mb]

ah! ok! i´ll try editing the avisynth script...

i allways keep the original pgs subs which are working well for me ;)

[mini-moose]

got another question.

I noticed the chapters files are generated with the time position
added as the chapter name:

CHAPTER02=00:10:38.137
CHAPTER02NAME=2 - 0:10:38

usually when I extract chapters with eac3to the chapter name stays empty.

Curious if there is a purpose behind it.

[r0lZ]

Not really, but IMO, that gives a useful information, and it's better than nothing. Many players show the chapter name, and in some cases, it's useful. For example, you can easily select a chapter to jump, say, near the middle of the movie, with more precision than if you see only a chapter number.

[mini-moose]

Not really, but IMO, that gives a useful information

ok thanks.

Was playing with Chapter Grabber earlier and it seems to have trouble with ogm and I think also with .txt that have the names filled in. DB is limited anyway but it can fill in some chapter names for some movies.

[r0lZ]

I don't know Chapter Grabber. What is it supposed to do?

[mini-moose]

I don't know Chapter Grabber. What is it supposed to do?

It can add chapter names when such exist and are on it's db.
I guess it's mostly useful for music blu-rays but it's something you find on movies too sometimes (haven't extensively tried though).

[r0lZ]

Yes, I've just seen the thread here (http://forum.doom9.org/showthread.php?t=40343). It seems interesting, but I have to check it to understand how it works. Is it able to modify the names of the chapters of a .ogm file created with another tool? You should never change the time codes, as they are correct in the ogm files generated by BD3D2MK3D, even if you have used the option to add a few seconds of black at the beginning of the video. Also, they are perfectly in sync with the .qpfile, and therefore, you have the guarantee that there will be an I-frame at the beginning of each chapter. Of course, if you use another chapter file with (even slightly) different time codes, you lose that benefit.

Anyway, if Chapter Grabber has trouble modifying the original ogm files, you should contact its author. It's not something wrong in my program.

[mini-moose]

Anyway, if Chapter Grabber has trouble modifying the original ogm files, you should contact its author. It's not something wrong in my program.

Didn't say there's something wrong with your program :) was just exploring something that happens to be related to blu-rays. It doesn't seem to accept ogm at all.

[r0lZ]

I see. Then, it's perhaps a suggestion for the author. ;-)

[r0lZ]

@mini-moose

I've read your message about the bitrate calculators, but I'm not convinced by them. I have analysed the method used by the "Bitrate Calculator GPL" and it doesn't take any overhead into account, and you cannot specify subtitle streams. (I agree that the subtitles can be ignored, because usually they are small files, but the overhead cannot simply be ignored.)

Anyway, here is what I do.
Note that that code is executed after the demux operation, and therefore the exact file size of all audio and subtitle streams is known, and must not be evaluated. However, there is a little overhead when an audio file and the video file are muxed in the final MKV. It's that overhead that is difficult to estimate.

1. Add the file size of all audio files together.

2. Multiply that size by 1.0006. (It's my estimation of the audio overhead.)

3. Add the file size of all subtitle streams to that size. (Only the .SUB file is taken into account. The IDX file is ignored.)
Note that there is no overhead for the subtitle files.

At this point, I know the "total size of muxed streams" (with overhead). That size is printed to the log, so you can verify it if you wish.

4. The remaining size for the video stream is then computed, by subtracting the total size of muxed streams from the media size provided by the user in the GUI. The "remaining file size for video (with overhead)" is again printed to the log.

5. The total movie duration is computed. It's the duration reported by eac3to or tsMuxeR, plus the seconds of black added at the beginning or end of the video, if any, converted to a number of seconds. It is also printed to the log.

6. Finally, the target bitrate is computed using this formula:
bitrate = round(remaining_size_for_video * 8 / movie_duration * 1.0012) / 1000

Note that the movie duration is multiplied by 1.0012 to take the video overhead into account.
The remaining_size_for_video is multiplied by 8 because the bitrate is expressed in bits and not in bytes. Similarly, the final result is multiplied by 1000 because it is expressed in Kbits and not in bits.

Of course, the final video bit rate is also printed to the log.

7. Finally, the program checks if the final video bitrate is smaller than 1000, and if it's the case, it issues a warning and forces it to 1000. IMO, 1000 is the strict minimum for a low quality encoding.


As you can see, currently, the overhead multipliers are fixed to 1.0006 for the audio files, and 1.0012 for the video. Curiously, the subtitle sizes have a little NEGATIVE overhead, and I have decided that it is small enough to ignore it.

I did many tests to obtain these values, but I agree that they are somewhat too high. I may lower them a bit, but I need some time to do many new tests.

Also, my method uses the audio file size, not the audio bitrate. I may try to use the bitrate instead, if I can get it from the tsMuxeR output and if it appears that it is correctly evaluated. Don't forget that the audio streams are usually encoded in VBR mode, and therefore it is not necessarily easy to get the correct average bitrate. It's why I prefer to use the file size of the demuxed stream.

[mini-moose]

I've read your message about the bitrate calculators, but I'm not convinced by them.
ok, that's a little above my skills. I pointed some calculators that seem to do the job in case they can assist, as your were looking for a better formula. For 2D at least they seem pretty accurate.

It's true that vobsubs would not be computed and that might be an issue, as they are a lot bigger than text subs, and those calculators don't offer those to be added into the equation.

As for Audio, if you use the DTS-MA/HD or TrueHD streams, those would be hard to compute by bitrate but could be by size maybe. The core audios are easier as they are CBR so sizes are constant.

[r0lZ]

I have noticed a serious bug in tsMuxeR, that I have reported in the tsMuxeR thread here (http://forum.doom9.org/showthread.php?p=1664898#post1664898). Unfortunately, that bug has an important impact on BD3D2MK3D. As long as that bug is not fixed, it is not possible to demux a video stream from a multi-angle MPLS with tsMuxeR.

It is important to understand that there are two ways to handle multi-angle movies in the 3D (and 2D) BDs. The most common method is to use a different MPLS for each angle. For example, 00001.mpls could reference 00001.ssif+00002.ssif+00003.ssif, and 00002.mpls could reference 00001.ssif+00004.ssif+00003.ssif. In that example, only the second ssif is different. 00004.ssif may contain for example the movie title in a different language. tsMuxeR can successfully demux any of there MPLS files.

But there is also another method. The same MPLS can contain several different playlists, one for each angle. For example, 00001.mpls could reference 00001.ssif+00002.ssif+00003.ssif AND 00001.ssif+00004.ssif+00003.ssif in the same file. For my examples above, that means that currently, it is not possible to specify that we want the first or second angle to be demuxed, and if we try to demux the MPLS anyway, the MVC stream is truncated after the first part (common to all angles). Of course, with an incomplete MVC file, it is not possible to encode the movie.

I have discovered that problem when I have tried to encode "Cloudy with a Chance of Meatballs 2". The GUI has also a bug, and it doesn't show the correct information in tab 1. Also, only angle 1 is available in the list of MPLS to process.

The GUI bug is already fixed, and I am working on a workaround for the tsMuxeR bug, but unfortunately, it's not easy. I have to use eac3to to demux the video streams of such multi-angle MPLS , but I still have to use tsMuxeR to demux the audio and subtitle streams, because eac3to has a big bug when demuxing the 3D subtitles of some (many) movies. Therefore, the demux operation will require 2 passes, and of course, it will be very long. Of course, for normal MPLS files, the method has not changed, and still use tsMuxeR only. I hope Roman will fix that bug rapidly, so I can remove that workaround, but in the meantime, you will have to wait longer for the demux operation to finish.

I have already a new version that seems to work well, but I want to verify it before releasing it. So, be patient, and do not try to process Cloudy 2 right now. With some chance, I will be able to encode it tonight, and I'll release a new version tomorrow...

[jdobbs]

You can pull the information from the MPLS yourself and construct the META file. It's a little more code, but not too bad.

[r0lZ]

Oh, I don't need to analyse the MPLS file myself. I use eac3to for that usage, and it works pretty well. (However, I agree that doing it myself can probably be much more rapid. I will have a look...)

Your idea of building the meta file directly from that information is interesting, but I don't know the syntax to demux several SSIF files as a whole. Is it possible? How?

[jdobbs]

Sure. You just put a "+" sign between them. Here's an example:

V_MPEG4/ISO/MVC, "P:\BD_KEEP\TOY_STORY_3D\BDMV\STREAM\SSIF\00014.ssif"+"P:\BD_KEEP\TOY_STORY_3D\BDMV\STREAM\SSIF\00069.ssif"+"P:\BD_KEEP\TOY_STORY_3D\BDMV\STREAM\SSIF\00073.ssif", insertSEI, contSPS, track=4114

V_MPEG4/ISO/AVC, "P:\BD_KEEP\TOY_STORY_3D\BDMV\STREAM\SSIF\00014.ssif"+"P:\BD_KEEP\TOY_STORY_3D\BDMV\STREAM\SSIF\00069.ssif"+"P:\BD_KEEP\TOY_STORY_3D\BDMV\STREAM\SSIF\00073.ssif", insertSEI, contSPS, track=4113

You can see the syntax by using the GUI and using the JOIN button for each SSIF segment.

You can do the same for the PGS and Audio streams.

Demuxing will give you some really long filenames (try it and you'll see), but you can also use this syntax to remux into a single file or structure -- and then demux from that.

[r0lZ]

I see. It's similar to the eac3to syntax.

But if I understand correctly, there is a risk of too long file names for Windows, if there are many SSIF files referenced in the MPLS. For example, in some Disney BDs, there are more than 100 SSIF files in the main movie. Will it be possible to create the output file under Windows? (Windows is picky with long file names and sometimes refuse to create or even delete them. I don't want to be stuck with a file that cannot be deleted.)

Also, the solution to remux them to demux a single file later is not a good solution IMO. It will take even more time than the current method I've implemented, using eac3to. But thanks for the tip anyway.

[jdobbs]

I see. It's similar to the eac3to syntax.

But if I understand correctly, there is a risk of too long file names for Windows, if there are many SSIF files referenced in the MPLS. For example, in some Disney BDs, there are more than 100 SSIF files in the main movie. Will it be possible to create the output file under Windows? (Windows is picky with long file names and sometimes refuse to create or even delete them. I don't want to be stuck with a file that cannot be deleted.)

Also, the solution to remux them to demux a single file later is not a good solution IMO. It will take even more time than the current method I've implemented, using eac3to. But thanks for the tip anyway.Your choice. But it's been working for me for a long, long time.

[r0lZ]

So, you have never had too long file names? I don't remember exactly, but I think the problem with the long file names under Windows is present only in Explorer. IIRC, it should be possible to create, rename or delete files with very long file names from tools that do not use Explorer. I will check what happens with a Disney. If it can be processed without problem, I'll use that method.

Currently, I'm demuxing Cloudy 2 and it works well so far, but there are only 3 SSIF files in the MPLS. Easy! ;-)

[jdobbs]

So, you have never had too long file names? I don't remember exactly, but I think the problem with the long file names under Windows is present only in Explorer. IIRC, it should be possible to create, rename or delete files with very long file names from tools that do not use Explorer. I will check what happens with a Disney. If it can be processed without problem, I'll use that method.

Currently, I'm demuxing Cloudy 2 and it works well so far, but there are only 3 SSIF files in the MPLS. Easy! ;-)Sure you do, but it has to be pretty long. As you said, Disney gets crazy. If the output filename is too long, TSMUXER fails, so I then just remux to an M2TS or SSIF and demux from that. It's actually pretty fast.

You can also simply concatenate the files as well --- but that's another story.

It would be a lot better if you could simply select an angle from TSMUXER and just use the MPLS, but right now you can't. I guess you can with eac3to?

[r0lZ]

Yes, eac3to works fine with multi-angle MPLS files. Its first parameter is the angle number. Unfortunately, it cannot demux properly the subtitles when they are present in the M2TS file containing the AVC stream (it's always the case) AND in the M2TS containing the MVC stream. I have never understood why some BDs are authored that way, but unfortunately, it's often the case. And it seems that the subtitle stream in the MVC M2TS share the same ID than the corresponding stream in the main M2TS. As a consequence, eac3to considers the two streams as one single stream, and complains. The resulting SUP file is unusable. It's why I prefer tsMuxeR. But nothing is perfect! It's a pity that tsMuxeR doesn't have an option to specify the output stream name in its meta file.

[Nico8583]

Do you think it's possible to convert MPLS multi-angle to separate MPLS ? Because you may lose informations when you don't open MPLS ?!

[jdobbs]

Do you think it's possible to convert MPLS multi-angle to separate MPLS ? Because you may lose informations when you don't open MPLS ?! Hmmm... that's a pretty good idea. It should be easy enough to copy the existing MPLS and just swap angle 1's entries with those in one of the other angles. I might be able to write a command line app to do it if anyone wants it. Of course it wouldn't work when reading directly from a disc, but those on the hard drive would work... I think TSMUXER would require that it is in the same BD structure.

[r0lZ]

I'm not sure that will be sufficient. In addition of the problem of read-only media, there is the problem of tsMuxeR not being able to demux correctly the first angle of a multi-angle SSIF file. It's strange, as it can demux the same SSIF when it is given in the meta file with the "+" syntax, but not when it is a part of the first angle of a MPLS. I wonder why. It seems that it takes into account the SSIF files of the other angles, even though it doesn't list them in its output. Anyway, that means that it will probably be necessary to create a completely new MPLS with only one angle, and not just duplicate it and swap the existing angles.

jdobbs, if you write a CLI tool to do it, I'll be glad to test it, but I'm not sure I'll use it with my GUI, because afaik most people use a mounted ISO or a real BD (with AnyDVD if necessary) as input. Having to copy the BD as single files to HDD is a very long operation, and that requires also much disc space (especially with a BD 3D, where the SSIF files must be copied in addition to the M2TS).

[jdobbs]

I'm not sure that will be sufficient. In addition of the problem of read-only media, there is the problem of tsMuxeR not being able to demux correctly the first angle of a multi-angle SSIF file. It's strange, as it can demux the same SSIF when it is given in the meta file with the "+" syntax, but not when it is a part of the first angle of a MPLS. I wonder why. It seems that it takes into account the SSIF files of the other angles, even though it doesn't list them in its output. Anyway, that means that it will probably be necessary to create a completely new MPLS with only one angle, and not just duplicate it and swap the existing angles.

jdobbs, if you write a CLI tool to do it, I'll be glad to test it, but I'm not sure I'll use it with my GUI, because afaik most people use a mounted ISO or a real BD (with AnyDVD if necessary) as input. Having to copy the BD as single files to HDD is a very long operation, and that requires also much disc space (especially with a BD 3D, where the SSIF files must be copied in addition to the M2TS).No problem. But I haven't noticed any issues with multi-angle discs. I have a couple of angled discs I keep on my hard drive for testing. I'll check it out.

[HWK]

Try cloudy with chance of meat balls 2 as test candidate.

[r0lZ]

Yes, it's with Cloudy 2 that I have had a problem, when trying to demux the MPLS with tsMuxeR (and therefore angle 1), as I wrote in the tsMuxeR thread:
[...]
As you can see, the MVC stream is truncated at frame 11753.
Note that frame 11753 is somewhere at the beginning of 00345.ssif, in the multi-angle part of the movie. The other streams (AVC, audio and subtitles) are correct.

So, currently, afaik there is no way to specify to tsMuxeR that angle 1, 2 or 3 must be demuxed. I haven't tried, but I guess that it has the same limitation with a 2D multi-angle MPLS.

And anyway, with a 3D multi-angle MPLS, it cannot demux properly the MVC stream. eac3to, in the other hand, can demux the two video streams of any angle (but it has other problems, notably with the subtitles).
[...]
Maybe Cloudy 2 is authored strangely or has something special. But anyway, eac3to can demux it, so there must be a bug in txMuxeR, probably due to a bad parsing of the multi-angle MPLS.

[r0lZ]

@mini-moose:

I have slightly modified the formula to compute the bitrate in ABR or 2-pass modes, and I think it is much better now. I have made a 2-pass encoding of Claudy 2 (with the Slow preset), and I have requested 4470 MB for the target medium size. (It's the size of a DVD-5.) This morning, I see the final MKV, that is exactly 4,685,222,922 bytes long, approx 4468.18 MB. Although it is still slightly off, I think we can live with a so small difference. :-)

I will release a new version soon, but before, I would like to implement the "+" syntax for the meta files of tsMuxeR, to solve the problem of the multi-angle MPLS files. Please report if your next encodings produce correct file sizes.

[mini-moose]

his morning, I see the final MKV, that is exactly 4,685,222,922 bytes long, approx 4468.18 MB. Although it is still slightly off, I think we can live with a so small difference. :-)

great, thanks. a couple mbs over/under is common anyway.

[r0lZ]

OK, here is the new beta: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

# v0.34 (February 1, 2014)
# - BD scan bug when eac3to's output includes the angle number is fixed.
# - Due to bugs of tsMuxeR when demuxing the video streams of a multi-angle MPLS,
# the "SSIF+SSIF+..." syntax is now used in the tsMuxeR meta file for the video tracks.
# - When the "SSIF+SSIF+..." tsMuxeR syntax cannot be used due to too long file names,
# eac3to is used to demux the video tracks of multi-angle MPLS.
# - Better formula to compute the bitrate from the file size in 2-pass or ABR mode.
# - The conversion of the forced subtitles of streams without forced subtitles is now automatically skipped.
# - Copy M2TS/SSIF List to Clipboard (available by right-clicking on an entry in tab 1) was broken.
# - DGMVCSource is now the default again, instead of FRIMSource.
# - Updated DGMVCDecode.dll to the latest version (b20)

Currently, the program tries to use tsMuxeR whenever possible, and use eac3to to demux the video streams only in this precise case:
- The MPLS to compute is a multi-angle MPLS
- And it has too many SSIF parts to result in a file name compatible with the NTFS limitations.

Under NTFS, the maximum length of a file name is theoretically 255 characters. However, the full length of the path\filename is also limited to 260 characters. So, the program checks if the MPLS to demux is multi-angle. If it's not the case, it uses tsMuxeR the normal way (with the MPLS as input file name). Otherwise, it computes the length of the names that tsMuxeR will give to the video files, and if it is greater than 255 characters, then eac3to is used. Otherwise, the path of the output directory is added, and if the total length of the full file name is greater than 260 characters, then eac3to is used. Otherwise, tsMuxeR is used with the "+" syntax, and the two video files are renamed on disc immediately after the demux, to re-create a descent file name.

That means that now, tsMuxeR is used anyway in most cases, and the only exception is when the multi-angle SSIF has too many SSIF parts (normally more than 20 to 25 parts). For instance, it is now possible to demux the video streams of Cloudy 2 with tsMuxeR. The Disney BDs can also be demuxed by tsMuxeR, even when they have more than 120 parts in the MPLS, because the SSIFs are always mono-angle. IMO, most BDs will be demuxed by tsMuxeR, and only very rare exceptions will require the additional eac3to pass. :)

Note that to minimize the risk to have to use eac3to instead of tsMuxeR, you should select an output directory with a short name and placed directly in the root of one of your drives. For example, if you use "D:\3D\", you will probably have the possibility to demux a multi-angle MPLS containing up to approx 25 SSIF parts with tsMuxeR. Otherwise, eac3to may be used, and that means that the time necessary to do the demux phase will be multiplied by 2. Not a big deal anyway. AFAIK, eac3to does a good job with the video streams.

I think I'll keep that method, unless it doesn't work well with some BDs. Of course, if you find a BD that fails, please let me know. Also, I would like to know if a specific BD needs to be demuxed with eac3to. Currently, I have none.

Thanks to jdobbs for having suggested the solution to use tsMuxeR in most cases. :)

[Nico8583]

Is it a software to create a MPLS file ? So we could create a MPLS file only to open it in tsMuxeR and remove NTFS limitations

Or edit MPLS file to remove angle information and map SSIF with correct files

[r0lZ]

AFAIK, no, but jdobbs suggested to write it. ;)
I might be able to write a command line app to do it if anyone wants it.

[Nico8583]

Yes I've seen this post :) but if tsMuxeR is not able to demux properly, it's useless :( so perhaps we could create a playlist (like for MP3) to replace file1+file2+file3...

[r0lZ]

I don't understand.
Is it a software to create a MPLS file ? So we could create a MPLS file only to open it in tsMuxeR and remove NTFS limitations

Or edit MPLS file to remove angle information and map SSIF with correct files
Is it not exactly what you suggested here?:
Do you think it's possible to convert MPLS multi-angle to separate MPLS ? Because you may lose informations when you don't open MPLS ?!
The solution of the "+" syntax works perfectly... as long as there are not too many SSIF files in the multi-angle MPLS.

IMO, the problem is due to the lack of an output file name for tsMuxeR. It can demux properly, but it cannot create the files with the (sometimes very) long file names it generates automatically, when there are too many SSIF files.

There are several ways to solve that problem, including the remux to a temp file, or using eac3to. But unfortunately, all methods, except the "+", need to write a lot of data on disc, and are therefore slow. It's why I have implemented the "+" method when it's possible.

The only method that may work faster than the remux or eac3to is your idea: with a new, mono-angle MPLF file, it should be possible to generate the output file with a short file name. But for that method to work, it is necessary to write that new MPLS in the BD folder BDMV/PLAYLIST. Most of the times, that folder is read only, and you have to copy all BD files (or at least some of them) to your HDD. It's again a waste of time and disc space.

It's why I have chosen the eac3to solution. It's a second demux pass, but IMO, it's the fastest of the 3 solutions, and it is reliable. Of course, I would prefer a modification of eac3to to support an output file name. I hope it will be implemented some day. In the meantime, the eac3to solution is sufficient IMO, given the fact that there are very few multi-angle MPLS referencing too many SSIFs. In fact, I don't think there is a single 3D BD having that problem currently available. So I wouldn't worry too much.

[Nico8583]

jdobbs suggests a tool to edit an MPLS file, but the best would be to create a new MPLS file (or remove angle information rom existing MPLS) for each angle in order to replace "+" method, so we could use this with infinity SSIF files.

Yes "+" method works perfectly but it can't be used with too many files, and remux to a temp file need time and space so no interest, we are allright. Why new MPLS needs to be write in BD folder and not to a temp folder ? Is it impossible to specify files path ?

[r0lZ]

Why new MPLS needs to be write in BD folder and not to a temp folder ? Is it impossible to specify files path ?Yes. In the MPLS, you can only specify the number of the SSIF (or M2TS) files to include, not their full path. And tsMuxeR finds the containing folder relatively to the path of the MPLS file. In other words, it must be in the PLAYLIST directory of the BD. Pity. It's why I prefer the eac3to method.

[Nico8583]

OK :) I believed full paths could be indicated, sorry, so I'm agree with your solutions to have a full working demux :
- Add output filename to tsMuxeR
- Add angle detection feature to tsMuxeR

[Nico8583]

I've perhaps found an tip to use a modified playlist with an ISO or BD :
- Create a folder (ex : D:\BD\)
- Create in this folder another folder named PLAYLIST (ex : D:\BD\PLAYLIST)
- Create a symbolic link to STREAM folder on ISO (ex : mklink D:\BD\PLAYLIST H:\BDMV\STREAM) - Works only with NTFS file system if I'm not wrong
- Copy or create a MPLS into D:\BD\PLAYLIST and open it in tsMuxeR. It works for me with an original MPLS, so it would be good to try with a modified playlist :) and no need to copy all files to HDD from an ISO or BD ;)

Edit : Symbolic link appears in Windows like a classic shortcut, so delete it will delete the symbolic link without delete data.

[r0lZ]

Nice idea. :-) I'll test it. If it works fine, that could make the CLI tool proposed by jdobbs very interesting.