BatchMux plugin - MuxMan authoring with DVD2SVCD [Archive]

Sir Didymus

30th August 2006, 20:45

Here it is the link to release 1.8 of the BatchMux plugin:

http://www.mediafire.com/?z7gj3lxlxg1

1. What is BatchMux.zip ?
As the thread title say, it is a plugin to enable the usage of MuxMan inside DVD2SVCD.

2. BatchMux.zip contain a readme.txt file, describing with some details the steps to perform in order to install and use the plugin. The procedure is quite simple (setup DVD2SVCD to author with DvdAuthor, then point the three components Mplex, SpuMux and DvdAuthor to their hacked counterparts Mplex_hack, SpuMux_hack, DvdAuth_hack, included in the zip).

3. Enjoy DVD2SVCD with the authoring quality of Muxman !!!

- Thanks to Nick for its very very nice testing avi :cool:
- Thanks to manolito for the suggestions, the support, and the testing files.
- Thanks to the author(s) of DVD2SVCD for giving to the community this big, nice and and very complete backup suite!
- And finally a big thank you to Mpucoder: everybody all around here should be grateful to him for its enlightening contributions, discussions and great authoring program.

Edit 18-12-2007, Released version 1.8
- Unified the logic of the process for the different XXX2DVD modes
- Improved the code of acquisition for some parameters (movie length, framerate, pulldown flag) in order to be more robust in the scenarious of killing & resume of the XXX2DVD sessions.
- CAVEAT: quoting an appropriate warning, suggested by manolito, "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 !"

Edit 17-09-2007, Released version 1.7
Changelog (all related to Mplex_hack.exe component):
- Celltimes.txt file is now used back as a single chapter point format
- FPS entries are now used to detect the correct framerate, instead of the TV system alone...
- In framerate conversions now NTSC sources have always 30 frames per second...
- Changed: one frame less reported by GetMovieFrames from ecl files...

Edit 27-08-2007, Released version 1.6
Changelog:
1. Refinements (of the Mplex_hack.exe component). Reworked the handling of chapter points in order to provide higher precision, especially in case of NTSC + pulldown sources.
2. BugFix (of the Mplex_hack.exe component). Under some circumstances audio delay parameters handling was NOK. The issue is now solved.
3. Trying to use a different file upload service - Mediafire... They claim no time limitation for uploaded files... Let's see...

Edit 20-06-2007. Released version 1.5
Changelog:
1. Bugfix (of the Mplex_hack.exe component). The proper support for sources needing pulldown was nok. Solved. Thanks to Fishman0919 for the bug report, the excellent testing and the very appreciated support... Many thanks to manolito and to Nick who gave significant assistance and contributions on the same (not trivial) issue.
2. Bugfix + improvement (of the Mplex_hack.exe component). Audio delay parameters, when present in the mplex command line, were completely unsupported, breaking the plugin. These are now supported and passed to the authoring stage. Again many thanks to manolito for raising the issue up.
3. Version alignement (of the BatchMux.exe component). Release 1.0 of BatchMux.exe is now adopted. Due to the lack of support for the older releases, it is recommended to adopt this newer version of the authoring wrapper...

Edit 23-04-2007. Released version 1.4
Changelog:
1. Bugfix (of the SpuMux_hack.exe component). The support for srt subs was nok. Solved. Thanks to bionic for the bug report...
2. Improvement (of the Mplex_hack.exe component). It should be now able to directly support encodings based on CCE. Now chapters file should be properly created in case of CCE+fixed chapters. Very little testing performed, but it should work... Many thanks to manolito for the contribution...
3. Version alignement (of the BatchMux.exe component). Release 0.8 of BatchMux.exe is now adopted. It should have no impact for DVD2SVCD users...

Edit 03-10-2006. Released version 1.3
Changelog:
1. Bugfix (of the BatchMux.exe component). One change introduced in release 1.2 lead to the incorrect production of the muxman script, happening when no chapters are present in the title. The situation is quite rare, but still easily possible, in the DVD2SVCD usage.
2. Another bug is related to the wrong parsing of the -vidmode argument, never used in DVD2SVCD.
3. Slight functional improvements in the usage of the DvdProducer argument.
All of the above points are related to release 1.2, so, whoever downloaded and used release 1.2 is invited to update the plugin to version 1.3. People who is happy with release 1.1 may avoid to upgrade, since version 1.1 is still valid and effective. Sorry for the trouble.

Edit 24-09-2006. Released version 1.2
Changelog:
1. Just changed (quite heavily) the BatchMux.exe component. Other components unchanged. Since all of the implemented modifications do not - hopefully - have any impact on the plugin functionnalities for DVD2SVCD, people who is happy with release 1.1 is not specifically asked to upgrade to 1.2...

manolito

30th August 2006, 22:23

Thanks so much, SD!
Will start testing right away...

Cheers
manolito

manolito

31st August 2006, 00:10

Just did 3 short test conversions using DVD2DVD and AVI2DVD modes, and everything worked like a charm. In DVD2DVD mode I used 2 audio tracks and 3 sub streams without problems. In AVI2DVD mode I converted a captured AVI, first transcoding the audio from wav to mp2, then using Nick's AC3Enc plugin to convert audio to 2channel AC3. In both cases there also were no problems at all. Even the "chapter bug" with AC3ENC when using fixed chapters was magically gone!

Well, those were just some quick tests, and my folder structure for DVD2SVCD is simple (one work folder plus a separate folder for subs), but as far as I am concerned, BatchMux will be ready for a stable release very soon!

Thanks again to SD, this plugin really keeps DVD2SVCD at the top.

Cheers
manolito

Sir Didymus

31st August 2006, 10:27

...Even the "chapter bug" with AC3ENC when using fixed chapters was magically gone!

Hi manolito! :)

The reason is that now Mplex_hack generates a new chapter file for authoring (CellTimes.txt) starting from the chapters extracted from the DVD [if DVD chapters are used] or using just the Chapter length information available in the DVD.INI file [if fixed chapters are used]. In both cases the source information seems valid and unaffected by the "chapter bug".

The code used for the chapter generation is:

if (MovieFrames>MIN_FR_LAST_CHAP)
{
for (ChapPoint=ChaptersLength*VideoFps;
ChapPoint<MovieFrames-MIN_FR_LAST_CHAP;
ChapPoint+=(ChaptersLength*VideoFps))
{
fprintf(out,"%I64d\n", ChapPoint);
}
}

As a consequence, now the audio track is not involved any more in the calculation, and, in case of fixed chapters, the BatchMux plugin prevents the generation of a last chapter too short. Actually the parameter MIN_FR_LAST_CHAP is set to 10 seconds...

Cheers,
SD

manolito

31st August 2006, 13:42

Thanks for the explanation!

More test results:
I did a PVA2DVD encode over night, everything works perfectly.

Since I never use external subs, I don't know what else to test. I am completely happy with the plugin as it is now!

Thanks again,

Cheers
manolito

Sir Didymus

31st August 2006, 14:16

I am very happy too about what I hear so far... :)
Thanks to you for testing!

ChickenMan

6th September 2006, 05:04

Thanks Sir Didymus for a great plugin. :) I tried it last night in Batch mode on a few AVI's, with D2SRoba, Nicks AC3 batch file and your Muxman files and all worked perfectly together. Thank you.

One small problem however, I set the DVDAuthor's output folder to a different folder (normally on another HD) than set for the Default output folder. But the final VIDEO_TS folder is generated in the Default Output folder (where all the other DVD2SVCD files are generated) and not the folder I set. Can this be fixed?

As a minor request, is it possible to get the "Data Preparer" text as entered into DVD2SVCD imbeded into the output rather than the default text of "MPUCoder" produced by MuxMan ?

Keep up the good work, this has made DVD2SVCD the ultimate in AVI to DVD conversions.

Sir Didymus

6th September 2006, 10:07

...I tried it last night in Batch mode on a few AVI's, with D2SRoba, Nicks AC3 batch file and your Muxman files and all worked perfectly together...

Gulp...
I have to admit...
Never ever thought before to test BatchMux in Batch mode...
Lol... Nice to hear everything is almost ok...

One small problem however, I set the DVDAuthor's output folder to a different folder (normally on another HD) than set for the Default output folder. But the final VIDEO_TS folder is generated in the Default Output folder (where all the other DVD2SVCD files are generated) and not the folder I set. Can this be fixed?

This is a little "bug" in my brain, not in the plugin...
Hopefully it will be not difficult to fix... :cool:

Well, seriously, I take the opportunity of your question to spend few words about BatchMux.exe...

This is the "engine" of the plugin, which is basically a "wrapper" of MuxMan. BatchMux.exe is the single component of the plugin which is usable (and very useful, IMHO...) also outside DVD2SVCD - as a standalone command line application - enabling the usage of MuxMan with a rich set of command line arguments.

It is sufficient to launch it without arguments to get an help screen showing all of the supported options... This component is already fully parametric, needing no changes to implement what needs to be fixed.

The problem you discovered is a little design fault, depending ... hem ... on the limited analysis I did of the DVD2SVCD GUI... :o

Could you tell (or show) me what is exactely, in the GUI of DVD2SVCD, the panel and the editbox where you set the VIDEO_TS folder ?

As a minor request, is it possible to get the "Data Preparer" text as entered into DVD2SVCD imbeded into the output rather than the default text of "MPUCoder" produced by MuxMan ?

Mhhh. I don't know...
Basically, if it is possible to change the "MPUCoder" label through mxp scripting, the answer is yes...
But I am not sure on the matter...
I will check...

Keep up the good work, this has made DVD2SVCD the ultimate in AVI to DVD conversions.

Hei, thanks, ChickenMan.
DVD2SVCD is really a great suite...
and MuxMan is really a great authoring application...

Cheers,
SD

manolito

6th September 2006, 16:32

One small problem however, I set the DVDAuthor's output folder to a different folder (normally on another HD) than set for the Default output folder. But the final VIDEO_TS folder is generated in the Default Output folder (where all the other DVD2SVCD files are generated) and not the folder I set. Can this be fixed?This is a little "bug" in my brain, not in the plugin...
Hopefully it will be not difficult to fix... :cool:
Actually this should be very easy to fix. The "Authoring" folder can be found in DVD2SVCD.INI under "I-Author Folder". No problem for MPlex_Hack.exe to find this folder and create the VIDEO_TS folder there.
The reason for this little issue probably is that you cannot specify a folder for authoring under the "Misc" tab. This is because Mplex / DVDAuthor were added later to DVD2SVCD. Before this only Scenarist was supported, and there was no need to have separate folders for muxing and authoring.

Cheers
manolito

ChickenMan

6th September 2006, 17:35

Could you tell (or show) me what is exactely, in the GUI of DVD2SVCD, the panel and the editbox where you set the VIDEO_TS folder ?
You enter it in the DVD Image window with DVD Author selected as per

manolito

7th September 2006, 13:42

@ChickenMan
Until Sir Didymus releases a new version, there is an easy workaround for your problem. Batchmux creates the VIDEO_TS folder within the "Muxed" folder, not in the work folder. So you can just specify the desired output folder under the "Multiplexer" tab in DVD2SVCD. The "Mplex_Muxed_File00.mpg" which is also created in this folder is just a short dummy file.

Cheers
manolito

ADLANCAS

8th September 2006, 04:34

Is BatchMux (as a standalone command line application) able to create .mpg instead a .vob file ?

Sir Didymus

8th September 2006, 09:22

Actually this should be very easy to fix. The "Authoring" folder can be found in DVD2SVCD.INI under "I-Author Folder".

Ok! I see...

The reason for this little issue probably is that you cannot specify a folder for authoring under the "Misc" tab. This is because Mplex / DVDAuthor were added later to DVD2SVCD. Before this only Scenarist was supported, and there was no need to have separate folders for muxing and authoring.

Ok! I understand...
This is exactely the reason for the issue: in xxx2DVD modes, the I-Author button is not enabled; that made me assuming that all of the I-Author entries in the DVD2SVCD.INI file were unrelated to DVD Author, so I completely missed the authoring folder...

You enter it in the DVD Image window with DVD Author selected as per...

Ok!
I will fix the authoring folder issue with the next release of BatchMux - Hem... as soon as possible... in the early days of next week, most probably...

As a minor request, is it possible to get the "Data Preparer" text as entered into DVD2SVCD imbeded into the output rather than the default text of "MPUCoder" produced by MuxMan ?

Ok. Got it... It is the Preparer-ID field (32 bytes) in the video_ts.ifo...
It requires a little postprocessing step to be performed by the dvdauth_hack component...
It should also be available in the next release...

Is BatchMux (as a standalone command line application) able to create .mpg instead a .vob file ?

No. BatchMux.exe, as a standalone command line application, does not work as a muxer (i.e. it is completely different from ImagoMuxer or Mplex). It simply allows the usage of MuxMan with command line arguments. In other words it just launch MuxMan. The benefit (and the rationale for its existance) is that it does not require to write in advance a more or less complex script in order to use MuxMan: it takes the arguments, it create automatically a dedicated mxp script, and it launch MuxMan. That's all.

Cheers,
SD

manolito

8th September 2006, 12:42

Ok!
I will fix the authoring folder issue with the next release of BatchMux - Hem... as soon as possible... in the early days of next week, most probably...
Hi SD,
take your time, and I think you do not have to release the next version as Beta any more. I have been using your plugin exclusively since it came out, with 10 conversions at least, in AVI2DVD and DVD2DVD modes, and there simply is nothing to report. It just works perfectly!

Thanks and Cheers
manolito

Nick

8th September 2006, 12:52

Agreed. I have tested it with a number of DVD's and AVI's and even with files I have kept only for testing purposes due to their problematic nature. I just can't break it whatever I try :)

Good work SD. Added to the plugins sticky.

manolito

11th September 2006, 13:31

Just one quick question I'd like to ask before the final version comes out:
XmlFile set to --> I:\Movies\DVDAuthor.xml
WorkingFolder set to --> I:\Movies
Authoring Folder set to --> I:\Movies\VIDEO_TS
Mux Folder set to --> I:\Movies
Audio 0 set to --> --

This is the last part of the DVDAuthor log, right after the Muxman log. Audio 0 is set to nothing. Does this indicate a problem? The encode is just fine, the (one) MP2 audio track was muxed into the stream perfectly.

Cheers
manolito

/Edit
Too late, I just noticed that version 1.1 is already online. Downloading already...

Sir Didymus

11th September 2006, 13:36

You may find the link and the changelog in the first post of the thread...

Hem... apart the critical bugfix related to folders containing spaces, I did some large cleaning and review in the code, so better still considering the plugin as a beta, for a little while...

Future plans:

1. Short term: Bug fixing...

2. Medium term: Adding some multi VTS capabilities in BatchMux.exe. This will have no impact for DVD2SVCD users, but will make the core component of the plugin a little bit more general, making it more appealing for other usage, as a standalone application...

3. Long term: External encoding of the subpictures. Actually the Scenarist SST format is used. Adopting the Ifoedit SUP format seems leading to a significant speed up of the authoring, when a large number of subtitle streams is used...

Cheers,
SD

Sir Didymus

11th September 2006, 13:42

Oops...

Sorry manolito...
I was just uploading the file while you were posting...

Well, the "--" string is related to the audio language, and it means that the language is not specified...

If you set it in the the GUI to a specific language, it should be obeyed...

Anyway, it is a perfectly legitimate value...

Cheers,
SD

P.S. You will notice the log files changed a little bit... just formatting and readability... the content is more or less unchanged... Now the string above should read as "Audio 0 language --> -- "

manolito

11th September 2006, 13:57

Alright, cool!
And I really think you should announce the core BatchMux application in the Authoring thread also. I believe it certainly is stable enough to be useful for many Muxman users.

Cheers
manolito

manolito

11th September 2006, 20:13

Just finished a resumed mux / author session with the new version. I changed the target folder for the VIDEO_TS folder, and the report is very short:
Muxing / authoring was uneventful, everything worked as exspected. Which means that reviewing and cleaning the code seems to not have introduced any problems.

Cheers
manolito

ChickenMan

13th September 2006, 10:21

Just tried the new ver 1.1, works exactly as expected for me :) many thanks SD.

Sir Didymus

13th September 2006, 11:42

...Which means that reviewing and cleaning the code seems to not have introduced any problems...
...Just tried the new ver 1.1, works exactly as expected for me...

good reports...
me too tested a little bit more...
it seems this release 1.1 is quite solid... :-)

happy authoring!

Matthew

15th September 2006, 00:30

2. Medium term: Adding some multi VTS capabilities in BatchMux.exe.

Just curious, how will you do this?

Personally I included the structure/data in directories/filenames (e.g. VTS01_TIT01/P_OL_blah.m2v).

Sir Didymus

15th September 2006, 09:50

Hi Matthew! :)

Just for the benefits of casual readers, please remind BatchMux.exe (the authoring component of the BatchMux plugin) is a MuxMan wrapper. Nothing more nothing less.

Into this next medium term release, BatchMux.exe will have no navigation support, meaning that it will be able to use MuxMan 15P for producing DVD titles with multiple VTS, but all of the the navigation (including PGC precommands and postcommands) will be hardcoded, in order to perform a straight playback of the VTS, just one after the other...

In other terms, for the moment, no CLI arguments will be available in BatchMux.exe in order to do any organisational or navigational tasks [the "spreadsheet" and the "navigation", just to adopt the MuxMan terminology, will be added - if even - in a second time, i.e, future developments].

The definition of the BatchMux.exe frontend (the list of CLI arguments) is actually completed and it is totally conservative respect to the one available in the DVD2SVCD plugin version 1.1. I am especially happy about this because it will imply no changes of the other components, inside the plugin itself, carrying out the BatchMux arguments preparation.

Keeping the assets of the different VTS in different folders before authoring is a good practice. I do almost the same as in your example. BatchMux.exe is totally happy with this. To say the thruth, one of the reasons for the development was exactely the speed up of the re-authoring of different VTSs, in doing DVD backups, with a command line program.

Let me go deeper into this... Assuming you are in a scenario where you need to reauthor a DVD with two or three different VTS, one related to the main feature and two to the extras. In order to rehauthor the first VTS, you have to type, in a dos shell, in the folder where the main feature assets are placed, the needed BatchMux.exe commands (and that takes more or less the same as doing the job in the MuxMan GUI).

But then, all you need to do with BatchMux to author other VTS, in the different folders, is to move to these folders and recall the same command previously issued, just doing little tuning for changing some parameters (e.g. audio strams). That takes much less than redoing the job with the MuxMan GUI...

If you are so curious as you say, maybe you'd like to get a look at the CLI frontend for the next release (it will take a couple of weeks, more or less to complete the coding of version 0.5...)...

//
//============================================================================
//= BatchMux - version 0.6: Wrapper to use MuxMan 0.15P as a CLI application =
//= --> Limited functionalities but - No scripting + CLI interface :-) =
//============================================================================
//
// First release 18-07-2006
// Version 0.2 26-07-2006
// Version 0.3 19-08-2006
// Version 0.4 11-09-2006
// Version 0.5 24-09-2006
// Version 0.6 03-10-2006
//
//
// Arguments:
//
// -d destination_folder, mandatory
// -mxp target script_file, optional; default to C:BatchMux.mxp
// -l log_file, optional; default to C:MuxMan.log
// -muxman folder, place where to look for the MuxMan.exe file, optional, default
// NULL string, meaning the same folder where BatchMux is executed
// -palette palette_file, optional; ascii file with 16 colour entries (index,
// red, green, blue) adopted for redefining the default color palette
// used by MuxMan
// -preparer "32_char_string"; optional copyright string setting the DVD preparer
// field in the VIDEO_TS.IFO and VIDEO_TS.BUP files. Note: it is overridden
// by the -norun option
// -norun allows to open the MuxMan GUI, to load the script file and to stop
// -[SEGi]v video_file, mandatory; note: in all of the arguments with the
// "SEGi_" prefix, the i index should be an integer value, in the range
// [2...99]; also, segments sequence should be progressive: e.g if segment
// 4 is missed, all segment arguments from 5 to 99, if present, are ignored
// -[SEGi]vidmode 4:3 | PS_LB | PS | LB display mode for the video file,
// optional, if present and compatible with the actual video mode, it is
// honored, based on the authoring application rules; if not present, it is
// not included in the script
// -[SEGi]a1 audio1_file ... -a4 audio4_file; all optional;
// -[SEGi]a1lang xx ... -a4lang xx two characters language code for the audio
// files, all optional; default unspecified
// -[SEGi]a1ext 0|1|2|3|4 ... -a4ext 0|1|2|3|4 language extensions for the audio
// files, where 0 --> unspecified, 1 --> normal, 2 --> visually impaired,
// 3 --> director comments, 4 --> alternate director comments; all optional;
// default 1 - normal
// -[SEGi]a1delay xxx ... -a4delay xxx audio delays, positive and negative
// values, in ms, in the range [-300...300]; all optional; default 0
// -[SEGi]s1 subpic1_file ... -s8 subpic8_file; all optional
// -[SEGi]s1lang xx ... -s8lang xx two characters language code for the subpic
// files, default unspecified
// -[SEGi]s1ext 0|1|2|3|5|6|7|9|13|14|15 ... -s8ext 0|1|2|3|5|6|7|9|13|14|15
// language extensions for the subpicture files, where 0 --> unspecified,
// 1 --> normal, 2 --> large, 3 --> children 5 --> normal captions,
// 6 --> large captions, 7 --> children captions, 9 --> forced,
// 13 --> director comments, 14 --> large director comments,
// 15 --> children director comments; all optional; default 1 - normal
// -[SEGi]s1dmode LB | PAN | LB_PAN | WIDE | WIDE_LB | WIDE_PAN | WIDE_LB_PAN
// ...
// -[SEGi]s8dmode LB | PAN | LB_PAN | WIDE | WIDE_LB | WIDE_PAN | WIDE_LB_PAN
// display modes and track assignement for the subpicture streams;
// all optional; default --> unspecified if video A/R is 4:3,
// default --> WIDE_LB if video A/R is 16:9
// -[SEGi]celltc timecode_file; optional file containing chapter points in the
// hh:mm:ss:ff - 11 char fixed ndtc format
// -[SEGi]cellfr celltimes_file; optional file containing chapter points in the
// "usual" CellTimes format - plain frame indexes
//

Edit: reference code update to release 0.6...

Matthew

16th September 2006, 06:38

But then, all you need to do with BatchMux to author other VTS, in the different folders, is to move to these folders and recall the same command previously issued, just doing little tuning for changing some parameters (e.g. audio strams). That takes much less than redoing the job with the MuxMan GUI...

So each VTS multiplex operation will be performed using its own separate mxp script then?

If this is the case...how does implementing menu support fit into this?

Note that I have no intention of switching to your app as my own script generation suits me better atm (I have my own tools to demux dvds and perform avi->m2v/ac3 to the required input conventions), but I'd be quite happy to pinch any useful ideas ;)

Sir Didymus

16th September 2006, 14:55

So each VTS multiplex operation will be performed using its own separate mxp script then?

Yes, but just in the example I gave, that was describing some benefits of CLI... BatchMux, on its own, generates always a single script per session... The example I made, was intended to show, in case your reauthoring process implies multiple Muxman sessions, that adopting the CLI of BatchMux may speed up significantly the overall process. In this scenario you need usually other tools (demuxers, encodeers, and finally VobBlanker by Jsoto) to build up the reauthored DVD...

If this is the case...how does implementing menu support fit into this?

For the moment (or better, for the next release...) BatchMux will build up a single mxp script, allowing the generation of multiple VTS - one VTS per segment in the title domain. Organisational tasks, like placing segments in the VMG domain, or placing more than a segment into the same VTS, will be not supported atm... Maybe in a second time...

Note that I have no intention of switching to your app as my own script generation suits me better atm (I have my own tools to demux dvds and perform avi->m2v/ac3 to the required input conventions), but I'd be quite happy to pinch any useful ideas...

Well, I now understand better your question - sorry English is not my mother tongue, so I have sometimes troubles with this...

I am happy with your statement :-) I mean, I am aware advanced users of MuxMan would take advantage by BatchMux just for speeding up some ripetitive tasks, while other people, less familar about writing and modifying mxp scripts may be happier about BatchMux.exe...

But first of all I have to admit I should spend some words to describe very clearly what BatchMux is and what it does...

If you want to get a look to some samples of the scripts produced by BatchMux.exe, please PM me, or just wait some little while: I will post (in the proper forum, the Authoring one - I don't want to go too much OT here...) the next release of BatchMux.exe, together with some description and examples...

Cheers,
SD

Matthew

20th September 2006, 00:33

BatchMux, on its own, generates always a single script per session

Yup, I see that now...the command could get very long though, e.g. if there were lots of vtss and audio and subtitle streams.

Sir Didymus

21st September 2006, 11:20

Yes... :)
That's right... the length is proportional to the complexity of the project...
It takes more or less the same time as selecting and entering the entries in the GUI...
The nice aspect of the CLI is that, if needed, you can "recall", and then change and/or reuse the whole project with a single keystroke...

Sir Didymus

24th September 2006, 15:53

Release 1.2 of the plugin is available. It is an evolution step, not changing the plugin functionnalities for DVD2SVCD users, so whoever is happy with release 1.1 is not specifically suggested to switch to 1.2. The link is in the first post of the thread...

The single BatchMux.exe component has been changed (significantly) respect to release 1.1.

Since this (authoring) component of the plugin may be used outside of the plugin itself, some further details about BatchMux.exe are given in the authoring forum...

I did nor receive bug reports on the previous release, so I think both 1.1 and this 1.2 con be considered as stable versions...

Cheers,
SD

manolito

18th March 2007, 01:18

Here is a small extension for BatchMux users which does two things:

It overcomes a chapter creation issue when using CCE 2.70

It allows almost automatic PAL to NTSC conversion

Download here:
http://scifi.pages.at/manolito/CCE270/D2S_CCE2.70.zip

Cheers
manolito

bionic

31st March 2007, 15:38

You guys are doing an excellent job evolving d2s like this, much much appreciated :)

Unfortunately i do seem to have a problem with the batchmux plugin(latest version), i cant get subs to work when doing avi2dvd(havent tried any other modes)
D2s always errors out in the spumux stage, with a SpuMux failed for unknown reasons error.

I suspect it has something to do with the muxing stage as Mplex_hack produces a nonfunctional 12kb muxed file and a 0kb muxed subbed file, but thats a very uneducated guess. It does produce a 12kb file when doing no subs too though but the authoring still finishes proper.

Ive gone through the logs but id rather leave the interpretation to you experts.
Please take a look.

http://fileho.com/download/3b57f3397560/logs.rar.html

Nick

31st March 2007, 19:00

Seems to be a very odd AVI you're converting...
According to the logs, it's only a couple of minutes long (5055 frames) and audio conversion took less than a second :confused:

Try playing back the extracted and encoded audio files.

Is this as it expected? If not I suspect a corrupt AVI. The VDubMod trick in the AVI-problems sticky may help reconstruct it.

bionic

31st March 2007, 19:24

Thx for replying :)

Should have mentioned..Its just a clip i use to test, its an xvid with 2ch ac3 audio 3.30 mins long.

Have tried many different avi sources with both ac3 or mp3 audio. The moment subs are involved the batchmux plugin fails.
To sum up.
default dvdauthor and muxers with subs =ok
imago with subs =ok
imago+your excellent ac3 plugin and subs =ok
Batchmux =ok
Ac3plugin+batchmux =ok

batchmux with subs=error
Ac3plugin+batchmux with subs=error

Sir Didymus

31st March 2007, 19:41

Hi Bionic!

I will get a look asap to the logs. I have to say that the subs support, at the time of the development of the plugin was one of the most complex (and estensively tested) features implemented. I will report back to you as soon as I get a look to the logs...

Cheers,
SD

EDIT: OK. Just got through the log files... It seems that the first subpicture in your srt file has been converted, then the plugin broke down. Your info about the "strange" filesizes of some of the generated files are related to the normal behaviour of the plugin. It should generate a single bmp file for each of the png in the source directory, and then it should generate a sst file to import within muxman. In order to understand what it's going on it should be very helpful if you can post or send to sir_didimus (at) libero.it the original srt, in order to replicate the bug...

EDIT2: OK. I got through the segment of code, in spumux_hack, producing the error reported after the reading of the first picture in the srt file. I suspect that your source srt has been manually edited, breaking the srt format. According to the description here:

http://www.matroska.org/technical/specs/subtitles/srt.html

the srt assets should be composed by (a list of):
1. A number indicating the which subtitle it is in the sequence.
2. The time that the subtitle should appear on the screen, and then disappear.
3. The subtitle itself.
4. A blank line indicating the start of a new subtitle.

In the implementation supported by spumux_hack, each one of the items above should be present and it should be contained in a single line of the srt file...

bionic

1st April 2007, 13:05

Thx for looking into it.
I have sendt you the subs.

Sir Didymus

1st April 2007, 14:19

I see; it's a limitation of the current implementation supported by spumux_hack, that allows just a single line of text for each subtitle item in the srt file.

As I just checked, multiple lines should be supported, since the srt format allows them.

Involved modifications of the code are quite easy to implement. Tomorrow, most probably, I will send to you a PM with an updated version of spumux_hack.exe. It is the single component of the plugin affected. In case it solves the bug, I will distribute a new release of the plugin with the bug fix.

Many thanks for reporting the problem!

Cheers,
SD

bionic

2nd April 2007, 13:08

Np, just glad i didnt waste your time.

I have recieved your pm and have tested with and without subs and im glad to report its now working proper.
Excellent work, thank you :)

Sir Didymus

2nd April 2007, 15:48

OK. Excellent. I had also some doubts regarding the other sub format supported (MicroDVD) but it seems it shouldn't be affected by the same issue you have discovered...

So, thanks again for the report and testing...

Now that an update release of the plugin is necessary, I think it could be nice to take the opportunity for including in the plugin also the support to the usage of CCE 2.70, as provided by the brilliant solution of manolito, few post above...

All the best,
SD

ChickenMan

21st April 2007, 03:37

Sir Didymus, are you going to release your modified plugin that appears to have fixed the SRT subs problem. I ask as I have been having the same problems as bionic reported :(

Sir Didymus

23rd April 2007, 13:29

Hi ChickenMan!

Afraid for the time it took to upload the new version of the plugin. You can get it at the first page of the thread...

Three component are updated in release 1.4 of the plugin:

1. the SpuMux_hack.exe component. The support for srt subs was nok. Solved. Thanks to bionic for the bug report...

2. the Mplex_hack.exe component. It should be now able to directly support encodings based on CCE. Now chapters file should be properly created even when CCE 2.7 is used. I did few testing on this, but I am quite confident it should work... Some confirmation will be appreciated...

3. the BatchMux.exe component. Release 0.8 of BatchMux.exe is now adopted. I am active on the developments related to this component, since other applications (like FAVC) may get significant benefits (for example in supporing menus in the batchmux sessions). It should have no impact for DVD2SVCD users, however...

Cheers,
SD

manolito

23rd April 2007, 21:30

Hi SD,

thanks for the update. I cannot test the new Spumux_hack file (I never use subs), but I did test CCE 2.70 fixed chapter creation. Works like a charm.

Cheers
manolito

bionic

23rd April 2007, 22:34

Manolito! thank you much sir for your work on evolving d2s

Sir Didymus, thank you for the updated plugin.
Are there any changes to spumux_hack other than those implemented when i tested it?

Sir Didymus

24th April 2007, 10:51

Hi manolito!

...but I did test CCE 2.70 fixed chapter creation...

Excellent!
:)

@bionic:
no; the spumux_hack component is the same I sent to you as a beta...

For whoever is interested in using the authoring component of the plugin (BatchMux.exe) outside DVD2SVCD, please consider that the release 0.8 of this component have a nasty bug (the file composer is broken). This have no impact for DVD2SVCD users, since this feature is not used in the plugin. However, the bugfix release of this component is available here (original thread in the authoring forum):

http://forum.doom9.org/showthread.php?t=116297

Cheers,
SD

ChickenMan

24th April 2007, 14:41

Sir Didymus, thanks for the updates, very much appreciated and keep up the good work :)

Fishman0919

20th May 2007, 17:18

Having a problem getting BatchMux plugin started....

getting this error...

DvdAuth_hack: Version --> 0.5
XmlFile set to --> C:\Program Files\DVD2SVCD\Movie\DVDAuthor.xml
WorkingFolder set to --> C:\Program Files\DVD2SVCD\Movie
Authoring Folder set to --> C:\Program Files\DVD2SVCD\Movie\VIDEO_TS
Mux Folder set to --> C:\Program Files\DVD2SVCD\Movie
Audio 0 lang set to --> en
Error opening File C:\Program Files\DVD2SVCD\Movie\Mplex_hack_dat.txt

Sir Didymus

21st May 2007, 09:11

Hi Fishman0919!

Could you post also the log file produced by Mplex_hack ?

It is supposed the missing configuration file needed by DvdAuth_hack is produced by Mplex_hack...

Cheers,
SD

Fishman0919

21st May 2007, 13:09

Sure, I'm at work now... I uninstalled and reinstalled DVD2SVCD and start the disc over again.... will post when I get home.

Fishman0919

21st May 2007, 23:57

Sorry, seems to be working fine now after reinstall everything....

but I noticed the chapter points are not correct for dvd to dvd

Sir Didymus

22nd May 2007, 08:40

Well, to say the truth I am aware of a small glitch in the DVD2SVCD process affecting the positioning precision of the chapters...

:rolleyes:

The result is that, in average, the chapter positions can be ensured only within +/- 1.2 seconds (1 GOP). Are you referring to this effect or to something more critical ?

...If this is the case, I always assumed nobody would care about, since the glitch was present before the development of the BatchMux plugin, and the issue was not raised in the forum posts of the last two/three years... It seems the missed inclusion of the chapter points among the encoder parameters is the cause...

The problem is present for all x2DVD modes and both for dvd chapters and fixed chapters.

However, better to ask to Nick for some confirmation on the matter...

:)

Cheers,
SD

Fishman0919

22nd May 2007, 12:15

The result is that, in average, the chapter positions can be ensured only within +/- 1.2 seconds (1 GOP). Are you referring to this effect or to something more critical ?

No, they are way off.... 5, 10 sec... 1, 2 mins off

If I use dvdauthor.exe they are within +/- 1.2 seconds

Running new disc now... will post after complete

Sir Didymus

22nd May 2007, 12:51

That's really odd, if confirmed... :confused:

Just checked in the code...
In case of DVD chapters, the process performed by Mplex_hack for producing the celltimes.txt file is straightforward...

It simply looks for the file "dvd2svcd chapters file.ini" in the source folder, copying the chapters points, one to one, from one file to the other...

Fishman0919

22nd May 2007, 13:23

The movie is The Painted Veil R1... I run it on one pc with dvdauthor.exe and one with BatchMux both using HC .21. Both completed but the one done with BatchMux has the chapter points off. I used chapterxtractor and got the chapter points from the rip file from DVD2DVD. I then manually author it with Muxman and that worked fine.... chapter point are correct.

Sir Didymus

22nd May 2007, 14:25

So, I am interested on three files in your system:

1) The "dvd2svcd chapters file.ini" in your source folder
2) The Celltimes.txt in your working folder, produced by the BatchMux plugin
3) The Celltimes.txt, which is working fine when manually authored, extracted with chapterxtractor

Could you check for the differences among the three ?
Or post them, or send to me at:
sir_didimus (at) libero.it

Thanks!
SD

manolito

22nd May 2007, 21:30

Here in PAL land I cannot reproduce the problem. Did some short test encodes using HC 0.21 and CCE 2.70, and in all cases the chapter points were the same.

Could this be a NTSC issue? DVDAuthor gets its chapter information in absolute time values (like 01:55:12) while BatchMux needs frame numbers. So for BatchMux the frame rate has to be considered also.

Is there any frame rate conversion involved in the conversion process? Like going from hard telecined to soft telecined or vice versa?

Cheers
manolito

Mr_Odwin

22nd May 2007, 21:41

An issue that I had with Muxman was that the frame numbers used as chapter points assume an NTSC framerate of 30 instead of 29.97. Could this be the issue? If the difference drifts slowly over the title then it's possible this is the case.

Fishman0919

22nd May 2007, 22:47

This is from Matrix Revolutions R1... I already had it rip As an .ISO on my HD

dvd2svcd chapters file.ini

[CHAPTERS]
Chapter0001=0
Chapter0002=5616
Chapter0003=10836
Chapter0004=14833
Chapter0005=21177
Chapter0006=25833
Chapter0007=33853
Chapter0008=43280
Chapter0009=51173
Chapter0010=56893
Chapter0011=61804
Chapter0012=67180
Chapter0013=70524
Chapter0014=74624
Chapter0015=83424
Chapter0016=86740
Chapter0017=89876
Chapter0018=97816
Chapter0019=101372
Chapter0020=107236
Chapter0021=112736
Chapter0022=119588
Chapter0023=123588
Chapter0024=128369
Chapter0025=132120
Chapter0026=139305
Chapter0027=146592
Chapter0028=150852
Chapter0029=155496
Chapter0030=160441
Chapter0031=165544
Chapter0032=169033
Chapter0033=172896

CellTimes.txt

5616
10836
14833
21177
25833
33853
43280
51173
56893
61804
67180
70524
74624
83424
86740
89876
97816
101372
107236
112736
119588
123588
128369
132120
139305
146592
150852
155496
160441
165544
169033
172896

ChapterXtractor chapters.txt

0
7020
13545
18541
26471
32291
42316
54100
63966
71116
77255
83975
88155
93280
104280
108425
112345
122270
126715
134045
140920
149485
154485
160461
165150
174131
183240
188565
194370
200551
206930
211291
216120

I set ChapterXtractor to 30 fps

again the BatchMux ver is off but the manually author Muxman is right on

An issue that I had with Muxman was that the frame numbers used as chapter points assume an NTSC framerate of 30 instead of 29.97. Could this be the issue? If the difference drifts slowly over the title then it's possible this is the case.

yep, with 29.97 fps by the end of the movie the chapters are off

but in this case I talking mins off not just a few frames or sec

manolito

23rd May 2007, 00:53

I think I figured it out:

DVD2SVCD always calculates the chapter frame numbers based on the encoding frame rate. For a NTSC telecined film this would be 23.976 fps. After the encode Pulldown is applied to reach the required playback rate of 29.97 fps. This means that all DVD2SVCD chapter points will be off.

I wrote a small batch file to verify my theory:

:fixparams
IF !%1 == !-f GOTO getfolders
SHIFT
GOTO fixparams

:getfolders
SET Muxed_Folder=%~dp4

SET commandline=%1
:loop
SHIFT
IF !%1==! GOTO mplex_hack
SET commandline=%commandline% %1
GOTO loop

:mplex_hack
mplex_hack.exe %commandline%

Copy %Muxed_Folder%CellTimes.txt OldChp.txt
IF EXIST NewChp.txt DEL NewChp.txt
FOR /f %%a IN (OldChp.txt) DO CALL :Write %%a

COPY NewChp.txt %Muxed_Folder%CellTimes.txt
IF EXIST ???Chp.txt DEL ???Chp.txt

EXIT

:Write
SET /A Chapter=%1 * 29970 / 23976
ECHO %Chapter% >> NewChp.txt

Save this file as "Pulldown_Mplex_hack.bat" and save it in your DVDAuthor folder. Then point DVD2SVCD to this batch file instead of the original "Mplex_hack.exe".

If it works then Sir Didymus has some work to do. :devil:

The chapter points only have to be recalculated if DVD2SVCD applies Pulldown (or if DGIndex decides that Force Film has to be applied). For PAL nothing has to be done, and for NTSC real interlaced video also no recalculation should be necessary.

Please let me know if it works...

Cheers
manolito

Fishman0919

23rd May 2007, 05:12

Sorry, no good... same result

CellTimes.txt

11972
18792
27748
33320
46856
54312
69740
81517
87604
99624
112520
119780
132644
148357
158601
169408
184292
186797

ChapterXtractor chapters.txt

0
14966
23490
34685
41650
58570
67890
87175
101896
109505
124530
140650
149725
165805
185446
198251
211760
230365
233496

Sir Didymus

23rd May 2007, 09:23

I think I figured it out:

DVD2SVCD always calculates the chapter frame numbers based on the encoding frame rate. For a NTSC telecined film this would be 23.976 fps. After the encode Pulldown is applied to reach the required playback rate of 29.97 fps. This means that all DVD2SVCD chapter points will be off.

I wrote a small batch file to verify my theory...

If it works then Sir Didymus has some work to do. :devil:
...
Please let me know if it works...

Cheers
manolito

Me too I think Sir Didymus has some work to do... :cool:

From the logs of Fishman0919 it is clear your explaination is correct: all chapter point should be multiplied by the factor of 1.25 when DVD2SVCD applies pulldown flags to an NTSC source.

The problem is: how to implement the bugfix in a clean way ?

I have a couple of NTSC DVD in my collection... Not sure about they are telecined or not, however. I will try to replicate the issue on my PC in the next days...

For the moment thanks to Fishman0919 for the bug report and the testing and double thanks to manolito for the support and co-operation in the developement and improvement of the BatchMux plugin...

The bug will be fixed ASAP, I am quite confident about...

EDIT: Hmmm... Maybe I have a nice idea...

:sly:

I noticed that apart the "dvd2svcd chapters file.ini" file, also the "DVD Maestro Chapters File.chp" is produced by DVD2SVCD. This file (apparently) contains chapters in the standard NDTC format: hh:mm:ss:ff. Using this file instead of the former, since BatchMux.exe is already enabled to accept this format, should solve the issue...

Am I right ?

Are there any implications in adopting always this second timecode file instead of the classical Celltimes.txt ?

Cheers,
SD

Nick

23rd May 2007, 12:13

EDIT: Hmmm... Maybe I have a nice idea...

:sly:

I noticed that apart the "dvd2svcd chapters file.ini" file, also the "DVD Maestro Chapters File.chp" is produced by DVD2SVCD. This file (apparently) contains chapters in the standard NDTC format: hh:mm:ss:ff. Using this file instead of the former, since BatchMux.exe is already enabled to accept this format, should solve the issue...

Am I right ?

Are there any implications in adopting always this second timecode file instead of the classical Celltimes.txt ?

Cheers,
SD

There is one. If the conversion is done from AVI, the DVD Maestro chapters file is empty. So if chapter info is gained from this file, AVI-to-DVD conversions will presumably have no chapters.

Sir Didymus

23rd May 2007, 14:12

OK. When I wrote "always" I really meant "both for PAL and NTSC, in the dvd2dvd + dvd chapters mode".

In the avi2dvd mode, the DVD chapters option is meaningless right ? I mean, only fixed chapters are possible in this case, and for fixed chapters the overall process is not affected by this bug...

Do you agree ?

Nick

23rd May 2007, 14:15

Doh! Yes, my bad.

Sir Didymus

23rd May 2007, 14:20

:)

So, it takes more to discuss than to code it...
I hope to have a new beta to test soon...
this evening, most probably...

Cheers,
SD

manolito

23rd May 2007, 14:56

Fishman0919

23rd May 2007, 15:10

@fishman0919
I just ran my quick and dirty batch file here, and it worked. The batch file has to be in the same folder where Mplex_hack.exe is located (probably, but not necessarily the DvdAuthor folder).

Cheers
manolito

I have a sub folder in DVDAuthor ... BatchMux

C:\Program Files\DVD2SVCD\DVDAuthor

C:\Program Files\DVD2SVCD\DVDAuthor\BatchMux

I put all the files, both Mplex_hack.exe and Pulldown_Mplex_hack.bat are there.

I am running a new disc now, just about fininhed encoding.

Will let you know the results.

manolito

23rd May 2007, 16:34

OK, just finished testing another workaround which should work for any source, whether Pulldown is involved or not.

This time I hijack the authoring process, not the muxing. Here is the file, I call it "Run_DvdAut_hack.bat"

SET Muxed_Folder=%~dp2
%SYSTEMROOT%\system32\FIND "SourceFolder" /i "%Muxed_Folder%MPlex_log.txt" > temp.txt
FOR /f "tokens=1,2 delims=--> " %%a IN (temp.txt) DO SET SourceFolder=%%b\
IF EXIST temp.txt DEL temp.txt

%SYSTEMROOT%\system32\FIND /C "Pulldown=No" "%SourceFolder%dvd2svcd project file.d2s"
IF NOT ERRORLEVEL 1 goto Author

Copy %Muxed_Folder%CellTimes.txt OldChp.txt
IF EXIST NewChp.txt DEL NewChp.txt
FOR /f %%a IN (OldChp.txt) DO CALL :Write %%a

COPY NewChp.txt %Muxed_Folder%CellTimes.txt
IF EXIST ???Chp.txt DEL ???Chp.txt

:Author
DvdAut_hack.exe %1 %2
EXIT

:Write
SET /A Chapter=%1 * 125 / 100
ECHO %Chapter% >> NewChp.txt

Put the file where "Dvd_Aut_hack.exe" is located and point DVD2SVCD to this batch file instead of the original "DvdAut_hack.exe". (Make sure to get rid of the previous batch file which hijacked "Mplex_hack.exe")

How it works:
The file needs to get the "Source Folder" where the D2S project file is located. This information is extracted from the Mplex log file. Then the project file is searched for the "Pulldown=" entry. If "Pulldown=No" then DvdAut_hack.exe is called without doing anythig, otherwise the chapter points are modified.

Cheers
manolito

Sir Didymus

23rd May 2007, 16:46

But I see a problem in DVD2DVD mode when fixed chapters are selected. In this case the chapter files created by D2S are both empty, but you still cannot use the old way of chapter creation when Pulldown is used.

In this case Mplex_hack.exe calculates the chapter points from the movie length which it reads from the D2S project file, right? This routine also must be modified. It is actually pretty easy, because there is an entry in the project file "Pulldown=No" or "Pulldown=Yes". If yes then the the chapter points have to be multiplied by 1.25.
...

You are right!
Actually fixed chapters are calculated until the upper boundary of MovieFrames is reached. This value should also be scaled. (I mean, actually the effect of the bug should consist in the fact that the chapter points should be precise but the last chapters are most probably missed)...

Your suggestion of reading (and using) the Pulldown=No or Yes flag is much clean than my previous idea...

Do you know if this Pulldown=No or Yes flag is set both in avi2dvd and in dvd2dvd mode ?

Cheers,
SD

EDIT: be careful. If you hack the process at the authoring stage you change the chapter points both for the avi2dvd and for the dvd2dvd mode. When the mode is avi2dvd (fixed chapters), actually - IMHO - the effect of the bug is not the underestimation of the chapter points of the factor of 1.25, but the missed inclusion of the last chapters in the celltimes.txt file. Actually the code used for the fixed chapters generation is the following (in case of NTSC VideoFps --> 30):

// fixed chapters generation
if (MovieFrames>MIN_FR_LAST_CHAP)
{
for (ChapPoint=ChaptersLength*VideoFps;
ChapPoint<MovieFrames-MIN_FR_LAST_CHAP;
ChapPoint+=(ChaptersLength*VideoFps))
{
fprintf(out,"%I64d\n", ChapPoint);
}
}

manolito

23rd May 2007, 17:32

Do you know if this Pulldown=No or Yes flag is set both in avi2dvd and in dvd2dvd mode ?

Yes, the pulldown flag is also used (and of course set to NO) in AVI2DVD mode.

EDIT: be careful. If you hack the process at the authoring stage you change the chapter points both for the avi2dvd and for the dvd2dvd mode. When the mode is avi2dvd (fixed chapters), actually - IMHO - the effect of the bug is not the underestimation of the chapter points of the factor of 1.25, but the missed inclusion of the last chapters in the celltimes.txt file.

Well, I do not see any problems with this approach so far. Remember that my batch file only jumps into action if "Pulldown=Yes". If "Pulldown=No" which is true for all AVI2DVD conversions, the batch file does absolutely nothing. It does not touch the "Celltimes.txt" which has been created by Mplex_hack.exe.

Since I never have to deal with NTSC stuff, my main question is if my logic is solid. I assume that the chapter correction should take place whenever pulldown is used. No other condition is checked. Do you agree with my assumption?

Cheers
manolito

Sir Didymus

23rd May 2007, 18:40

Yes and No...

I mean, two different type of corrections should be implemented when the pulldown flag is "Yes":

1. In avi2dvd mode, pulldown flag is "No", and no corrections should be applied. (By the way, how 24fps avi files are handled in DVD2SVCD ?)

2. In dvd2dvd mode, when DVD chapters are used, if pulldown flag is "Yes" the number of chapters in the celltimes.txt file is correct, but all of the DVD chapters should be multiplied by 1,25.

3. In dvd2dvd mode, when fixed chapters are used, if pulldown flag is "Yes" the number of chapters in the celltimes.txt file is wrong (since the MovieFrames in my post above is relative to the encoded frames, I think), but the position of the chapters itself should NOT be multiplied by 1,25 since the chapter points are calculated using the chapter length (in seconds) and the VideoFps, which is always 30 for NTSC, and it is relative to PRESENTATION frames, not to ENCODED frames...

Am I wrong ?

Nick

23rd May 2007, 18:47

1) I think Manolito is incorrect on this one. If you feed an AVI at 23.976 (NTSC film) framerate, pulldown is applied and the pulldown flag is set to Yes. Just run my test piece

[VOBFiles]
VobName_0=D:\test.avi
...
Deinterlace=None
Pulldown=Yes
Width=720
Height=480

2) That is how I understand it

3) Not sure. I don't have an NTSC DVD to hand. Only PAL DVD's and NTSC AVI footage.

Sir Didymus

23rd May 2007, 19:56

I coded a quick bug correction release of Mplex_hack as follows:

1. In avi2dvd mode, when pulldown flag is "Yes", the MovieLenght variable (which is used to generate fixed chapters) is stretched by the factor of 1,25 - but only when this variable is generated starting from encoded frames, e.g. when using CCE 2.70 as encoder... :)

2. In dvd2dvd mode, when DVD chapters are used, if pulldown flag is "Yes", the DVD chapters are stretched by the factor of 1,25.

3. In dvd2dvd mode, when fixed chapters are used and pulldown flag is "Yes", again the MovieLenght variable (which is used to generate fixed chapters) is stretched by the factor of 1,25 - but only when this variable is generated starting from encoded frames.

Edit 20-06-2007 Link removed. See first page for the last available release...

Hem... Fishman0919... Any feedback will be appreciated...

Fishman0919

23rd May 2007, 21:04

Hem... Fishman0919... Any feedback will be appreciated...

I just started Superman Returns R1 and with Mplex_hack_beta_1.0

I will let you know of the results, any other info you need... please let me know.

manolito

23rd May 2007, 21:22

Since I have no NTSC Film DVD source, I had to create one for testing first.

Results:
For DVD2DVD with fixed chapters you are absolutely right:

3. In dvd2dvd mode, when fixed chapters are used, if pulldown flag is "Yes" the number of chapters in the celltimes.txt file is wrong (since the MovieFrames in my post above is relative to the encoded frames, I think), but the position of the chapters itself should NOT be multiplied by 1,25 since the chapter points are calculated using the chapter length (in seconds) and the VideoFps, which is always 30 for NTSC, and it is relative to PRESENTATION frames, not to ENCODED frames...

Am I wrong ?

The number of chapters is wrong, and the chapter positions should NOT be multiplied by 1.25. With the new Mplex_hack Beta the chapter points came out correctly (using QuEnc).

For AVI2DVD conversions my knowledge is very limited. All my AVI sources are 25 fps. As Nick stated for a 23.976 AVI D2S does apply pulldown. If the chapter points have to be corrected in this case depends on how Mplex_hack.exe creates the fixed chapters.

And what happens if the source AVI has a non standard frame rate? Does D2S automatically convert the frame rate to a DVD compliant rate? I have no idea.

Anyway, I'm gonna do some more testing with the new Mplex_hack.exe. I'll report back...

Cheers
manolito

Sir Didymus

23rd May 2007, 21:37

...I will let you know of the results, any other info you need... please let me know.

You are doing exactely what I need (testing, from NTSC land) for correcting the nice bug you have discovered.

That's very much appreciated!

Nick

23rd May 2007, 21:40

And what happens if the source AVI has a non standard frame rate? Does D2S automatically convert the frame rate to a DVD compliant rate? I have no idea.

Yes, that's exactly what it does, and very, very badly as a rule!!
I wouldn't worry too much about non-standard rates - the results are generally so poor in my experience as to be considered useless.

Sir Didymus

23rd May 2007, 21:49

Since I have no NTSC Film DVD source, I had to create one for testing first.

Results:
For DVD2DVD with fixed chapters you are absolutely right:
The number of chapters is wrong, and the chapter positions should NOT be multiplied by 1.25. With the new Mplex_hack Beta the chapter points came out correctly (using QuEnc).

Wow! manolito! you are quicker than the flash! Thanks for this confirmation. My hypotheses were based just on theories, but I have to admit that having the code of Mplex_hack in front of me help a lot for producing good theories...
:)

As Nick stated for a 23.976 AVI D2S does apply pulldown. If the chapter points have to be corrected in this case depends on how Mplex_hack.exe creates the fixed chapters.

Right. Actually, when Non Drop Time Code references are used in the code, these are reflecting "absolute timing" information, and are independent from the application of pulldown to the encoded source. When Movie Length or other timing information is derived by encoded frames, then this timing are stretched, depending on the "Pulldown=". By the way, thanks a lot for pointing out the parameter to look at for the clean implementation of the patch.

And what happens if the source AVI has a non standard frame rate? Does D2S automatically convert the frame rate to a DVD compliant rate? I have no idea.

Neither I have...

Anyway, I'm gonna do some more testing with the new Mplex_hack.exe. I'll report back...

Thanks manolito!

Sir Didymus

23rd May 2007, 21:52

Yes, that's exactly what it does, and very, very badly as a rule!!
I wouldn't worry too much about non-standard rates - the results are generally so poor in my experience as to be considered useless.

Mhhh... Good to know...

Edit: In the last days this thread became really interesting and instructing!

Fishman0919

23rd May 2007, 22:48

Bingo, Chapters matchup perfectly with both Superman Returns R1 and The Chronicles of Narnia: The Lion, the Witch, and the Wardrobe R1

Fishman0919

24th May 2007, 11:41

Hummm, ran into a little problem with X-men 2 R1.
I encoded with TMPGEnc 2.524 keeping both DD and DTS
.... just to try something different.
I start the project last nite and this morning my VIDEO_TS folder is 94.9 GB (101,932,920,832 bytes) and growing

Encoded_Video_TMPGEnc_NTSC.mpv = 3.09 GB (3,326,899,370 bytes)

Extracted_audio_1.ac3 = 428 MB (449,455,104 bytes)

Extracted_audio_2.dts = 721 MB (756,947,598 bytes)

VIDEO_TS now = 95.9 GB (103,006,662,656 bytes)

MuxMan version 0.15R
Opened script file C:\Program Files\DVD2SVCD\Movie\BatchMux.mxp
Accepted video C:\Program Files\DVD2SVCD\Movie\Encoded_Video_TMPGEnc_NTSC.mpv size = 3326899370
Accepted audio C:\Program Files\DVD2SVCD\Movie\Extracted_audio_1.ac3
Accepted audio C:\Program Files\DVD2SVCD\Movie\Extracted_audio_2.dts
expanded database to 300 entries.

02:35:15 Begin multiplex VTS01.
Title Segment List
Segment_1
Maximum audio duration 481078 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
Starting scene Segment_1_scn2 at 00:01:49:18, requested for 00:01:49:11
Starting scene Segment_1_scn3 at 00:05:20:26, requested for 00:05:20:20
Starting scene Segment_1_scn4 at 00:07:11:00, requested for 00:07:10:25
Starting scene Segment_1_scn5 at 00:12:25:17, requested for 00:12:25:11
Starting scene Segment_1_scn6 at 00:15:33:20, requested for 00:15:32:10
P-STD buffer underflow by 11133 bytes at 84112295, sector 307500.
P-STD buffer underflow by 13801 bytes at 84116799, sector 307529.
Starting scene Segment_1_scn7 at 00:17:55:13, requested for 00:17:55:10
Starting scene Segment_1_scn8 at 00:19:23:22, requested for 00:19:23:16
Starting scene Segment_1_scn9 at 00:22:45:18, requested for 00:22:45:10
Starting scene Segment_1_scn10 at 00:26:07:07, requested for 00:26:07:05
Starting scene Segment_1_scn11 at 00:29:13:11, requested for 00:29:13:06
Starting scene Segment_1_scn12 at 00:31:07:23, requested for 00:31:07:15
Starting scene Segment_1_scn13 at 00:33:38:20
Starting scene Segment_1_scn14 at 00:35:06:17, requested for 00:35:06:15
Starting scene Segment_1_scn15 at 00:39:47:01, requested for 00:39:46:25
Starting scene Segment_1_scn16 at 00:45:32:06, requested for 00:45:32:00
Starting scene Segment_1_scn17 at 00:47:14:22, requested for 00:47:14:15
Starting scene Segment_1_scn18 at 00:50:20:13, requested for 00:50:20:05
Starting scene Segment_1_scn19 at 00:53:14:05, requested for 00:53:13:25
Starting scene Segment_1_scn20 at 00:55:37:23, requested for 00:55:36:05
P-STD buffer underflow by 4648 bytes at 300700667, sector 935889.
P-STD buffer underflow by 10880 bytes at 300703670, sector 935907.
P-STD buffer underflow by 21289 bytes at 300708174, sector 935938.
Starting scene Segment_1_scn21 at 00:57:10:17, requested for 00:57:10:15
Starting scene Segment_1_scn22 at 00:59:17:18, requested for 00:59:17:10
Starting scene Segment_1_scn23 at 01:04:51:06, requested for 01:04:51:00
Starting scene Segment_1_scn24 at 01:09:18:20, requested for 01:09:18:16
Starting scene Segment_1_scn25 at 01:14:43:16, requested for 01:14:43:10
Starting scene Segment_1_scn26 at 01:18:13:05, requested for 01:18:12:25
Starting scene Segment_1_scn27 at 01:24:46:20, requested for 01:24:46:15
Starting scene Segment_1_scn28 at 01:27:10:06
Starting scene Segment_1_scn29 at 01:30:26:02, requested for 01:30:26:00
Starting scene Segment_1_scn30 at 01:32:28:22, requested for 01:32:27:11
Starting scene Segment_1_scn31 at 01:36:37:20, requested for 01:36:37:10
Starting scene Segment_1_scn32 at 01:41:09:00
Starting scene Segment_1_scn33 at 01:43:24:10, requested for 01:43:24:00
Starting scene Segment_1_scn34 at 01:46:30:23, requested for 01:46:30:20
Starting scene Segment_1_scn35 at 01:48:31:07, requested for 01:48:31:05
Starting scene Segment_1_scn36 at 01:53:35:13, requested for 01:53:34:05
Starting scene Segment_1_scn37 at 01:58:11:02, requested for 01:58:10:22
Starting scene Segment_1_scn38 at 02:02:06:12, requested for 02:02:06:07
Starting scene Segment_1_scn39 at 02:04:30:05, requested for 02:04:29:27
Starting scene Segment_1_scn40 at 02:05:02:25, requested for 02:05:02:17
SeqEnd at C64C74A6.

I stop with 97.0 GB (104,256,565,248 bytes)

Any files or info needed, please ask

Edit: I closed the windows at the bottom of the screen and closed DVD2DVD and noticed Muxman process is still running... VIDEO_TS is now 98.1 GB (105,439,358,976 bytes)

manolito

24th May 2007, 14:10

It does not look like this is caused by BatchMux. Muxman detected a couple of buffer underflows, and if something like this happens, Muxman does not finish the authoring correctly. It does not behave like DVDAuthor which will finish and leave it up to you if you want to keep the result.

In your case Muxman seems to be in an endless loop. This has not happend to me so far (maybe it was introduced with the latest version 0.15R), but if underflows were present, the VIDEO_TS folder would never contain all the files necessary for burning.

Bottom line: TMPGEnc did a bad job encoding your video. Switch to CCE, HC or QuEnc...

Cheers
manolito

Sir Didymus

24th May 2007, 14:51

Some encoders produce clips without the sequence end code at the end...

Release 1.0 of the BatchMux.exe program (it is the authoring wrapper of the plugin) have a patch for this very specific condition...

This release is not included in the plugin download (I was planning to update it in the next - needed - release of the plugin itself...)...

Do you mind checking if this release of BatchMux.exe:

http://forum.doom9.org/showthread.php?t=116297&highlight=BatchMux

is fixing the problem ?

Cheers,
SD

Fishman0919

24th May 2007, 15:16

Sir Didymus

24th May 2007, 17:51

In your case Muxman seems to be in an endless loop. This has not happend to me so far (maybe it was introduced with the latest version 0.15R)...

A similar situation was present in FAVC (and kindly reported by Mr_Odwin some days ago).

Apparently the trouble holds just when using the free version of MuxMan+BatchMux v0.9. The glitch seems to be not present in the professional version of MuxMan (18.8).

By loading (and running) the BatchMux.Mxp project file produced by DVD2SVCD with MuxMan 18.8, I am quite sure that the issue will disappear.

I implemented a patch in BatchMux 1.0 (see my post just above) that should be able to recover from this condition, but it's not a definitive solution. In order to solve the issue in a radical way MuxMan 15R should be updated; however I am not sure if this is in the priorities of MpuCoder...

Fishman0919

24th May 2007, 20:09

re-ran the authoring part with new patch in BatchMux 1.0, worked perfect.

VIDEO_TS = 4.33 GB (4,650,047,488 bytes)

Sir Didymus

24th May 2007, 21:55

Hei Fishman0919, in the last days you gave to me some very nice news (and you performed some excellent tests with the BatchMux plugin...)...

:thanks:

I think it's time to upgrade the plugin to release 1.5 (it should include the new BatchMux.exe 1.0 and the new Mplex_hack 1.0)... Next week, most probably...

Fishman0919

24th May 2007, 22:19

manolito

24th May 2007, 22:50

Here are some test results using the new Mplex_hack Beta:

Setup:
BatchMux 1.4
New Mplex_hack.exe Beta1
BatchMux.exe 1.0
Encoder: QuEnc

AVI2DVD mode, NTSC (Pulldown ON): OK
(thanks to Nick for providing a NTSC source AVI)
AVI2DVD mode PAL: OK

DVD2DVD mode PAL, DVD Chapters: OK
DVD2DVD mode PAL, Fixed Chapters: OK

DVD2DVD mode NTSC Film (Pulldown ON), DVD chapters: OK
DVD2DVD mode NTSC Film (Pulldown ON), Fixed chapters: OK

What is missing so far is NTSC interlaced Video (Pulldown OFF), I will test this tomorrow.

So far the new Mplex_hack.exe looks like winner. :)

@Sir Didymus:
I have no idea how you implemented the fixed chapter fix when using CCE 2.70. Do you think it is necessary to test the new Mplex_hack.exe with CCE 2.70 and maybe earlier CCE versions also?

Cheers
manolito

manolito

25th May 2007, 00:16

Test Update:

For NTSC Interlaced @29.97 the new Mplex_hack.exe also delivers the correct chapter points. No matter if Fixed Chapters or DVD Chapters are selected.

Cheers
manolito

Sir Didymus

25th May 2007, 09:20

Here is the way the Pulldown fix is implemented:

For DVD chapters, there is no much to say: the lines of the chapter file are represented as Encoded Frames and MuxMan need a representation in terms of Presentation Frames. When Pulldown flag is on, all entries of this file should be scaled by 1,25.

For fixed chapters, in the previous version, in the step 6 of the code, the following parameters were extracted from the DVD2SVCD files (this is just the initialisation of the involved variables...):

PalFlg = 0;
MovieFrames = 0;
hh = mm = ss = ff = 0;

now also pulldown is extracted:

PalFlg = 0;
PulldownFlg = 0;
MovieFrames = 0;
hh = mm = ss = ff = 0;

The two timing representations of the movie length (in frames and in ND time code - hh, mm, ss, ff) are extracted and - in the new beta of Mplex_hack, when the Pulldown flag is set, the MovieFrames variable is updated in order to represent Presentation Frames (not Encoded Frames):

if (PulldownFlg)
{
MovieFrames = MovieFrames + MovieFrames/4;
}

These two distinct representations are both needed, since, depending on the different DVD2SVCD modes, just one of the two is present in the configuration files of DVS2SVCD. For the production of the proper Celltimes.txt just MovieFrames is used, but this variable should represent Presentation Frames, not Encoded Frames...

In case MovieFrames is derived from the ND time code (hh:mm:ss:ff) then this variable is already representing Presentation Frames, so there is no need to scale it by 1,25.

In case MovieFrames is not derived from the ND time code - e.g. when it is fetched from the configuration files of DVD2SVCD, then it represents Encoded Frames, so it is necessary to scale it by 1,25.

Before this step, it take place the segment of code for supporting CCE 2.70:

// In case MovieFrames == 0 try to get this parameter from the ECL file generated by CCE
if (MovieFrames==0)
{
MovieFrames=GetMovieFramesFromEcl();
}

Where GetMovieFramesFromEcl() basically performs the following:

MovieFrames=encode_last-encode_first+1;

But also in this case, the MovieFrames extracted from the ECL expresses Encoded Frames.

So, to answer your question, an impact of the presence of the Pulldown handling on the CCE 2.70 exist (I would say more than just an impact it is a straight relationship). However, due to way the code is implemented I am very confident it should work. I have to admit I did not test this condition...

Hope this quick description is sufficient to clarify...

Thanks a lot for your further testing and for the very nice news and confirmation of the good behaviour of Mplex_hack_beta1.0 !
It is really appreciated !

Cheers,
SD

ChickenMan

25th May 2007, 09:25

Been away for a couple of weeks on holidays and I see all this new action :) Keep it up guys. Will do some testing also as soon as I get myself re-organised.

Sir Didymus

25th May 2007, 09:38

Hi ChickenMan!

Take your time... I will wait for some feedback also from your side before updating the whole plugin.

For making it short, and for the benefit of possible other casual readers, the two component (Mplex_hack.exe and BatchMux.exe) need to be updated. You may get the most recent releases here:

Edit 20-06-2007 Link removed. See first page for the last available release...

Cheers,
SD

manolito

25th May 2007, 22:27

@Sir Didymus

Thanks for the explanation about how CCE 2.70 chapters are implemented.

I still had the urge to test it, and -Bingo- I did find bugs!

Mode DVD2DVD, source was NTSC FILM, Pulldown ON.
For fixed chapters the chapter points were at the correct position, but the last chapters of the movie were missing.

For DVD chapters all chapter points were there, but at the wrong positions. They should have been expanded by 1.25, but obviously they were not.

Just to make sure my source was OK I crosschecked using QuEnc, and here everything was perfect.

And I also found another issue which is not related to chapter creation at all and which has been there all the time:

Mplex_hack.exe seems to assume that the Mplex command line always starts with the parameter "-f". This is not always true. In my tests I often use "Keep original audio", and many times DVD2SVCD determines that there is an audio delay which must be corrected. In my latest test the Mplex command line issued by DVD2SVCD was like this:

"E:\Programme\DVD2SVCD\DVDAuthor\Mplex_hack.exe" -1 17ms -f 8 -o "I:\Movies\MPlex_Muxed_File00.mpg" "I:\Movies\Pulldown_Encoded_Video_NTSC.mpv" "I:\Movies\Extracted_audio_1.ac3".

Please notice that there are two additional parameters in front of the "-f" parameter. In this case Mplex_hack.exe fails to determine the needed folder information.

I found that the solution is to simply discard the delay parameters in front of the "-f" parameter. I never got a sync problem when I just ignored these parameters.

And last something OT:
I always have the urge to try newer versions of the SVD2SVCD helper applications. AviSynth 2.57 works well with D2S, but for DGIndex / DGDecode it is different. Version 1.45 which comes with D2S is the only version which works. Newer versions (from 1.46 to 1.49) all have issues:
For PAL sources they all crash as soon as the encoder starts. For NTSC sources they seem to work at first glance. But they all detect NTSC interlaced video falsely as Film which leads to very ugly results. So do yourself a favor and stick with 1.45....

Cheers
manolito

Sir Didymus

25th May 2007, 23:56

...
Mode DVD2DVD, source was NTSC FILM, Pulldown ON.
For fixed chapters the chapter points were at the correct position, but the last chapters of the movie were missing.

For DVD chapters all chapter points were there, but at the wrong positions. They should have been expanded by 1.25, but obviously they were not.

Just to make sure my source was OK I crosschecked using QuEnc, and here everything was perfect.

This is possible only if the Pulldown flag, in the "dvd2svcd project file.d2s" file is (wrongly ?) set to "No"...
Could you post the Mplex_hack.log file ?

And I also found another issue which is not related to chapter creation at all and which has been there all the time:

Mplex_hack.exe seems to assume that the Mplex command line always starts with the parameter "-f".

That's right...

This is not always true. In my tests I often use "Keep original audio", and many times DVD2SVCD determines that there is an audio delay which must be corrected. In my latest test the Mplex command line issued by DVD2SVCD was like this:

"E:\Programme\DVD2SVCD\DVDAuthor\Mplex_hack.exe" -1 17ms -f 8 -o "I:\Movies\MPlex_Muxed_File00.mpg" "I:\Movies\Pulldown_Encoded_Video_NTSC.mpv" "I:\Movies\Extracted_audio_1.ac3".

Please notice that there are two additional parameters in front of the "-f" parameter. In this case Mplex_hack.exe fails to determine the needed folder information.

I found that the solution is to simply discard the delay parameters in front of the "-f" parameter. I never got a sync problem when I just ignored these parameters.

Good to know...
I simple was not aware of the different variants of the command lines passed to Mplex...
Do you know if there are other arguments like the one you have discovered, that should be taken into account ?
It will be quite easy to implement the delay parameter (BatchMux.exe always is perfectly adequate to support it...), but it would be important to know what is the overall set of arguments generated by DVD2SVCD.

And last something OT:
I always have the urge to try newer versions of the SVD2SVCD helper applications. AviSynth 2.57 works well with D2S, but for DGIndex / DGDecode it is different. Version 1.45 which comes with D2S is the only version which works. Newer versions (from 1.46 to 1.49) all have issues:
For PAL sources they all crash as soon as the encoder starts. For NTSC sources they seem to work at first glance. But they all detect NTSC interlaced video falsely as Film which leads to very ugly results. So do yourself a favor and stick with 1.45....

Cheers
manolito

Nice to know... Never tryed anything else than the DGDecode version bundled with DVD2SVCD... Since it seems this version works quite well, have you specific needs/good reasons for upgrading ?

Anyway, well, it seems there is still some work to perform before releasing a new version of the plugin...

:rolleyes:

Cheers,
SD

manolito

26th May 2007, 03:07

This is possible only if the Pulldown flag, in the "dvd2svcd project file.d2s" file is (wrongly ?) set to "No"...
Could you post the Mplex_hack.log file ?

Yes , you are right (as usual). When using CCE 2.70 with DVD2SVCD the pulldown flag in the D2S project file is not reliable. In all my tests with CCE 2.70 using NTSC film sources DGIndex determined Film and activated "Force Film". D2S did apply pulldown, but in the D2S project file the pulldown flag was set to "No". No wonder that Mplex_hack.exe got it all wrong.

But there is a very easy fix. Whenever DVD2SVCD applies pulldown it renames the video stream. If the name of the original video stream was "XYZ.mpv" it will be renamed to "Pulldown_XYZ.mpv". I believe that this would be a foolproof way for Mplex_hack.exe to determine if pulldown was used or not. Just parse the video stream file name for "Pulldown" and set the pulldown flag accordingly.

For the Mplex parameters all I could find so far is that D2S can issue delay parameters for the two supported audio streams which appear in front of the "-f" parameter. The format is "-1 xxms -2 yyms". As I already said I never had any sync problems just ignoring these parameters.

Cheers
manolito

ChickenMan

26th May 2007, 12:11

I just tried my first AVI2DVD encode using BatchMux.exe ver 1.0, Mplex_hack.exe ver1.0, MuxMan 0.15R, Nicks latest Ac3Enc and CCE 2.70. Chapter points set to 5min (300sec).

AVI was 1hr 41min 15sec long NTSC @ 23.976fps with MP3 audio. All went fine. Played final VIDEO_TS folder and all is well and in sync, however, chapter points were at exactly 5min intervals but stopped at 1hr 20min.

A quick calculation shows 101min * 0.8 (thats 1 / 1.25 ) = 80.8min and thats where the last chapter point was put in, at 80min.

EDIT: Checked the Project file and Pulldown was set to NO, even though a Pulldown_Encoded_Video_NTSC.mpv was correctly produced.

Sir Didymus

26th May 2007, 20:20

...
But there is a very easy fix. Whenever DVD2SVCD applies pulldown it renames the video stream. If the name of the original video stream was "XYZ.mpv" it will be renamed to "Pulldown_XYZ.mpv". I believe that this would be a foolproof way for Mplex_hack.exe to determine if pulldown was used or not. Just parse the video stream file name for "Pulldown" and set the pulldown flag accordingly.

I see...
However, if we change the way Mplex_hack.exe is acquiring the PulldownFlg (using the avi filename instead of some configuration parameters), this have the consequence that avi files whose original filename is "Pulldown_xxx.avi" can not be allowed anymore within DVD2SVCD... Right ?
It would be nice to understand what is the rule adopted by DVD2SVCD when it applies pulldown and implement something similar instead...

@ChickenMan
OK. I see. Thanks for confirming the issue discovered by manolito...
:)

Nick

26th May 2007, 20:40

No - this is not the case.
It is not the original AVI that is renamed.
What he means by the "original video stream" is the MPV file - the encoded MPEG2 video stream created by D2S.

The video encoder is called to create a stream called Encoded_Video_CCE(or whichever encoder)_PAL(or NTSC).mpv

If pulldown is to be applied - which as I understand it is only in the case of a 23.976fps source or use of the IVTC function - the pulldown command line is set to input Encoded_Video_*.mpv and output Pulldown_Encoded_Video_*.mpv . It is this latter file that is used for muxing.

You can therefore tell whether Pulldown has been applied from the parameters in the Mplex_hack commandline - if the filename of the video stream to be multiplexed has "Pulldown" as the first word, pulldown has been applied. If it doesn't, it hasn't.

Hope this clarifies!
Cheers
Nick

manolito

26th May 2007, 20:49

Exactly!
Thanks for the clarification...

Cheers
manolito

Sir Didymus

26th May 2007, 21:14

OK! I see! Thanks for the clarification Nick...

So, there is no drawback in fetching the PulldownFlg variable from the Mplex command line, as suggested by manolito... Let's code it...

:)

Cheers,
SD

Edit. OK. here it is the link for a quick fix of the two problems reported above. Pulldown is now fetched from the command line (video file argument) and the presence of optional audio delay arguments should not break the plugin anymore.
For the moment, these arguments, if present, are just discarded - I will include them in the process in a future time...

Edit 20-06-2007 Link removed. See first page for the last available release...

ChickenMan

27th May 2007, 14:06

Just downed Beta 3, trying it now :)

EDIT: Just tried on an NTSC 29.97 avi (no pulldown ) and all chapter points present and correct. Bed time, more testing tomorrow. :)

bionic

27th May 2007, 16:58

Im testing avi to dvd, audio to 2ch ac3

Using all the latest versions incl aften rev 512.
Single core barton and cce 2.50 xpsp2

1. pal with ac3 5.1 = ok
2. pal with vbr mp3 = ok
3. ntsc 23.976 with vbr mp3 = ok
4. ntsc 23.976 with ac3 5.1 = ok
5. ntsc 23.976 with ac3 4ch(3.1) = got vobs only, doing another encode with batchmux only, no audio encoding.
Second round same result, this thing seem to pop up every now and again, im keeping the logs in case theres any interest in checking it out.

:)

manolito

27th May 2007, 20:00

Edit. OK. here it is the link for a quick fix of the two problems reported above. Pulldown is now fetched from the command line (video file argument) and the presence of optional audio delay arguments should not break the plugin anymore.
For the moment, these arguments, if present, are just discarded - I will include them in the process in a future time...
Yes!!! Everything works as expected. Tried using CCE 2.70 with PAL sources (no pulldown) and with NTSC (with pulldown) both for DVD chapters and Fixed chapters, and the chapter points came out correctly every single time.

For the delay arguments I still try to figure out what DVD2SVCD is actually doing.

If the audio is reencoded, it seems that the delay correction is always done through BeSweet (using the -ota parameter) so the Mplex command line will not have delay parameters.

If "Keep source audio" is selected, I found two different scenarios so far. In one case the delay was -79ms, and this time BeSweet was run only to correct the delay. No delay parameter for Mplex. This was for a PAL source.

But in another case (NTSC source this time) the audio delay was 17ms, and this time BeSweet was not called at all. Instead there was the additional "-1 17ms" parameter for Mplex.

I would really like to know why the delay correction is sometimes done with BeSweet and another time with Mplex. Anyway, it would probably be a good idea to pass these delay parameters to MuxMan.

Cheers
manolito

Sir Didymus

28th May 2007, 11:15

Anyway, it would probably be a good idea to pass these delay parameters to MuxMan...

Yes! I fully agree with this. Beta4 should support audio delays...

Generally speaking, it can be not easy to understand what are the strategies applied by DVD2SVCD without the direct explainations of the authors. On the other hand, if the audio delay parameters are there, it's a good idea to support them.

An example is related to ac3 audio frames, that are encoding 32 ms of audio data, and are someway "atomic" units of ac3 audio. So it would be simply impossible for the audio encoder (e.g. BeSweet) to add or cut audio in order to compensate delays smaller than 32 ms. In this case the alignement must be performed at the mux level (by the authoring application)...

MuxMan is supporting audio delays in the range [-300..+300] ms. and BatchMux is already enabled to handle these parameters, so it turned out as easy to implement a simple check of the delays against the supported boundaries and to pass them to the authoring stage (dvdauth_hack.exe)...

EDIT. IMPORTANT... Please use the beta4 release of Mplex_hack below... Previous beta3 suffered from a nasty condition leading to loose the audio tracks for avi with audio delays... Beta4 should by OK, supporting (and delivering to the final DVD) also the audio delays... :)

Edit 20-06-2007 Link removed. See first page for the last available release...

BatchMux plugin - Released version 1.5
OK. It seems release 1.0 of Mplex_hack is working fine (no changes respect to Beta4 above). So I just update the first page of this thread with the most recent releases of the components:
Mplex_hack (ver. 1.0)
BatchMux (ver. 1.0)

Cheers,
SD

bionic

7th July 2007, 16:16

Hi guys! :)

Im testing avi to dvd, audio to 2ch ac3

Using all the latest versions incl aften rev 512.
Single core barton and cce 2.50 xpsp2

1. pal with ac3 5.1 = ok
2. pal with vbr mp3 = ok
3. ntsc 23.976 with vbr mp3 = ok
4. ntsc 23.976 with ac3 5.1 = ok
5. ntsc 23.976 with ac3 4ch(3.1) = got vobs only, doing another encode with batchmux only, no audio encoding.
Second round same result, this thing seem to pop up every now and again, im keeping the logs in case theres any interest in checking it out.

:)

Ive been trying to find a reason for the vobs only issue.
Afaict from the logs its the Muxman P-STD buffer underflow (bitrate spike?) issue thats been brought up from time to time.
Its right there in the logs, just took me some time to reflect.

Ive tried closed gops and that has sometimes worked, but very unreliable.
Ive tried lowering max bitrate and that works so far.
But theres no way afaik to predict what max bitrate values are needed without encoding several times.
And it sometimes takes lowering to an exctent that leaves the encode in cbr mode.

When lowering the bitrate enough for the authoring to finish "proper" i get the pulldown related 38 fields gop "error" in the muxman log
(1 oddities detected, resulting DVD is non-standard).
From what ive gathered so far this is related to encoding with 15 frames gops or more totalling to more than 36 frames after pulldown?

And since muxman counts the displayed frames/fields, not the physical frames in the stream. This has has an impact on max bitrate?
So could this problem be related to pulldown in some cases producing a too high max bitrate caused by the injected frames ?

Im still reading up on this though, input much appreciated :)

Boulder

8th July 2007, 09:46

Could someone please upload the latest version somewhere, sendspace.com seems to be down.

EDIT: Never mind, it's back up again..

Sir Didymus

8th July 2007, 20:43

Hi bionic!

See here for a nice discussion related to GOP sizes:
http://forum.doom9.org/showthread.php?t=113143

From what ive gathered so far this is related to encoding with 15 frames gops or more totalling to more than 36 frames after pulldown?

Yes, definitely.

And since muxman counts the displayed frames/fields, not the physical frames in the stream. This has has an impact on max bitrate?

No. The bitrate parameters (min, max, avg) are referring to the encoded frames. Applying pulldown to a given encoded stream should not change its bitrate...

So could this problem be related to pulldown in some cases producing a too high max bitrate caused by the injected frames ?
I can not see such a straight relationship. Maybe pulldown.exe is changing other timing information in the encoded stream (other than just adding the rff and tff flags), but I can not say it for sure, since I don't know the program...

Afraid I am not able to give you other hints on the matter...
It would be very interesting to create your assets using a different encoder, or to feed your assets to the professional release of MuxMan (the 0.18) to see if it makes any difference...

If you are able to make the issue replicable with short clips, maybe you may want to upload them somewhere (assuming no copyright issue holds), in order get them a look...

Please let us informed about your findings...

@Boulder: nice you are interested in the BatchMux Plugin :-)

Cheers,
SD

Boulder

8th July 2007, 20:48

@Boulder: nice you are interested in the BatchMux Plugin :-)I've set up DVD2SVCD for my dad since he captures a lot of TV stuff on his PVR-250..I just happened to browse through the forum and noticed that the brilliant multiplexer has been put to good use by you:) Too bad we're forced to switch to DVB at the end of August, DVD2SVCD won't work with DVB subs. I need to think of something for that (or would you like to hack D2S so that it accepts for example SUP files ;))

Sir Didymus

8th July 2007, 21:01

bionic

8th July 2007, 21:52

Hi Sir Didymus!

Thanks for the info and thanks for looking into it.
The link you pointed me to, along with this one
http://forum.doom9.org/showthread.php?t=116583&highlight=oddities+detected
was in fact the source of my "reasoning" :)

Yes, i do use muxman free version(0.15r) so testing with pro version would be something to try, i dont have it though, but i can up rather big clips for you to test with.

I was able to reproduce it with a test clip earlier, i dont have it anymore, but ill try to produce one that fails.

I have entertained the possibility of this being cce related, will test encode with quenc and tmpgenc too and report back.

I have a few logs with buffer underflow and the 38 gops error if you want to take a look?

Edit: Of course, if upping a clip is a copyright issue i will definitely refrain from it :)

Sir Didymus

8th July 2007, 22:21

I was able to reproduce it with a test clip earlier, i dont have it anymore, but ill try to produce one that fails.

I have entertained the possibility of this being cce related, will test encode with quenc and tmpgenc too and report back.

I have a few logs with buffer underflow and the 38 gops error if you want to take a look?

Of course, please post the logs... But I am dubtful it will be sufficient to understand what is going wrong... Most important would be to reproduce the issue and to have assets and logs available (in each step of the chain from the source asset, to the encoded one, to the pulldowned one)...

Boulder

9th July 2007, 04:35

I am quite interested in making the plugin as much useful as possible...

However I am nor sure I properly understand what you want to do... You mean you want to perform avi 2 dvd or dvb 2 dvd + subs in the sup format ? Have you some (short...) sample files to perform some tests ?

Edit - in any case it should be checked if other applications (e.g. FAVC ?) offer in a native way the features you are looking at... There is no point in developing some features that are already available elsewhere... By the way... FAVC is also using the jewel of Mpucoder (Muxman) for its authoring stage...Thank you for your interest. Unfortunately FAVC doesn't support MPEG2 input AFAIK so I can't set that up..

The problem is that the national broadcasting company (YLE) uses DVB subs so that they are not hardsubs but softsubs. When cutting the transport stream file with ProjectX, I can extract the subs directly to the SUP format. If D2S was hacked so that the SUP file could be imported when MuxMan does its magic, my dad could keep on using the program he likes to use and it would also save me from some headache.

I'll try to snip a sample for you tonight. ProjectX can extract to m2p or pva which D2S supports so that is not a problem. One problem is that to get the subs, you apparently need to demux the stream because when creating m2p or pva, ProjectX only adjusts the PIDs and keeps the subs in the container without extracting them as a separate file. But there is a solution to that (some manual work).

bionic

9th July 2007, 16:06

Quenc and tmpgenc tested.

Good news with Quenc.
1pass, default gops settings, high quality, trellis and extreme settings not active, muxman finsihes authoring proper.
No gops errors or pstd-underflow reported.

Tmpgenc tested twice. Just wanted to see if there was a difference.
One test with 2 pass vbr lowest quality rest at default.
One test with cq-vbr same settings.
Both tmpgenc tests produce several pstd-undeflow warnings in the logs.

Ill see about that clip next :)

Boulder

11th July 2007, 12:05

I'll try to snip a sample for you tonight.Dang, I forgot the sample:( Still, you pretty much don't need it, everything else can be done in the cutting phase in ProjectX before feeding the stream into D2S. The thing is to feed the subs in the multiplexing phase.

Sir Didymus

11th July 2007, 13:15

Quenc and tmpgenc tested.
Good news with Quenc...

Well, I am doing some testing using QuEnc and HCenc...

It seems to me (see advanced parametes of encoder) that using QuEnc for sources needing pulldown, the GOP size limit is set to 12. This explains why no GOP oddities are detected when using QuEnc as encoder.

For users who like adopting HCenc as encoder, I recommend for NTSC sources at 23,976 to adopt an HC configuration file (HC.ini), in the same place where HCenc.exe is located, containing the following line of text:

*AUTOGOP 12

It should solve the glitch of the GOP size limit with this encoder.

Edit. Thanks to the log files that bionic sent to me via PM, I discovered a bug in the chapter point generation performed by Mplex.hack. After some further investigation I found that the issue, under some non rare circumstances, may lead to the VOBS only problem reported above. In this scenario (affecting NTSC+pulldown cases) the error reported by MuxMan should be something like this:

Reference to non-existant scene "Seg1_Scn11" from PGC "VTS01_Ttn1_Pgc1"

The good news is that I was able to reproduce the problem, so I am positive to find a clean solution for this (in next days, most probably)... Stay tuned...

Sir Didymus

11th July 2007, 13:34

Dang, I forgot the sample:( Still, you pretty much don't need it, everything else can be done in the cutting phase in ProjectX before feeding the stream into D2S. The thing is to feed the subs in the multiplexing phase.

Don't mind...

But well, if some manual steps are still necessary in the process, then the simplest solution for adding a sup stream in the authoring stage is the following:

1) leave D2V making its job until the authoring phase, and then abort it.

2) You will see (in the DvdAuthor_log.txt) that a command line like this is issued:

BatchMux Arglist -->
-muxman "C:\Programfiler\DVD2SVCD\DVDAuthor"
-d "J:\Dvd2svcd\VIDEO_TS"
-v "J:\Dvd2svcd\Pulldown_Encoded_Video_NTSC.mpv"
-mxp "J:\Dvd2svcd\BatchMux.mxp"
-l "J:\Dvd2svcd\MuxMan.log"
-a1 "J:\Dvd2svcd\Encoded_audio_1.ac3"
-cellfr "J:\Dvd2svcd\CellTimes.txt"
-preparer "DVD2SVCD"
-a1lang --

3) in order to add a sup subpicture stream to the batch, it is simply necessary now to open a dos window and to paste/modify the command above in order to add the new subpicture (-s1 in the example):

BatchMux.exe
-muxman "C:\Programfiler\DVD2SVCD\DVDAuthor"
-d "J:\Dvd2svcd\VIDEO_TS"
-v "J:\Dvd2svcd\Pulldown_Encoded_Video_NTSC.mpv"
-mxp "J:\Dvd2svcd\BatchMux.mxp"
-l "J:\Dvd2svcd\MuxMan.log"
-a1 "J:\Dvd2svcd\Encoded_audio_1.ac3"
-s1 "New subpicture.sup"
-cellfr "J:\Dvd2svcd\CellTimes.txt"
-preparer "DVD2SVCD"
-a1lang --

Of course I should think to some way to make the step automatic, but in the meanwhile...

Another problem is that the colors and the display modes for the new stream are unknown a priori...

So, most probably some manual steps (PgcEdit editing) will be still necessary at the end...

If you launch BatchMux.exe manually, it will appear a short help showing the available options for the MuxMan wrapper; it is very simple to add or change some authoring parameter there...

Cheers,
SD

Boulder

11th July 2007, 13:45

Thanks, I think a simple batch file to run after each process might just do the trick, the sup filename just needs to be the same every time.

So you cannot enter the parameters for subtitle palette and display mode in the MuxMan CLI? Sorry, I'm at work and cannot try it out now myself.

Sir Didymus

11th July 2007, 16:22

Yes, thinking better at the problem, the solution of a simple batch file, at the end, should be the one solving your needs. You may enter a suitable palette, together with the other BatchMux parameters via the command:

-palette palette_file

It's an optional parameter; PgcEdit compatible ascii file containing 16 colour entries (index, red, green, blue) adopted for redefining the default color palette used by MuxMan.

There are also parameters for setting the subpic display mode... You just need to play a little bit with BatchMux... :rolleyes:

Boulder

11th July 2007, 16:58

OK, thanks - I'll play with BatchMux when I get the time :)

Sir Didymus

16th July 2007, 13:12

A new release of Mplex_hack is available:

edit - link removed. Please follow the discussion for the last available release

The code has been simplified, and the way of producing the chapters has been completely changed, in order to produce a chapters file for the authoring stage containing time references defined in terms of frame references or ND timecodes, depending on specific information available at the time mplex_hack is executed.

It should provide no improvements for PAL users, but some more precise results for NTSC users are expected (expecially in the avi 2 DVD mode and 24,976 fps sources).

Since the way of handling chapters is changed, please consider the release as a beta, and please report any oddities you discover...

Problems leading to a premature end of the MuxMan authoring, with some error condition similar to the following:

Reference to non-existant scene "Seg1_Scn11" from PGC "VTS01_Ttn1_Pgc1"

Should be fixed.

Cheers,
SD

bionic

16th July 2007, 13:22

Thanks :) testing as i post.

manolito

17th July 2007, 16:39

Test results for Mplex_hack.exe 1.1 beta:

I used two NTSC XviD Avi files, one @ 29.97 fps (no pulldown) and one @ 23.976 fps (pulldown). The clips both had a length of 2min 01sec. Fixed chapters every 20 sec were selected. CCE 2.70 was my encoder.

Correct chapter points in both cases. I then reverted back to the old Mplex_hack.exe 1.0, and indeed the chapter points created by the new version were slightly different.

Celltimes.txt created by ver 1.0:
600
1200
1800
2400
3000
Celltimes.txt created by ver 1.1 beta:
599
1198
1798
2397
2997

IMO these differences are not too relevant, for me it mostly shows that Sir Didymus is a real perfectionist...:)

One other thing I noticed: The clip has a length of 2min 01sec, but the last chapter at 2:00 is missing. This is a good thing, and it looks like this was done on purpose. Am I right?

Anyway, thanks for the new version, I could not find any issues with it.

Cheers
manolito

Sir Didymus

17th July 2007, 17:40

Test results for Mplex_hack.exe 1.1 beta:

IMO these differences are not too relevant...

agreed... :)

for me it mostly shows that Sir Didymus is a real perfectionist...:)

hem, agreed also with this one... :p Well, I have to explain that I implemented the small correction in the attempt to recover from a more serious situation (the authoring failures reported by bionic).

I have some evidence these errors are not related to the plugin, which seems working OK, apparently.

The point is that MuxMan seems quite sensitive to glitches in the authoring assets. Release 0.15R looks especially sensitive towards VBV underflows, refusing to complete the authoring stage in presence of such encoding errors. I have no clue on how to eliminate these errors. One recommendation is surely to try to limit the usage of the one pass VBR mode in CCE, which is disobeying to the max bitrate parameter... Another recommendation is not to push the max bitrate itself beyond 8500~9000 kbps... But I know both of the above hints are not eradicating the problem...

One other thing I noticed: The clip has a length of 2min 01sec, but the last chapter at 2:00 is missing. This is a good thing, and it looks like this was done on purpose. Am I right?

Yes, you are! There is a parameter (now it if fixed at 10 seconds or 250 frames, depending on different situations) preventing to generate a last chapter shorter than this parameter...

Thanks a lot for confirming Mplex_hack 1.1 is OK!

Cheers
SD

Edit - Spoke too early - sigh... Just found (thanks to bionic!) a little mistake in the new code introduced in mplex_hack beta1... Very nice it was discovered while mplex_hack 1.1 is in beta...
Please adopt beta2 here...

Edit 27-08-2007 Link removed - see first page of the thread for the most up to date version

ChickenMan

18th July 2007, 15:18

Ive been trying to find a reason for the vobs only issue.
Same here. I use to get the odd avi 2 dvd encode that didnt complete and reading the muxman log file, there were always references to buffer underflow probs. I sort of lived with that. But recently installing Nicks latest AC3enc8.exe and now only get the odd conversion thats complete and the rest not. So went back to AC3Enc7.bat and replaced the aften.exe with Aften 0.07 SSE3 optimized version and its now back to normal (ie. the odd conversion that never completes).

I've also noted of late, that on the odd occasion Muxman doesnt complete the authoring, the audio in the AVI was always odd (by odd, I mean either 44.1khz, 32khz or Mono). As a side note, Mono audio never seams to convert properly anyway, as Madplay produces a mono WAV correctly and then Aften (or the old AC3enc.dll) doesnt produce a compliant mono ac3 or a stereo ac3. Only 1/2 the audo is there but stretched out to full length of the movie. So audio way out of sync, very deep sounding and slow. I then manually process the audio.

Sir Didymus

18th July 2007, 17:37

Hi ChickenMan!

Thanks a lot for your comments, and for sharing your experience on the subject; very nice to know what you report about the audio assets :)

I am into these days more and more convinced that oddities in the assets feed to the authoring application are the specific cause of the reported issues.

In addition, please take into account that (in my experience) the glitches can be also related to the video alone.

We are having nice discussions and testing sessions (via PM) with bionic, where it seems - if confirmed - that under the specific conditions of the performed tests, the encoding based on CCE - multipass is getting rid of such errors, while OPV (and maybe CBR ?) is almost always producing buffer underflows at the authoring stage.

I have to say that I knew since some time that CCE - OPV is not complying strictly with the max bitrate encoding parameter... This single finding is quite astonishing and difficult to believe, considering the level of such a professional product... But there is some clear evidence about this...

And the implications are really serious, considering that multipass encoding takes much longer than OPV, and that the implicit suggestion (to not use OPV) is quite embarassing, looking for example at the huge - and beautiful - work performed by Tylo on the Roba method...

However it has been not easy to establish that the BatchMux plugin (and MuxMan, of course) have no responsibilities on the issue...

After all (I hope you agree), this is a good reason for going on using BatchMux:

better to know your assets have some troubles and stop the authoring, than producing a DVD with glitches and realising it stutters only at the playback time... :p

Cheers,
SD

manolito

18th July 2007, 18:24

AFAIK Mono audio has always been a problem. I recall some older posts about it (I think they were by Nick), and I made it a habit a long time ago to convert Mono to Stereo before feeding the audio to Besweet.

But I never had a problem so far when source audio was 44,1 kHz and had to be converted to 48 kHz.

As for the muxing failures caused by buffer underflows: Muxman is extremely picky and does not finish the conversion if it thinks that anything about the source files is non-standard. But on the other hand this means that if Muxman does not complain then you can be 100% sure that your encode is DVD compliant (even if there is an occasional bitrate spike above the max bitrate limit).

CCE OPV is my standard conversion method, and yes it does overshoot the specified max bitrate here and there. My max bitrate is always set to 8000 (DVD2SVCD sets this as the default), and using this value for max bitrate makes my encodes "Muxman proof" in 99.9% of cases.

QuEnc 1-pass VBR is a different story. Even with max bitrate set to 8000 there are buffer problems quite frequently, especially with short encodes. A way to get rid of the problems usually is to lower max bitrate even more and to use a high bitrate matrix like Fox Home Entertainment (or to switch to CBR).

So IMHO all this has nothing to do with Batchmux as Sir Didymus already pointed out. In the rare cases when Muxman refuses to convert my source files I usually try to remux with Imago and reauthor with DVDAuthor. Even if DVDAuthor issues some warnings, there is a very good chance that my standalone will play the DVD without any problems.

Cheers
manolito

bionic

18th July 2007, 19:34

Ill throw in a cce 2.50 opv encoding with max birate 8000 too then :)
I usually use 9000 or 9200 as max, but ive had assets that required iirc no more than 5000 as max for authoring to finish proper with muxman.

ChickenMan

20th July 2007, 15:32

I also use CCE 2.50 OPV 99% of the time ( to many hassles with 2.70 in Batch mode) but I also got the odd non-completed VIDEO_TS folder before SD's Muxman came along. That was using standard DVDAuthor, so I dont believe the problem lies with Muxman. But with all the new Aften versions of late and Muxman with various combinations of both seamed to make things worse, not better. But at the moment, 90% of encodes are now coming out fully authored. By the way, I have always used a max bitrate of 9200 for the last few years.

Those avi's with 44.1 audio, well the audio is converted to ac3 at 48kh fine, just it almost always doesnt get authored complete.

manolito

21st July 2007, 13:48

By the way, I have always used a max bitrate of 9200 for the last few years.

Here is the Muxman log file from an OPV conversion I just finished. I used CCE 2.70 with D2SRoba. The encode was done with a Q of 7, max bitrate set to 8000, min bitrate was 1000. No filtering at all, Quantizer characteristics 28, DC precision 10, GOP size 12, standard matrix.

MuxMan version 0.15R
Accepted video I:\Movies\Encoded_Video_CCE_PAL.mpv size = 4127779160
no multichannel extension found.
Accepted audio I:\Movies\Extracted_audio_1.mpa

13:09:31 Begin multiplex VTS01.
Title Segment List
Segment_1
Maximum audio duration 391558 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
SeqEnd at F608E954.
Bytes remaining in buffer = 0.
Bitrate - avg: 4510552, min: 921600 (lba 2128), max: 10308266 (lba 2087389).
Shortest GOP has 12 fields, longest GOP has 24 fields.
Fields: 391556, VOBU: 15762, Sectors: 2155925.

13:27:00 Begin multiplex VMG.
13:27:00 End multiplex.

As you can see, Muxman reports a max bitrate of 10308266 which is definitely higher than the DVD specs allow. But still Muxman had no problem authoring the files correctly, and there is no stuttering on my standalone whatsoever.

So I think you can make your life a lot easier if you limit your max bitrate for OPV encodes to a value of 8000. I do not believe that your quality will suffer in any visible way by this bitrate restriction.

Cheers
manolito

ChickenMan

22nd July 2007, 02:46

Thanks Manolito, I iwll drop it back and see how it goes. I also have seen the log files saying Max bitrate way over dvd specs and both authored completely and non-authored. Maybe because I've had the max bitrate so high at 9200 and audio at 224 leave little elbow room for either to go over a bit as why I have found the actual version of aften to have influenced whether it authors complete or not.

Back to 8000 and will report back. But I will keep my Min bitrate at 200.

manolito

8th September 2007, 19:15

@ Sir Didymus

I just noticed that for version 1.6 you changed the name for the chapter points from "Celltimes.txt" to "CellTcodes.txt". Does this change apply in all cases, or are there situations where the old name is used?

The reason I am asking is that my little batch file for automatic PALtoNTSC conversions ( http://forum.doom9.org/showthread.php?p=992798#post992798 )has to work with this text file in order to adapt the chapter points to the new frame rate. If the new file name is always used I just have to change two instances of the file name. If not then I will have to add a routine to parse the log files to retrieve the correct file name.

Cheers
manolito

Sir Didymus

8th September 2007, 21:45

Hi manolito!

Edit. I completely edited out my previous description (of 1 hour ago). It contained just plain wrong information...

The process in Mplex_hack is as follow:
1. The program looks in the file "dvd2svcd project file.d2s" for the movie length (in hh:mm:ss)
2. If this item is not zero, then the movie length is used, and the chapters are generated in NDTC format (CellTcodes file)
3. otherwise movie length is recovered from the ecl file, and the chapters are generated in frame format (Celltimes file)

The native format for MuxMan (scene points in the mxp files) is based on the NDTC format - i.e. "hh:mm:ss:ff" strings, so I decided to change the previous scheme, in order to avoid a first conversion of scene points from NDTC to movie frames (in Mplex_hack) and another conversion (in BatchMux.exe) from movie frames back to NDTC scene points... I am quite convinced this way of handling available information is the most linear and precise...

I want to keep interoperability with your script. It seems to me very useful. Sorry if I broke it. Let's think now about how to recover... :)

Edit2. I just got a deep reading of your script. I see the problem: it assumes CellTcodes file is still in a frame based format... It could not work this way. I am really afraid the last release of mplex_hack caused this trouble. :mad:

Am I right stating the the activities performed by your bat script are as follow ?
a) to change all the chapter points;
b) to apply DgPulldown to the source.

dirio49

9th September 2007, 01:39

@Sir Didymus

Is there any way you can make BatchMux to also work with titlewritter?

I know that you intent BatchMux to work with dvd2svcd.
but Titlewriter uses the same utilities for what it does.

Thanks
later

Sir Didymus

9th September 2007, 12:14

Is there any way you can make BatchMux to also work with titlewritter?

Sorry I don't know this application. I will try to learn something more about... The basic purpose (and functionnalities) of BatchMux are to provide a rich command line interface to the authoring engine of MuxMan. I don't even know is what you are proposing is meaninful or not... What does titlewriter do ? Is its author active ?

I know that you intent BatchMux to work with dvd2svcd.

That's only partially true. The authoring layer provided by BatchMux is also used by FAVC. For the future I am planning to get in contact with authors of other one click applications that have been recently made available, in order to understand if it may exist some valid reason in order to use an additional, alternative, authoring engine respect to the one these adopt so far... From my point of view the ideal situation is to be able to choose among different authoring possibilities... For DVD2SVCD this goal is (more or less manually) achieved...
:)

dirio49

9th September 2007, 15:33

Thanks for the reply.
What does titlewriter do ?

Titlewriter is a program used to Add/Edit DVD_TEXT, Menus (Either Simple or Original) into Dvd Compilations (Menu Area has been heavily designed to work with DVDShrink Reauthored Compilations).

Is its author active ?
yes, FallenAngel (http://tinyurl.com/2xhpmc)
hi is active in Digital digest most of the time

manolito

9th September 2007, 20:16

@Sir Didymus

I did some testing this afternoon, and the results are a little different from what you wrote:

The process in Mplex_hack is as follow:
1. The program looks in the file "dvd2svcd project file.d2s" for the movie length (in hh:mm:ss)
2. If this item is not zero, then the movie length is used, and the chapters are generated in NDTC format (CellTcodes file)
3. otherwise movie length is recovered from the ecl file, and the chapters are generated in frame format (Celltimes file)
In DVD2DVD mode, fixed chapters, QuEnc encoder the D2S project file does contain the correct movie length (in hh:mm:ss). According to your post Mplex_Hack.exe should create a chapter file in NDTC format in this case, but it doesn't. It creates a "Celltimes.txt" file in the frame index format instead.

Generally in DVD2DVD mode I found that the chapter file will always be in frame index format, no matter if I used fixed chapters or DVD chapters, or if I used QuEnc or CCE 2.70. Only in AVI2DVD mode using QuEnc I did get a chapter file in the NDTC format.

The native format for MuxMan (scene points in the mxp files) is based on the NDTC format - i.e. "hh:mm:ss:ff" strings, so I decided to change the previous scheme, in order to avoid a first conversion of scene points from NDTC to movie frames (in Mplex_hack) and another conversion (in BatchMux.exe) from movie frames back to NDTC scene points... I am quite convinced this way of handling available information is the most linear and precise...
I am not so sure. The NDTC format may be the native format when you use Muxman in command line mode. But in GUI mode Muxman only accepts chapter files which are in the frame index format.

Am I right stating the the activities performed by your bat script are as follow ?
a) to change all the chapter points;
b) to apply DgPulldown to the source.
Yes, that's the basic idea. Additionally the script detects if the Avisynth script contains a frame rate conversion to 59.94fps in which case the DGPulldown step is skipped. But in both cases the PAL chapter points have to be recalculated for the new presentation frame rate.

Anyway this PALtoNTSC script is not the main reason why I do not like the new chapter file format. I just wrote this batch file because first of all there is a real need to do this conversion (many NTSC standalone players refuse to play PAL DVDs), and second because the "Celltimes.txt" chapter format made it very easy to convert the chapter points using just a simple batch file. Converting chapter points in the NDTC format is a lot more complicated, at least for a batch file.

I frequently interrupt the DVD2SVCD conversion to do some tweaking. Sometimes I want to sweeten the audio track in WaveLab, and then I manually call Muxman to get my final DVD files. So far I was able to use the Celltimes.txt file which had been created by Mplex_hack.exe for this final authoring. With the new chapter format I will have to create the chapter file from scratch.

Right now I think that I will revert back to Mplex_hack.exe 1.0 from the Batchmux 1.5 package. I will gladly sacrifice a little accuracy of the chapter points in exchange for the convenience of having to deal with only one file name and one format for the chapter file.

Cheers
manolito

Sir Didymus

10th September 2007, 20:30

Hi manolito! :)

...In DVD2DVD mode...

You are right, I posted just the situation related to the avi2dvd case, since it seemed the one we were discussing about... In DVD2DVD mode the chapters are always already available...

I am not so sure. The NDTC format may be the native format when you use Muxman in command line mode. But in GUI mode Muxman only accepts chapter files which are in the frame index format.

Try to load a video file and whatever Celltimes file in Muxman, then save the project and open it with a text editor. You will see the native format, which is in NDTC...

Yes, that's the basic idea. Additionally the script detects if the Avisynth script contains a frame rate conversion to 59.94fps in which case the DGPulldown step is skipped. But in both cases the PAL chapter points have to be recalculated for the new presentation frame rate.

I asked because I was thinking at the possibility to incorporate inside Mplex_hack the process performed by the pal2ntsc script, but now I have a better idea...

...Converting chapter points in the NDTC format is a lot more complicated, at least for a batch file.

That's understood.

Right now I think that I will revert back to Mplex_hack.exe 1.0 from the Batchmux 1.5 package. I will gladly sacrifice a little accuracy of the chapter points in exchange for the convenience of having to deal with only one file name and one format for the chapter file.

I will try to avoid this need to roll back to a previous version of the plugin. Could it be acceptable, when the NDTC files are generated, to have also the Celltimes.txt produced ? The authoring would be normally based on the NDTC files, but at least you have available the other format in case of need (manual processing and pal2ntsc conversions). What do you think about ?

Cheers,
SD

manolito

10th September 2007, 23:38

I will try to avoid this need to roll back to a previous version of the plugin. Could it be acceptable, when the NDTC files are generated, to have also the Celltimes.txt produced ? The authoring would be normally based on the NDTC files, but at least you have available the other format in case of need (manual processing and pal2ntsc conversions). What do you think about ?
This would be very nice. But how would you assure that if a PAL2NTSC conversion took place the right chapter file is used for authoring?

My batch file would only correct the chapter points for Celltimes.txt while CellTcodes.txt would still contain the uncorrected chapter points. Somehow DVDAut_hack.exe needs to know which of the two files it should use.

I already started to explore if I somehow could manage to correct chapter points in NDTC format using a batch file. WinXP batch files are quite powerful (Nick tought me some tricks), but so far I have not come up with anything useful.

Cheers
manolito

manolito

11th September 2007, 01:08

Well, I think I gathered enough information now so I am confident that I can come up with a new PAL2NTSC script which can handle both chapter formats. Just give me a couple of days...

Cheers
manolito

Sir Didymus

11th September 2007, 08:56

Just give me a couple of days...

It was the same I wanted to say... :cool:

Yesterday evening I investigated further on the way PgcEdit and MuxMan handle chapter point and timecodes. For NTSC sources it is always applied the conversion factor 1 second --> 30 frames. So (for alignement and compatibility reasons) I decided to change back again the way Mplex_hack is working. It seems that converting 1 second to 29,97 frames is not correct...

Sorry for these indecisions concerning NTSC. Living in PAL land, my neurons run at 25 fps...

OK. In short, I need to produce a new release of Mplex_hack, so please wait a little bit, since I also found a coding solution which is clean and general, in order to obtain the desidered precision using the Celltimes format alone...

Within a couple of days...

Maybe even tomorrow (the changes respect to the beta release below are quite little, but in these days I can work on BatchMux just in the evenings: here at work I am changing PC, so the C compiler and some other development facilitis are temporarily unavailable to me)...
:)

Cheers,
SD

Edit. This beta1 release of Mplex_hack 1.2 is producing always both formats...
http://www.sendspace.com/file/7qdqzp

manolito

11th September 2007, 20:59

Hi SD,

the problem how to convert chapter points in NDTC format is solved - it simply is no problem at all. In NDTC format the chapter points are absolute time references, and the frame rate of the movie is totally irrelevant. No need to convert anything. The chapter points will be correct no matter if the movie is PAL or NTSC. How could I be that stupid! :confused:

This means that using Mplex_hack.exe version 1.1 all I would have to do to adapt my PAL2NTSC script is to check if Celltimes.txt does exist. Your new Beta of Mplex_hack 1.2 requires no action at all.

But during testing I discovered another problem which has been there for a while:

Using CCE 2.70 in AVI2DVD mode with fixed chapters Mplex_hack.exe has to use the ECL file to get the number of frames and the D2S project file to get the frame rate, because the movie length in the project file is 00:00:00. This works as long as there is no frame rate conversion during encoding.

One of my methods to do the PAL2NTSC conversion is to use "ChangeFPS(59.94)" in the Avisynth script. In this case Mplex_hack.exe detects the movie length incorrectly. The detected length is too high, so some extra chapters beyond the length of the movie are created which causes Muxman to fail.

I do not know how you get the frame rate in this case, but to me it looks like you assume that if PAL=1 then FPS=25. This does not work here. The D2S project file still says "PAL", but the "FPS=" entry does show the correct frame rate of 29.97 fps. If you use the "FPS=" entry you will get the correct movie length. In my tests the detected length looked like you had used a value of 25 for the frame rate.

OK. In short, I need to produce a new release of Mplex_hack, so please wait a little bit, since I also found a coding solution which is clean and general, in order to obtain the desidered precision using the Celltimes format alone...
I believe there is no need for this. The CellTcodes format is just fine. If you could just check the routine for movie length detection...

Cheers
manolito

Sir Didymus

12th September 2007, 09:24

The chapter points will be correct no matter if the movie is PAL or NTSC...

Ahhh, right!.... Silly me I did not point out before this very strong consideration!

But during testing I discovered another problem which has been there for a while...

Oh, Oh.... Your point is understood... I need to change the segment of code looking at the PAL flag and introduce a new check involving FPS...

In any case I think it would be much better to use a single format for the chapters exported by Mplex_hack. I can actually use both, but I would prefere making a choice. The generality of the NDTC format is appealing, and the involved simplifications for external processes (avoiding to change the chapter file within pal2ntsc conversions) would bring me on the NDTC side: maybe using this format always, in all situations, is the definitive solution we are looking at...

What do you think about ?

manolito

12th September 2007, 13:56

The generality of the NDTC format is appealing, and the involved simplifications for external processes (avoiding to change the chapter file within pal2ntsc conversions) would bring me on the NDTC side: maybe using this format always, in all situations, is the definitive solution we are looking at...
Yes, that would be nice. Maybe you could still create the additional Celltimes.txt in parallel (without using it). This would make manually authoring later using Muxman a lot easier...

Cheers
manolito

Sir Didymus

12th September 2007, 14:54

Maybe you could still create the additional Celltimes.txt in parallel (without using it). This would make manually authoring later using Muxman a lot easier...

That's right, but it would be not a good solution from the point of view of the interoperability of the plugin with other addons like your script. If both files are created by Mplex_hack, then it should be assumed that they represent the same chapter points. This condition can not be maintained if pal2ntsc (or other scripts and/or avisynth filters) applies pulldown and/or change TV system and/or framerate to the video. After one of the above step, the two formats will represent different chapter points.

I am quite convinced that a single output format from Mplex_hack is the best solution. I am just not sure about which format to select:

NDTC. Pros: It is an absolute representation of chapter points in terms of hh:mm:ss:ff time strings. It is independent from the TV system (PAL, NTSC) and FPS. Cons: in case of manual processes (e.g. loading of chapters in the MuxMan GUI - free version) the format is not suitable, and a new Celltimes.txt file should be manually generated.

Celltimes format. Pros: Very popular and compatible with most of the applications all around, including the MuxMan GUI. Cons: among the other, if the TV system changes (pal2ntsc conversions) the file should be changed and a new Celltimes.txt file should be generated.

manolito

12th September 2007, 15:45

Either one of the formats is fine for me. If you decide to go NDTC I will probably write a small tool which converts CellTcodes.txt to Celltimes.txt. Just specify the input file and the frame rate, and the corresponding Celltimes.txt file will be created.

Cheers
manolito

Sir Didymus

13th September 2007, 10:59

Well. I confirm I am keeping a single output format. The following beta release:

Edit: link removed. Please look at the first page of the thread for the most recent release...

Is based on Celltimes.txt format (movie frames). It now checks also the framerate, in a very simple way, as described below. I did some limited testing, but I am not sure about interlaced PAL sources. Is in this case the fps set to 25 or to 50 ?

There are also other possible sources of troubles related to the fact that the Pulldown flag is simply derived from the argument of Mplex_hack, and in this case, always the MovieFrames, when used, are scaled by the fixed factor of 5 / 4.

The overall process performed by mplex_hack to generate the Celltimes.txt file, is shortly summarised as follow:

Overall process for recovering movie length & chapter points, looking in the "dvd2svcd project file.d2s" file:

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

Then,

a. DVD chapters.
- The file "dvd2svcd chapters file.ini" is expected to contain valid chapter points,
that are simply extracted from the file, and scaled by the factor 5/4 in case Pulldown is present

b. fixed chapters.
- Both in case of Movie Length is based on hh:mm:ss and on MovieFrames, the Celltimes.txt file
is generated based on chapter points = chapter lenght * i * Framerate.

manolito

13th September 2007, 16:15

Thanks SD for the new Beta. I have already started testing, no problems so far. I will post the results once I have finished all tests (probably later tonight), but I already want to let you know about two slight peculiarities:

When I switched between QuEnc and CCE 2.70 I noticed that with CCE one more chapter at the end of the movie was created. My source was a 2 min AVI with fixed chapters every 10 sec, and the chapter @ 01:50 was not there when I used QuEnc. Simple reason is that with CCE one more frame is reported as the No. of frames. So you probably should not increment the value for the last encoded frame from the ECL file.

The other thing has nothing to do with Mplex_hack, it is a DVD2SVCD issue. For my tests I first used an AviSynth script where I had commented out all commands. The source already had the correct size, so no resizing was required, and I did not want any filters. The encode using QuEnc went well, but no chapters were created. The reason was that D2S reported only 240 frames and a length of 10 sec for the source. All I had to do to make D2S report the correct length was to uncomment just one command in the script (I uncommented the resize command which would not be executed anyway because Avisynth is intelligent enough to not invoke the resizer if the source format is already correct).

Cheers
manolito

Sir Didymus

13th September 2007, 18:44

Simple reason is that with CCE one more frame is reported as the No. of frames. So you probably should not increment the value for the last encoded frame from the ECL file.

That's good to know and easy to iron out :thanks:
Did you check, after the encode, that the length of the encoded movie is equal to the source, and still one frame less than what reported in the Mplex_hack logs?

The other thing has nothing to do with Mplex_hack, it is a DVD2SVCD issue...

That's good to know too... Whatever suggestion in order to recover also from this very special condition is welcome...

Cheers,
SD

manolito

13th September 2007, 23:50

Did you check, after the encode, that the length of the encoded movie is equal to the source, and still one frame less than what reported in the Mplex_hack logs?
To be honest, I did not even check. One frame more or less, who cares? It was pure coincidence that with my 10 sec fixed chapters I hit Mplex_hack's threshold where it decides if the last chapter should b created or not. Who in the world uses 10 sec chapters? I just wanted to point out that I detected a difference between QuEnc and CCE, but I think it is completely irrelevant if you take the time to change your code for CCE or not. Noone will ever notice...

That's good to know too... Whatever suggestion in order to recover also from this very special condition is welcome...
Another thing you should not even bother. Since the source code of DVD2SVCD is not available, nobody can tell how D2S calculates the movie length which is visible in its project file. I believe that even the author of D2S did not trust this calculation very much, because if you use D2s with the default Mplex / DVDAuthor combination, this movie length is not even used. Right after muxing there is some other routine called "Determining Length of Audio" which is used for chapter creation for DVDAuthor. When using the Batchmux plugin this routine always returns a vale of zero, so it is useless here.

But here are my test results for Mplex_hack.exe 1.2 Beta2:

In short, I could not find any issues. My tests were quite comprehensive, I had to create my NTSC sources from scratch, and I tested almost any possible combination. No problems whatsoever...

I did some limited testing, but I am not sure about interlaced PAL sources. Is in this case the fps set to 25 or to 50 ?
FPS is always 25, no problems here.

The only thing I have to change is my PAL2NTSC script. My script supports two different methods for the conversion. The first method uses DGPulldown. No changes are required here. MPlex_hack.exe cannot detect the (irregular) pulldown applied by DGPulldown, so my script has to convert the chapter points.

The second method works by converting the frame rate to 59.94 fps, and up to now this conversion was not detected by Mplex_hack.exe, so my script would have to do this. This has changed with the current Beta. The new frame rate is detected, and my script has nothing to do here.

It took less than a minute to update my script, so I am very happy with this current version.

Cheers
manolito

Sir Didymus

17th September 2007, 10:27

Hi manolito!

Thanks a lot for the deep testing and report.

Release 1.7 of the plugin has been produced (see first page of the thread), taking into account of the last improvements on the Mplex_hack, as discussed in the recent posts.

Single difference respect to the last Mplex_hack 1.2 beta 2, is the MovieFrames number, reported when looking at the ecl files produced by CCE. Now one frame less is reported to the calling procedures. This should align the CCE 2.70 behaviour to the one of Qenc and HCenc.

Cheers,
SD

bionic

17th September 2007, 15:04

Thank you SD :)

To anyone having problems downloading from mediafire, turn on cookies.

manolito

17th September 2007, 20:45

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

22nd November 2007, 21:28

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

23rd November 2007, 21:14

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

24th November 2007, 01:08

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

Cheers
manolito

Sir Didymus

29th November 2007, 20:50

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

29th November 2007, 21:18

Thanks SD, will start testing right away...

Cheers
manolito

manolito

30th November 2007, 14:31

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

30th November 2007, 15:00

...(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

1st December 2007, 17:51

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

1st December 2007, 22:06

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

2nd December 2007, 04:10

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

Sir Didymus

2nd December 2007, 13:22

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

2nd December 2007, 15:24

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

2nd December 2007, 20:35

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

2nd December 2007, 22:13

I did a few AVI's.

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

Sir Didymus

3rd December 2007, 10:01

@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

3rd December 2007, 20:20

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

3rd December 2007, 21:08

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

3rd December 2007, 21:09

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

Sir Didymus

3rd December 2007, 21:16

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

3rd December 2007, 23:18

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

4th December 2007, 17:32

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

4th December 2007, 19:49

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

4th December 2007, 22:25

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

5th December 2007, 09:21

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

24th December 2007, 17:44

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

29th December 2007, 00:46

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

All the best for the new year :)

manolito

16th April 2008, 22:07

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

4th May 2010, 21:20

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

5th May 2010, 00:06

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