After a long time you finally managed to break my FF_VBR and WaviMod plugins...
The audio peak level check will not work if my plugins are installed. The reason is that you use the redirection character in the FFmpeg params. The way I intercept all FFmpeg commands in my plugins requires that I retrieve the original command line. In a batch file there is no way to do this correctly if the command line contains special characters like the pipe character or the redirection character.

So far I do not see any workaround for this. Myself I do not care because I use external tools to analyze my audio sources, and I also pretty much abandoned simple peak normalizing.

For the new chapter import and export routines I did not have the time yet to test them, will do this ASAP.

Hi manolito, of course it did not intend to break the plugins... from my side I will try to find a way to redirect FFmpeg stderr to a VB variable instead of going thru batch text file saving. Not easy, but I will try.

I will wait for your kind german translations.

And please let me know your opinion about the new features (Import OGG Chapters and Peak Level Check).

I tried a few more tricks today, but nothing worked (escaping special characters, using delayed expansion, creating new processes for my batch files). I am just hitting the limitations of batch files, which somehow was to be expected.

What would work is to edit your A2DPeakLevel.bat to call _FFmpeg.exe (the renamed original FFmpeg.exe). But this would mean that you had to integrate a check in A2D if my FFmpeg hack is installed and then call the appropriate executable. Not really desirable...

Anyways, anybody who uses my Wavi_Mod plugin has no need to check the audio peak level from within A2D. And for users who have not installed my plugins it does not matter anyways.

A suggestion:
Currently you employ the AviSynth "Normalize" function after the peak level check. This wastes a lot of time. If the peak level is already known you could use the "AmplifyDB" function instead.

When A2D is started in German then the translation for this entry does not kick in, I see the English text. Clicking "View->Select Language->German" fixes it, now I do see the German translation.

I also played a little with the new chapter import/export routines, but this stuff seems awfully complex, at least when you do not live in NTSC land...

What I tried so far was to convert a PAL title with chapters every 3 minutes to NTSC. When I had NTSC SpeedDown activated of course the OGG chapters added about 4sec to every chapter point, I did expect this. But when I imported an OGG chapter file I had saved earlier with chapters at exactly every 3 minutes then I got chapter points with about 40 sec added to every original chapter.

Still Batchmux handled these chapters gracefully. I did not expect this because I know that Muxman refuses to author streams with chapters beyond the video length.

Whatever, I think that some folks from NTSC land will have to join in here to test this new feature.

<<
...Still Batchmux handled these chapters gracefully. I did not expect this because I know that Muxman refuses to author streams with chapters beyond the video length...
>>

Indeed, this is intriguing...

The total number of chapters identified are reported in the BM log file as: "Segment #... - Total Nr of Chapters --> ...".

Just out of curiosity I browsed a little bit deeper in the C code where the chapter points are validated... Well, plenty of code is present in BM to validate the timecode entries. Believe me, there are many checks (and warnings/errors printed out in case of issues). Nevertheless, there is no explicit validation of the individual time points of the chapter lists against the duration of the related video segments. In other terms, as you are pointing out, the BM session (preparation of the mxp script) should not stop...

It is an intended behavior: in case of problems related to chapter points outside of the range of the video segment duration, the complains are all left to MuxMan...

You are right, all credits for handling these out of range chapters go to BatchMux, not to MuxMan.

Did another test which confirmed it. The source file was PAL, length was 6min 10sec. It had chapters at 2:00, 4:00 and 6:00. I exported these chapters to the OGG format. Then fired up AVStoDVD and told it to create an NTSC DVD structure. A2D used soft pulldown (correctly, the source was progressive). Then I imported the previously saved OGG chapters file, and the chapters window told me that I had chapters at 2:30, 5:00 and 7:30.

After the conversion which went without errors I played the DVD, and it had chapters at 2:30 and 5:00. The last chapter at 7:30 had not been included.

Had I tried to mux these chapters only using Muxman then Muxman woud have refused to mux and author this project. So it was really BatchMux which protected Muxman from receiving a chapter point outside of the video length. Very cool...

But of course it is still not correct how A2D handles this case. The whole point of using a chapter file which is based on absolute time stamps (as opposed to frame numbers which need to change with the target FPS) is to be independent of the target FPS. Right now A2D does not handle these OGG chapter files correctly when using pulldown.

In another test I used hard FPS conversion to NTSC with ChangeFPS. This time after importing the OGG chapter file the chapter points were correct. Looks like FPS conversion using pulldown needs to be fixed when importing OGG chapters.

Hem... No, no... Thanks for the credits, but I think there should be something else in the chain which is filtering out the last chapter.

Possibly it is the analysis and the conversions of AVS2DVD. Please get a look at the input chapter files provided to BM to confirm...

About BM I was saying the opposite of your (kind) understanding infact: as far as I can say, BM is NOT checking the duration of the video, so it is not removing the last chapter. If you look at the .mxp (output) file produced by BM, you should be able to see the presence of a scene at the time 7:30.

Yes, you are correct. I repeated my tests keeping all the temp files, and indeed it was AVStoDVD which removed the last (out of range) chapter from the conversion. BatchMux was called without this last chapter, so MuxMan had no problem. Still this is not the desired outcome, the chapters are not at the positions where they should be...

@ MrC

After some long hours of testing I do know why I had this feeling that implementing OGG chapter import would be a major task...

AVStoDVD is so advanced now, it offers many methods for FPS conversion, and all of these methods require a different handling of importing OGG chapters which are based on time codes.

From my understanding the goal must be:
When I import an OGG chapter file into A2D, then the chapters must appear at the same position of the video in the conversion result. If A2D does not speed up or slow down the video then the chapters must appear at the same point in time (which is also the same position in the video). But if A2D does speed up or slow down the video, then the chapters should still be at the same position of the video. But of course the time stamps for the chapter points should be different to reflect the now different length of the clip. Do we agree on this?

Alright, I tested most of the possible scenarios with the current Alpha, this is what I found so far:

Test environment:
Source file was a short 6min 9sec clip. I created an OGG chapter file with chapters at 2:00, 4:00 and 6:00 min. From this source clip I made different clips for the different use cases:

A2: Using DSS2Mod with LAVFilters
MediaInfo recognizes the frame rate as 23.976, DSS2 removes the pulldown flags, and A2D will either use PAL speedup or 23.976 -> 25 pulldown. In both cases the chapter points are off (by about 4% with PAL speedup, much worse when using 23.976 -> 25 pulldown).

B: Telecined 25 -> 29.97
MediaInfo does not recognize the pulldown flags. A2D sees the source as 29.97 and will use hard FPS conversion. No problems with the chapter points.

Generally it looks like hard FPS conversions are handled correctly by the current implementation. When soft pulldown or speedup/slowdown gets used then the problems start. There are probably some more use cases which will need special attention, but right now I am not in the shape for more testing (my head is buzzing already...).

A2: Using DSS2Mod with LAVFilters
MediaInfo recognizes the frame rate as 23.976, DSS2 removes the pulldown flags, and A2D will either use PAL speedup or 23.976 -> 25 pulldown. In both cases the chapter points are off (by about 4% with PAL speedup, much worse when using 23.976 -> 25 pulldown).

Realizing once again that NTSC is still a strange beast to me...
What is the "most correct" way to handle a progressive (film) NTSC clip which is encoded at 23.976fps with 3:2 pulldown flags?

In AVStoDVD the different source filters depend on the MediaInfo information. When DGIndex/DGDecode is used then the "Honor Pulldown Flags" option is set. AviSynth sees a 29.97fps clip which looks "interlaced" due to the repeated fields. For fps conversion to PAL framerate A2D uses the selected "hard" conversion method (default is MCJMFPS).

Is this a good way to do it? Or shouldn't DGIndex use the "Force Film" option instead to serve the 23.976 clip without the repeated fields to AviSynth?

//EDIT//
I had falsely assumed that AVStoDVD actively edits DGIndex.ini to make sure that "Honor Pulldown Flags" is set. This is not true, A2D does not touch the "Field Operation" setting. A user can change this setting to "Force Film" before starting AVStoDVD, and this will make sure that only the encoded frames without the repeated fields will be served to AviSynth.
//END EDIT//

The other method using DSS2Mod and LAVFilters also raises a few questions. In this case MediaInfo reports 23.976fps and 3:2 pulldown for the source clip. A2D adds the "fps=23.976" to the DSS2Mod source filter command. Does this command return the correct frames? Without the "fps=23.976" DSS2Mod would return a rate of 29.97 (like DGIndex with "Honor Pulldown Flags"). Is forcing 23.976 in the source filter command the equivalent of removing the pulldown flags? I have my doubts... I am afraid that DSS2Mod first decodes to 29.97 and afterwards just drops frames to reach the specified frame rate of 23.976.

BTW DirectShowSource and FFmpegSource behave the same way as DSS2Mod.

Whatever, I am mighty glad to live in PAL land where I do not have to deal with those things...

Thanks manolito for the German translation and extensive testing. PAL<->NTSC conversions are a nightmare for many reasons, chapters affaire is just the top of the iceberg...

Now I just have to find a couple of hours to go thru your investigations and solve all (?) the possible fps conversion scenarios within the new OGG chapters import routine.

About the Peak Level Check feature, I agree with you that it would better trigger the AmplifyDB() instead of Normalize(). There is also the possibility to move that routine directly in the AviSynth tab > Audio > Amplify Audio option, as preliminary prompt to the user.

The following hotfix should solve the chapters import sync issues in PAL<->NTSC conversions. And the Peak Level Check feature now triggers AmplifyDB(). And the 120011 Right-Click to manage Titles translation.

For OGG chapter file import for PAl -> NTSC conversions the pulldown issues as well as the speeddown issues are fixed.

For NTSC -> PAL I think that the PAL speedup thing is also fixed, but the whole NTSC -> PAL conversion routine does not work when the source is a progressive NTSC Film clip at 23.976 with pulldown flags (23.976 -> 29.97) added.

This has nothing to do with OGG chapter file import, this problem has been there for a long time. Most folks do not care, because all PAL players can handle NTSC sources these days, no need to convert to PAL.

For the FFmpeg stderr thing I think that it is not so important. I will add a quick batch command to my FFmpeg hack to disable and reenable the hack with one mouse click, so users can easily use the peak level check even when they have my plugins installed.

Right now when the Normalize option is active and the peak level check is performed, users may end up with a "normalize" command followed by a "AmplifyDB" command. After a successful peak level check the "normalize" command should be removed from the AVS script.

the whole NTSC -> PAL conversion routine does not work when the source is a progressive NTSC Film clip at 23.976 with pulldown flags (23.976 -> 29.97) added.

Case studies:

Using DGIndex with "Honor Pulldown Flags" enabled (default):

The stream served to AviSynth will be (pseudo) interlaced. You can either IVTC it (a field matcher followed by a decimator), or you can deinterlace it. Otherwise you will have to treat it as "interlaced".

AVStoDVD does not do anything to such a stream, it falsely treats it as progressive. Any vertical resizing or using a filter with a spatial component will screw up the clip.

Using DGIndex with "Force Film" enabled:

For consistent pulldown flags this would be the correct option. But importing OGG chapter files fails with the current A2D version.

Using DSS2Mod or DirectShowSource or FFmpegSource:

For these source filters AVStoDVD uses the frame rate reported by MediaInfo of 23.976 and inserts this frame rate into the source filter call. MediaInfo also reports 3:2 pulldown flags, but A2D ignores this. So the source filters first serve the 29.97 (pseudo interlaced) stream to AviSynth, then the frame rate parameter causes frame drops to reach the specified frame rate. The result will still have interlaced frames, generally the quality will be pretty bad.

Users could edit the AVS script in A2D and remove the FPS parameters for the source filter. Then the source would be served as 29.97 to AviSynth, but (the same as DGDecode) the resulting (pseudo) interlaced stream is not handled correctly by AVStoDVD.

The problem is there also when the PAL speedup routine is active along with a 23.976 progressive clips with 2:3 pulldown flags. Now I don't check if pulldown flags are present.

In these cases, what about applying the IVTC option (Edit Title > AviSynth > Enhance) to remove the pulldown flags? The output would be a true 23.976 progressive clip, to which we can apply soft pulldown (23.976->25) or 4% speedup. Currently IVTC option is greyed out for everything but 29.97 interlaced, but you can easily tweak the frame rate and scan type clip properties within A2D. And if it works, I can activate IVTC by default for this scenario (input NTSC 23.976 progressive clips with 2:3 pulldown flags, output PAL).

Currently IVTC option is greyed out for everything but 29.97 interlaced,

Hi MrC,

I have to admit that I did not test the IVTC option at all since it was introduced by the end of 2016. Now that I looked into it I believe you should change some things about it...

Only allowing it for 29.97 interlaced sources is too limited. First of all not all 29.97 interlaced clips are hard telecined, they could just as well be "truly" interlaced without repeated fields. In such cases TFM will fail because there are no fields to match. MediaInfo is no help for hard telecined sources, it won't tell if there are repeated fields.

And then of course applying IVTC is a standard procedure for soft telecined NTSC sources, it should not be greyed out for such sources.

A general remark about the IVTC implementation:
Right now the following lines are present in the AVS script:

Quote:

Video = Video.TFM.TDecimate
Video = Video.ConvertToYV12()

I believe that the IVTC commands should appear AFTER the ConvertToYV12 command, because TFM and TDecimate both only support YV12 and YUY2. And the commands should be "TFM()" and "TDecimate()", the brackets make it faster.

Now talking about these standard progressive 23.076 NTSC sources which have been encoded with 3:2 soft pulldown. How should A2D treat such clips?

From the Doom9 IVTC tutorial:

Quote:

IVTC ADVICE

FOR NTSC PEOPLE: FORCE FILM WHEN YOU CAN. IVTC WHEN YOU CAN’T FORCE FILM. DEINTERLACE WHEN YOU CAN’T DO EITHER.

But before digging into this I believe it is necessary to talk about semantics to make the behavior of the different source filters consistent.

For such a clip MediaInfo reports "23.976fps, 2:3 pulldown, progressive". All software players and VirtualDub report 29.97fps. I believe that the MediaInfo fps detection is wrong.

The problem with A2D is that whenever DSS2Mod or DirectShowSource or FFmpegSource is used then the frame rate reported by MediaInfo is included in the call for the source filter. This will give incorrect results. If MediaInfo reports 2:3 pulldown then the frame rate for the source filter call should be 29.97 (or it could be omitted).

The reason for this incorrect behavior is that all the above source filters have no option to remove pulldown flags with a "Forced Film" option like DGIndex. They all honor the pulldown flags and serve a "pseudo-interlaced" output to AviSynth.

DGIndex has a "Forced Film" option. When this option is selected then the pulldown flags are removed and AviSynth gets a progressive 23.976 stream from DGDecode.

IMO the way AVStoDVD should address this difference between source filters is to always set the fps to 29.97 as soon as MediaInfo reports pulldown. This way the behavior of all source filters will be consistent (if the DGIndex field option is left at the default "Honor Pulldown Flags").

Now how can A2D follow the advices from the Doom9 IVTC tutorial? The preferred option is "Force Film". Only DGIndex/DGDecode can do this in A2D, and only if users change the "Field Operation" setting to "Forced Film" before starting AVStoDVD. With the default option "Honor Pulldown Flags" DGIndex/DGDecode will send a 29.97 pseudo-interlaced stream to AviSynth like the other source filters.

The next advice "IVTC if you can't force film" means that A2D should not grey out the IVTC option as soon as MediaInfo reports pulldown.

And the last option "Deinterlace if all else fails" means that A2D should not grey out the "Deinterlace" option if MediaInfo reports Pulldown. Right now deinterlacing is not possible for such sources unless the user changes the title properties from Progressive to Interlaced.

Alright, even more things to consider. All of the above only applies to 23.976 progressive sources with standard 3:2 pulldown. But A2D also supports "irregular" pulldown (23.976 -> 25, 24 -> 25, 25 -> 29.97). For such sources MediaInfo does not report the pulldown. So AVStoDVD will treat it as progressive 29.97 which causes terrible results when applying vertical resizing or spatial filters.

The question is if you want to deal with such "irregular pulldown" sources at all. There is no automatic way to do it since MediaInfo does not recognize the pulldown. Of course using "Forced Film" on such sources is desirable, but only experienced users would be able to detect such a source. IVTC would also work, but not with the default parameters. TDecimate would need custom parameters to retrieve the original frame rate.

Well, this post came out much longer than I anticipated, but the problems are real. No idea how important this stuff is for the "Average Joe" user since converting NTSC to PAL is mostly not necessary for users living in PAL land. And the PAL -> NTSC conversions do already work.