BatchMux plugin - MuxMan authoring with DVD2SVCD

[manolito]

And a BIG thank you from me, too!

Even if the current version of DVD2SVCD has not been updated for almost two years (and it probably never will), it is amazing to see how a couple of loyal users keep this application current by writing plugins. IMO this piece of software still can give all the new competition a run for the money... (well, most of the new conversion frontends are free also, but you know what I mean).

Cheers
manolito

[manolito]

Hi SD,

this is not really a bug report but more letting you know that your plugin is in heavy use here all the time...

I did find a small issue with the current Mplex_hack.exe (from the Batchmux 1.7 package) which only happens on extremely rare occasions.

It only happens in DVD2DVD mode with fixed chapters using QuEnc or HC (any encoder other than CCE).

Earlier versions of Mplex_hack.exe always used the "length=" entry in the DVD2SVCD project file to determine the movie length. Only if this value was 00:00:00 then the length was retrieved from the CCE ECL file (Workaround for CCE 2.70).

The current version behaves differently:
1. DVD2DVD mode.
- Framerate (initialised to 30 fps)
- TVsystem (acquired from "PAL=" string)
- MovieFrames (acquired from "Frames=" string)
- If the line "fps=25" is present in the file, then FrameRate is set to 25 fps
- If the line "fps=" is present in the file, then FrameRate is set depending on the TV System (25 for PAL and 30 for NTSC)
- In case MovieFrames is 0, then Mplex_hack attempts to get this value from the CCE ecl file
- In case Pulldown is present, as detected from the argument of Mplex_hack, then MovieFrames = MovieFrames * 5 / 4

2. Avi2DVD mode.
- Framerate (initialised to 30 fps)
- TVsystem (acquired from "VideoFormat=" string)
- MovieLength (in hh:mm:ss format, acquired from "Length=" string)
- If the line "fps=25" is present in the file, then FrameRate is set to 25 fps
- If the line "fps=" is present in the file, then FrameRate is set depending on the TV System (25 for PAL and 30 for NTSC)
- In case hh, mm and ss are all 0, then Mplex_hack attempts to get MovieFrames from the CCE ecl file
- In this case, when Pulldown is present, as detected from the argument of Mplex_hack, then MovieFrames = MovieFrames * 5 / 4
In DVD2DVD mode the "Frames=" entry in the project file is used. If "Frames=0" then the CCE ECL file is used.

This logic assumes that if length=00:00:00 then Frames must be 0, too. This is true in 99.9% of cases, but not always. In certain cases it can happen that the length entry has the correct movie length, but Frames are set to 0.

It happens when I kill DVD2SVCD during the audio extraction phase. I do this frequently when I want to use a different audio file (one which I have edited and sweetened with a wave editor). Before resuming DVD2SVCD I have to edit the D2S project file to make it use my new audio stream, and then I can resume at the audio processing stage.

The D2S project file in this scenario will have "Frames=0" and the length entry will have the correct movie length. This worked fine with earlier versions of Mplex_hack.exe, but the current version will only see the "Frames=0" entry and then tries to get the values from the ECL file. But since I do not use CCE, there will be no ECL file.

This is not a problem in AVI2DVD mode since in this mode the "length=" entry is used. And if CCE is my encoder then Mplex_hack.exe will always find an ECL file to get the necessary information.

A possible workaround would be a slightly changed logic for Mplex_hack.exe:
If "Frames=0" then check if "Length=00:00:00" also. Only try to get the values from the CCE ECL file if both conditions are true. Otherwise calculate the value for Frames from the Length entry.


Again, this is something that happens only under very rare circumstances. I am probably the only D2S user who will ever experience this issue. So please do not feel pressed in any way to update Mplex_hack.exe. (Only if you really get bored during the upcoming Xmas holidays...)

Cheers
manolito

[Sir Didymus]

I see...

Infact the logic of the process is exactely as you describe... The model was designed following some limited and simple "try and see" process, so I was aware since the beginning of the possible conceptual mistakes...

Said this, your experience on the matter is fundamental, so please do not have any hesitations in reporting wrong behaviours of the plugin, even as consequence of some "etherodox" usage...

Your suggestion is an easy possibility; however I am start thinking why not to "fuse together" the DVD2DVD and AVI2DVD modes, in order to use the same unified logic:


1. DVD2DVD and AVI2DVD modes.
- Framerate (initialised to 30 fps)
- TVsystem (acquired reading both "PAL=" and "VideoFormat=" strings, and using the one which is initialised)
- MovieFrames (acquired from "Frames=" and "Lenght=" strings, and using the one which is initialised)
- If the line "fps=25" is present in the file, then FrameRate is set to 25 fps
- If the line "fps=" is present in the file, then FrameRate is set depending on the TV System (25 for PAL and 30 for NTSC)
- In case MovieFrames is 0 and hh, mm and ss are all 0, then Mplex_hack attempts to get this value from the CCE ecl file
- In case Pulldown is present, as detected from the argument of Mplex_hack, and MovieFrames was not derived from "Lenght=" string, then MovieFrames = MovieFrames * 5 / 4


However, I am not sure about the implications...

Let's see...

[manolito]

Well, I cannot find any fault in this "unified" logic. As you said: Let's see...

Cheers
manolito

[Sir Didymus]

Beta1, of Mplex_hack release 1.3, addressing the issue pointed out in your last posts...

Edit 01-12-2007 - Link removed

Hem.. please use it with some cautions, at least initially - the new logic is completely untested :scared: ...

Cheers,
SD

[manolito]

Thanks SD, will start testing right away...

Cheers
manolito

[manolito]

Oh my, it looks like I opened a whole can of worms here!

Whenever you kill DVD2SVCD somewhere in the middle of a job and then resume using a different audio stream or a different encoder (probably a different anything), D2S seems to write some nonsense into its project file.

The current problem was that the entries for movie length and for frames were not concurrent (Frames=0, but correct length entry). Now I ran into more stupid entries which occur when I start D2S with CCE 2.70 in D2SRoBa mode and kill the encoder after the Q value has been found. When I then resume using HC or QuEnc, the project file has "Length=00:00:10", "fps=24" and the correct entries for "Frames=" and "PAL". (The source was a commercial PAL DVD)

In this scenario Mplex_hack 1.2 assumes a frame rate of 30 and creates NTSC chapters. Version 1.3 Beta 1 only looks at the (nonsense) "Length" entry and disregards the (correct) "Frames" entry and creates no chapters at all. If you want to take a look at the log files, download them here:
http://scifi.pages.at/manolito/SD/Logs.zip

I don't know if it is really worth your time to catch all these errors. The only way I see how you could do this would be to always look at several entries in the project file and choose the one which looks more plausible.
(E.g. always check the entries for "Length" and "Frames" and use the longer value. IF "PAL=1" and "fps=29.97" then the PAL entry must be wrong (this happens for PAL2NTSC conversions). But if fps is anything other than 25 or 29.97 then this value must be wrong and the PAL entry looks more plausible).


If I were you I would probably just add a warning at the end of the readme saying: "If you really cannot resist to kill DVD2SVCD in the middle of a conversion and then resume with different settings, YOU ARE ON YOUR OWN !"

Cheers
manolito

[Sir Didymus]

...(E.g. always check the entries for "Length" and "Frames" and use the longer value. IF "PAL=1" and "fps=29.97" then the PAL entry must be wrong (this happens for PAL2NTSC conversions). But if fps is anything other than 25 or 29.97 then this value must be wrong and the PAL entry looks more plausible).


That's an excellent idea, and easy to implement...


...I would probably just add a warning at the end of the readme saying: "If you really cannot resist to kill DVD2SVCD in the middle of a conversion and then resume with different settings, YOU ARE ON YOUR OWN !"


It seems to me too this warning is really needed... :p

[Sir Didymus]

OK. Here it is a second beta for release 1.3 of Mplex_hack...

Edit 01-12-2007 - Link removed

Some decisions are taken in the situations of inconsistence of the parameters present in the project file...

Cheers,
SD

[manolito]

Great!
Just finished a couple of tests with deliberately inconsistent project file entries, but I could not break the new beta. Chapters always came out correctly.

Tomorrow I will do some PAL2NTSC tests. Maybe you can recruit Bionic and / or Fishman for some NTSC tests...

Thanks very much!
Cheers
manolito

[Fishman0919]

Sure, let me know what you would like me to do.... Glad to help

[Sir Didymus]

Hi Fishman0919!

Well, in the new beta of Mplex_hack, the logic of acquisition and analysis of movie lenght and TV system is changed, and it is now common for the DVD2DVD and AVI2DVD modes.

My principal concern now is to ensure that this new version work at least as good as the previous one. So, some verifications of regular behaviour, both for AVI2DVD and for DVD2DVD, especially for NTSC+pulldown sources, would be very helpful...

Thanks in advance if you can perform some quick checks in this scenario...

Cheers,
SD

[Fishman0919]

Well, so far with 5 DVD's it works perfect (HC 0.22, CCE 2.50)... charters are right on point.

I'm making some AVI's now and will report back.

[manolito]

OK, here are the test results for PAL2NTSC conversions using Mplex_hack 1.3 Beta 2:

There is only one scenario where the current Beta fails, and this is using CCE 2.70 and the conversion method for interlaced content using ChangeFPS(59.94). The D2S project file in this case has a "Length=" entry of 00:00:00, and the "Frames=" entry has the correct source frames. The "fps=" entry is 29.97, so Mplex_hack correctly detects NTSC. But it does retrieve the frame number from the D2S project file (source frames) instead of the ECL file (presentation frames). This results in correct chapter spacing, but the last chapters are missing because the calculated movie length is too short.

All other cases work just fine. The DGPulldown method is OK, and when using QuEnc (or any encoder except CCE 2.70) the movie length can be retrieved from the project file which also results in perfect chapter points.

Here is just another example for a funny D2S project file value: When I used QuEnc with the "ChangeFPS(59.94)" conversion method, I got "fps=29.9700012207031" in the project file. (For CCE 2.70 it was 29.97) But this did not confuse Mplex_hack. :)

Cheers
manolito

[Fishman0919]

I did a few AVI's.

720x416p 16/9 23.98fps = ok
720x480p 4/3 29.97fps = ok

[Sir Didymus]

@Fishman0919 --> :thanks:

@manolito. That's a consequence of the way Movie Length is retrieved. Actually the ECL file is searched only when both entries for "Length" and "Frames" are 0.

I admit it's not the best possible implementation, so the following beta 3 improves this simple check, trying to face also the issue you have experienced...

Edit 18/12/2007 - Link Removed; see first page of the thread for the most recent release...

It looks always for the three possilities ("Length" and "Frames" entries in the project file, plus the eventual content of the ECL file), assuming as valid length of the movie the maximum of the three...

[manolito]

Yes, beta 3 does the trick for me.
That's a consequence of the way Movie Length is retrieved. Actually the ECL file is searched only when both entries for "Length" and "Frames" are 0.Up to now I thought that when using CCE 2.70 the project file would always contain "Length=00:00:00" and "Frames=0". But this is only true in AVI2DVD mode. In DVD2DVD mode the "Frames" entry contains the correct source frames, but the ECL file has the encoded frames which is about the same if no frame rate conversion is specified in the AviSynth script. But for PAL2NTSC conversions the frame number in the ECL file is the correct one.

Could the new modification have broken any of the other modes which already worked perfectly? Need to retest?

Cheers
manolito

[Sir Didymus]

Could the new modification have broken any of the other modes which already worked perfectly? Need to retest?


In theory, unfortunately, yes, especially considering that now the presence of the ecl file is always checked... Sorry for this unpleasant implication...

However in practice the modified part is a single point in the source code (really just few lines), so I am quite positive that in case no obvious mistakes are quickly discovered, then a complete further testing is not needed...

Cheers,
SD

[bionic]

A little late to the party, ill join in and do some avi2dvd tests with beta3(pulldown and ntsc to pal)

[Sir Didymus]

Hi bionic!

You are not at all late :o

Hem, I would say you are perfectly in time, since the tests you are going to do are really needed!

Thanks in advance for your help...

Cheers,
SD

[manolito]

Just finished some more PAL DVD2DVD tests using CCE 2.70, QuEnc and HC. No matter if DVD chapters or fixed chapters were selected, Beta 3 always created the correct chapter points. :D

Will do some PAL AVI2DVD tests tomorrow...

Cheers
manolito

[manolito]

AVI2DVD tests finished, no problems at all!

I think I covered all possible PAL AVI2DVD combinations using CCE 2.70, QuEnc and HC. All this for straight PAL2PAL conversions plus two different PAL2NTSC methods (using DGPulldown and using ChangeFPS).

The Mplex log mostly had some complaints about inconstencies in it, but the Mplex_hack assumptions about frame rate and TV system were always correct.

I also killed D2S frequently and resumed using a different encoder. But whatever I did, I could not fool the current Mplex_hack beta.

So here in PAL country the current version is just perfect. If Bionic and Fishman have no objections then I think Beta 3 is ready for prime time.

Thank you very much again SD !

Cheers
manolito

[Sir Didymus]

Cool!

manolito, thanks to you for the systematic tests!

This time the Mplex_hack improvement from 1.2 to 1.3 was not simple... I have to admit it was not at all simple...

Let's wait for the report from Bionic before consolidating the new release...

;)

[bionic]

All done :)

1.ntsc (23.97) with pulldown = ok
2.ntsc (23.97) to pal = ok
3.ntsc (29.97) = ok
4.ntsc (29.97) to pal = ok

Seems good to go :)

[Sir Didymus]

Thanks for testing, bionic!

A am very happy about the good reports...

Edit 18/12/2007 -- Release 1.3 of Mplex_hack seems sufficiently stable. It is now included in the BatchMux package, version 1.8. See first page of the thread for the d/l link.

Also - Maybe it's a little bit early, but wanted to wish all of you a Merry Christmas and an happy new year...

Cheers,
SD

[manolito]

Thank you so much, SD.
Release 1.3 of Mplex_hack seems sufficiently stable. It is now included in the BatchMux package, version 1.8. See first page of the thread for the d/l link.
I have been using Version 1.3 beta 3 on an almost daily basis since it came out, and it did not fail one single time.

And also Merry Christmas and a Happy New Year to you!

Cheers
manolito

[bionic]

Just noticed the 1.8 release, thanks SD.
Havent had any problems here either, great work :)

All the best for the new year :)

[manolito]

Hi all,

MPUCoder just released the new free version 0.16.6 of Muxman. Just did a short test with Batchmux using this new version, and everything worked as before. So I think that there is no need to update the Batchmux plugin. :)

Hint: If you do not like the message window which pops up at every start of Muxman 0.16.6, a resource editor can take care of it...


Cheers
manolito

[Sir Didymus]

Hi to everybody... :)

It is long time since my last visit to the doom9 forums...

However, let me share at the link below:

Mplex_hack.zip - 27.7 Kb (http://www.uploadace.com/m7xbb5zo9glr/Mplex_hack.zip.html)

The version 1.4 of the Mplex_hack component for the BatchMux plugin.

The need to produce this new version was raised by Manolito :thanks:

We discussed via PM some while on this subject. He discovered one issue in the DVD chapter generation: when the last chapter is very short, it is easily possible that the authoring process fails. Now the duration of the last chapter is unified (in DVD chapters and in fixed chapters modes) and reduced to two seconds.

Cheers,
SD

[manolito]

Thanks Sir Didymus,

this update makes an already outstanding plugin even more perfect....:)

Here's a little more detailed explanation for the update:

I always had this one commercial DVD where Muxman would fail, and I thought it was just badly authored. But now I own at least 3 DVDs which exhibit this problem, and I figured it was time to address the problem.

When backing up these DVDs using "DVD Chapters" mode, Muxman would abort authoring with an error message like: Reference to non-existant scene "Segment_1_scn27" from PGC "VTS01_TTL01_PGC1". Upon further investigation I found this (from the ChapterXtractor readme):

On some DVDs, the last chapter doesn't exist really. (in fact
it's probably a logo, so check it length).
ChapterXtractor (when you check 'Last chapter bug fix') will auto
disable last chapter if it's length is less than 5s.
PowerDVD, WinDVD, SmartRipper confirm that this is a chapter, but
you probably don't want it.
And there is a thread at Videohelp:
http://forum.videohelp.com/threads/243408-MuxMan-Error

Muxman always pushes chapter points forward to the next I-frame (never backwards), and if the source DVD has a chapter within the last GOP, this chapter will be pushed to the next non existent I-frame causing Muxman to fail.

The Batchmux plugin already had a mechanism in place which prevented the last chapter being shorter than 10 seconds, but only in "Fixed Chapters" mode. Sir Didymus and I had an inspiring discussion about this topic via PM, and the result is this updated Mplex_hack.exe.

BTW this issue never came up when using Mplex / DVDAuthor in DVD2SVCD. The reason is simple: DVDAuthor does not complain if a requested chapter point is outside of the movie length, it simply ignores such a chapter. Muxman OTOH is very strict, instead of just writing a warning message into its log file it completely aborts the authoring process if it encounters a chapter point outside of the movie length.


Cheers
manolito

[DoctorM]

Hate to zombie the thread, but can anyone post a working link for v1.08?

[manolito]

Sure, here you go...
http://www.sendspace.com/file/pkype0


Cheers
manolito

[DoctorM]

Thanks. Been updating the components in my FAVC installation.