does dvd2avi chop off frames?

[Guest]

Originally posted by len0x
I wish someone can point me to the 1.76 CLI version download which includes CommandLine.txt, coz all versions I have don't have this file with them. http://www.dvd2dvd.org/

See the left-hand Downloads menu.

I'd like to know if new CLI has backward compatibility with 1.76? No it does not. The two versions of DVD2AVI do not have the same option sets.

[len0x]

Originally posted by neuron2
[BThe two versions of DVD2AVI do not have the same option sets. [/B]

That's true. I just compared CLIs and see that 1.77.3 has less options. The question is: will you version complain if unspecified option supplied or just ignore it and continue working?

[Zeul]

@ neuron2

quote:
--------------------------------------------------------------------------------
Originally posted by Zeul
Are you planning to do a fixed version for Avisynth 2.07/8?
--------------------------------------------------------------------------------

I can make one. How badly is it needed? Why are people not upgrading to 2.5?

I believe many people are still using 2.07 because 2.5+ still has a couple of outstanding issues (so I am told). In NuMenu4u and I am sure Eyes`Only will be the same for DIF4U! we would like to give the users the best dvd2avi/mpeg2dec versions possible - without forcing them to upgrade. If you could produce a version for this purpose that would be very useful.

Thanks

Zeul

[len0x]

Originally posted by Zeul
I believe many people are still using 2.07 because 2.5+ still has a couple of outstanding issues (so I am told). In NuMenu4u and I am sure Eyes`Only will be the same for DIF4U! we would like to give the users the best dvd2avi/mpeg2dec versions possible - without forcing them to upgrade. If you could produce a version for this purpose that would be very useful.


Which outstanding issues? I actually believe that we should force ppl to use 2.5.x otherwise those "issues" will stay outstanding forever... I am always shipping GK with latest avisynth and starting with 2.5.2 (well 2.5.3 is suppose to be out this week) I did not see many complains about it (2.5.1 indeed was buggy for some systems though...)

[Boulder]

I can confirm on my behalf that the a/v sync issues are history with beta 15.

Great work Don, as always:cool:

[Guest]

Thank you, len0x, CruNcher, and Boulder, for your test results.

I'm thinking of implementing the VFAPI by having it call into the MPEG2DEC3dg DLL. That will avoid having multiple code bases that must be kept in alignment.

>The question is: will your version complain if unspecified options
>are supplied, or will it just ignore them and continue working?

It will ignore them but not getting the requested options can hardly be viewed as "working". CLI clients should be revised as needed.

[Eyes`Only]

Amazing! Someone actually fixed our long-heralded bug! Thanks Donald!

DoItFast4U uses the same CLI as DVD2SVCD, so it looks like it will work fine (sure, testing needs to be done). One thing I did notice though... your Commandline.txt file seems to be missing many of the audio demux switches from the original DVD2SVCD version. Specifically, -DD and -CF are used by DoItFast4U's HDD Demux feature, which I'd LOVE to get rid of, but hey, some ppl actually like that feature. So without making me sift thru your code, could you just tell us if you removed those switches, or just omitted them from your text file?

[Guest]

Anything you can do through the menus of DVD2AVI 1.77.3, you can do through the CLI (except for the luminance filter and clipping, which were not in 1.76 CLI). You need to be creative about choosing the right combination of options to achieve your goal. Figure out how to do it using the menus first.

-DD and -CF are gone. I assume their effect is achieved through the appropriate use of the new options.

I do not know what HDD Demux is.

[JuanC]

Originally posted by neuron2
I'm thinking of implementing the VFAPI by having it call into the MPEG2DEC3dg DLL. That will avoid having multiple code bases that must be kept in alignment. Pretty smart! Also, the DVD2AVI VFAPI plug-in will surely become faster by using the optimizations in MPEG2DEC3.

[CruNcher]

@neuron2

i tested your 16 version and their is something strange the demuxed .mpa transcoded then to mp3 file doesn't fit to the created .avi that is what AviMux shows Vdubmod can compensate that i think but AviMux cant so i think that the demuxed mpa is crippled somehow ? this was DVB source i can cut you out a sample from the original mpg if you wish and you can check that but avimux allways shows there was a problem @ the end muxing both together

[Guest]

Do the time lengths of the demuxed *.mpa and the video differ (before you do any further processing)?

[CruNcher]

@neuron2

i found the problem the shown delay is wrong it shows MPA T01 DELAY -112ms.mpa -112 if i use -112 it does this http://cruncher.mufflastig.com/XviD/lengthprob.jpg if i dont use it it works :) but i think to mux it without a delay is wrong but the shown delay is also wrong pitty situation any idear ?

Avi File = 42:53:52 <- shown by VirtualdubMod
Mpa/Mp3 = 42:53:609 <- shown by Wave Editor /Nero

i think virtualdubmod is 42:53:520 so it would be 609 - 520 = 89 so actualy the file should show MPA T01 DELAY -89ms.mpa but its off by 23 ms correct ?

hmm i tested it muxing with the delay of -89 ms works :)

neuron2 could it be possible that the delay thats shown is wrong calculated now after your changes ?

[Guest]

Originally posted by CruNcher
neuron2 could it be possible that the delay thats shown is wrong calculated now after your changes? It's certainly possible. That is why I asked about it earlier in the thread. :)

I will investigate.

How do the numbers compare to what you get with 1.77.3 original?

[RB]

Donald, just wanted to thank you again and let you know that I've did quite a few DVD backups with beta 15 tools during the past days and there were NO issues whatsoever. Always accuare framecount, synced audio. Great!

[CruNcher]

@neuron2

sorry that it took so long here are my results but i can't see the answer i only think that those 2 artificial added frames are not calculated into the delay and then the delay of -112 gets wrong muxing the mpeg2dec3.dll and dvd2avi original one is no problem with the shown delay but muxing mpeg2dec3dg.dll and dvd2avidg files is wrong and result in the error shown above with avimux im confused sorry :(



Video = 25 fps PAL DVB stream


Using Mpeg2dec3DG.dll

1.77.3 original
delay shown = -112ms

Video = 64332 frames/25 = 2573,28s 42:53:28
Audio = 2573,448s*25 = 64336,2 frames 42:53:448

1.77.3 DG
delay shown = -112ms

Video = 64335 frames/25 = 2573,4s 42:53:40
Audio = 2573,448s*25 = 64336,2 frames 42:53:448
--------------------------------------------------
Using Mpeg2dec3.dll v 1.10

1.77.3 original
delay shown = -112ms

Video = 64330 frames/25 = 2573,2s 42:53:20
Audio = 2573,448s*25 = 64336,2 frames 42:53:448

1.77.3 DG
delay shown = -112ms

Video = 64333 frames/25 = 2573,32s 42:53:32
Audio = 2573,448s*25 = 64336,2 frames 42:53:448


both mp3 files are identical used the same besweet options @ 48khz where also crc checked

ok so what i heard from alexnoe maker of avimux is that 1 frame = 24ms @ 48khz so this would mean 2 more frames so it would be 24*2=48ms and then the -112-48=-64ms

Solution = On the fly adding those 2 frames to the (AudioPTS-VideoPTS)/90); and it should be right shown again for DVB content :)

i added this check now but somehow its only working for the 2 time you save the d2v anyone a idea whats causeing that ?


mpeg2dec.c

if (gop_warned == false && picture_coding_type == B_TYPE && !closed_gop)
{
MessageBox(hWnd, "WARNING! Opening GOP is not closed.\nThe first few frames may not be decoded correctly.", NULL, MB_OK | MB_ICONERROR);
gop_warned = true;

}


getbit.c


if ((AVI_Flag || D2V_Flag))
{
if (Method_Flag==AUDIO_DEMUXALL || Method_Flag==AUDIO_DEMUX && MPA_Track==Track_Flag)

{
if (gop_warned == true)
{
framedelay = 48;
}
sprintf(szBuffer, "%s MPA T%02d DELAY %dms.mpa", szOutput, MPA_Track+1, (AudioPTS-VideoPTS)/90+framedelay);
mpa[MPA_Track].file = fopen(szBuffer, "wb");

DEMUX_MPA

mpa[MPA_Track].rip = true;
}
}
}

[Guest]

@CruNcher

You're shooting yourself in the foot by encoding clips with an initial open GOP. I've suggested editing properly and asked you how you are producing these broken GOP clips, but you never answered.

But yes, I can modify it to adjust the delay if the initial GOP is open. Before doing that I'd like to understand how you are getting yourself into this condition.

Also, you appear to be confusing audio and video frames. If there are two additional video frames, wouldn't you adjust by 2 video frame times, not 2 audio frame times?

I do not understand your statement: "i added this check now but somehow its only working for the 2 time you save the d2v". Can you explain that better for me please?

[CruNcher]

You're shooting yourself in the foot by encoding clips with an initial open GOP. I've suggested editing properly and asked you how you are producing these broken GOP clips, but you never answered.


Jep sorry i record DVB content via a programm called www.progdvb.com
directly into mpeg2 not pva so i get a final mpeg2 ts and i can't controll when i push record that it should beginn recording on the next GOP sequence it just records the incoming Data and this can start @ any frame. Now what i would like todo is cut those bad frames out in dvd2avi with the seekbar but those 2 frames are not shown and with your dvd2avi 2 artificial frames are added but the sound delay is not taken into account so when i demux the file and the MPA shows a delay of -112ms it's wrong at least thats what i think because of the fact that when i try to mux with this -112ms avimux shows a error as you can see above a lower delay as that what dvd2avi shows works fine but i didn't knew wich is the correct one, so i asked Alexnoe what are those 2 artificial frames and he said 2 more audio frames would be 48ms so i took those into account and subtracted the -112 -48ms (2 frames) because the other 3 frames @ the end where allready their when Progdvb wrote the PTS so only those 2 artificial added ones by your code are missing that was the whole idea. Sure i would like to use those -112 but your code is adding those 2 artificial frames where the old dvd2avi just ignored them for DVB recording this was perfect but for correct VOBs it was not as we all know now.


Also, you appear to be confusing audio and video frames. If there are two additional video frames, wouldn't you adjust by 2 video frame times, not 2 audio frame times?


oh so it should be -80ms 2*40ms ? -112-80= -32ms


I do not understand your statement: "i added this check now but somehow its only working for the 2 time you save the d2v". Can you explain that better for me please?


I meant the first time you save a d2v and it demuxes the MPA it shows the delay as -112 the second time it showed -64 but you can use the preview then it will also be updated i think their is no other way ?

[Zeul]

I have a feature request:

is it possible that when DVD2AVI is doing its' thing that a small file could be created containing just the frame total for each cell. Listed for example like:
50
75
25 etc
This would just be an additional commandline argument

You may be wondering why I would want this. Well, I have noticed that when scanning the ifo file in NuMenu4u that occasionally a cell isn't listed anywhere, but is in the VOB file. I followed your suggestion in the development post, and I can parse the VOB but it is verrrrry slow.

And as the VOB is scanned anyway with DVD2AVI it makes a bit more sense to scan once.

Zeul

[D3s7]

Noticed something that's apparent in the last few betas of the new "no frame drop" builds

when working with a small (say 15frame) mpg the new dvd2avi will "GPF" or the XP equiv of...

anything larger it works great on but seems to have problems with smaller files.

I can reproduce this on any number of those small 15frame files I have

[Guest]

Can you please email me one of the short clips that fails? Please put "MAGIC" somewhere in the subject line and mail to neuron2@comcast.net. Thank you.

[D3s7]

Emailed them to you.....

I'm trying to get the full list of params passed to it from doitfast4u in case that has something to do with it although It does periodically blow up on it's own as well (manually opening the file)

[hakko504]

In this thread (http://forum.doom9.org/showthread.php?threadid=60449&goto=newpost), Kent Wang asked what was wrong with leaving leading NTSC intros in a movie so it could be force_filmed easier: That brought some old discussions back to my mind, namely one about hybrid NTSC/FILM stuff (http://forum.doom9.org/showthread.php?s=&threadid=39461) which are incredibly hard to IVTC, I thought, shouldn't it be possible to create Decomb overrides automatically when creating the D2V? That would speed up the FILM parts and only let decomb do it's calculations on the NTSC parts.

[D3s7]

Neuron:

ok more testing done... when calling latest version via CLI it blows up on me....

However, I think it might be a passing issue... if you do not call the full path to source (-IF) and dest (-OF) it appears to blow up even if source and dest file are current dir IE:
C:\Program Files\DoItFast4U>dvd2avicli.exe -FO=0 -CS=2 -IF=[X:\TT\VTS04\VTS__04_V14-no-cce.I-BFF.16~9_1.m2v] -OF=[X:\TT\VTS04\VTS__04_V13] -exit - this works (i'm in the dir where dvd2avi is)

BUT
"C:\Program Files\DoItFast4u\dvd2avicli.exe" -FO=0 -CS=2 -IF=[VTS__04_V13-no-cce.I-BFF.16~9_1.m2v] -OF=[VTS__04_V13-no-cce.I-BFF.16~9_1] -exit -- this blows up (i'm in the dir where the files are and point to dvd2avi)


Now if this logic is true, I have no idea why it blow up only on files with 15 frames or less unless that is called from a different routines
_______________

The testing continues... problem appears (for me) on the -IF line for long source file names...

example -VTS__04_V14-no-cce.I-BFF.16~9_1.m2v - that dies but
VTS__04_V12.I-BFF.16~9_1.m2v seems to be ok....

I'm thinking it's something in the input file name code for the CLI - I looked but I'm rusty w/ my C++

- D3s7

[Guest]

Thanks, that should be enough information to enable me to fix it when I get home from work.

[D3s7]

Great!

I was able to verify that passing the current path as well as the filename for input file works for all files

strange just fails on certain file names "like ones with -no-cce"

[Eyes`Only]

It seems that your CLI requires paths to be present in the input filename, whereas DVD2SVCD's version didn't require this. I've modified my app to now always include them, which d3s7 has tested and is working fine. Hopefully this is the only issue we find with DoItFast4U integration (besides the hdd mode not working because the switches have been removed), because I'd like to add your app to my first new beta, which is coming soon.

[Guest]

Originally posted by Eyes`Only
It seems that your CLI requires paths to be present in the input filename, whereas DVD2SVCD's version didn't require this. That's funny because IIRC I just ported DVD2SVCD's code. But I'll have a look at it tonight and fix it to not require full paths.

[Guest]

OK, I have posted beta 18 to fix these issues. If a file specified by the -IF or -AIF option does not include a path (i.e., does not include a \ character), then the current directory is searched. If the search fails, the file is ignored; it will no longer crash DVD2AVIdg.

BTW, I tried the DVD2SVCD version and it fails the same way, just as I expected.

http://neuron2.net/fixd2v/decodefix.html

[Eyes`Only]

Thanks for the fix. Strange, that's the syntax I use with the DVD2SVCD version and it's never failed on me.

[Guest]

Yes, strange, but not worth worrying about.

I'd appreciate feedback on whether beta 18 works OK with respect to this issue. Thank you.

BTW, you should be able to achieve the goals of the HDD feature using available options. Is that not the case?

[D3s7]

Just tested new build with version of DoItFast4u w/out path additions and it works for me now

Thanks!

[Guest]

Originally posted by hakko504
In this thread (http://forum.doom9.org/showthread.php?threadid=60449&goto=newpost), Kent Wang asked what was wrong with leaving leading NTSC intros in a movie so it could be force_filmed easier: That brought some old discussions back to my mind, namely one about hybrid NTSC/FILM stuff (http://forum.doom9.org/showthread.php?s=&threadid=39461) which are incredibly hard to IVTC, I thought, shouldn't it be possible to create Decomb overrides automatically when creating the D2V? That would speed up the FILM parts and only let decomb do it's calculations on the NTSC parts. I agree that Decomb override files could be automatically created, and that it might be useful in some scenarios. But rather than modifying DVD2AVI to do it, it would easy to make a program that reads the D2V and spits out a Decomb override file. In fact, a slight modification of ParseD2V would do it. I'll try to find time to implement that.

This thing you wrote elsewhere worries me:

Actually it is even worse, it decimates every 5th field, so that if you have a correctly telecined 1t1b 1t2b 2t3b 3t3b 4t4b sequence, it will produce 1t1b 2t2b 3t3b 4t4b. But if you have NTSC 1t1b 2t2b 3t3b 4t4b 5t5b then you will get 1t1b 3t2b 4t3b 5t5b. Ouch! top first becomes bottom first. If that is true it needs to be fixed! I plan to investigate further about this. Maybe it explains why Force Film is often unsatisfactory when it is not clear why that should be so. Maybe there is a better way to do Force Film, and that way would obviate the need for special Decomb processing of hybrids (to put it simply: make better decimation for video sections in DVD2AVI itself when Force Film is enabled).

[DDogg]

(to put it simply: make better decimation for video sections in DVD2AVI itself when Force Film is enabled). I hope you decide to pursue this. I sense you want to remain very conservative in your approach to reworking dvd2avi and concentrate on fixing problems. I think a strong argument could be made that the present implementation of FF is a problem that needs correcting rather than an additional feature. FF comes from way before there was any deinterlacing/decombing filters except manual IVTC in TMPG. It is pretty old stuff.

The 95% thing has always bugged me. It is like we are telling folks to except a 5% error like that is ok. Given that you now know the innards of dvd2avi and I think you just might know a thing or even two about dealing with hybrid sources :), it seems like the logical next progression of dvd2avi.

If you do decide to look in to it, would you expect it to be fairly straightforward or do you think it might turn out to be a can of worms?

[Jeffster]

I think I've found a bug with MPEG2Dec3dg.dll

I've just encoded a movie using beta16, and noticed a nasty green frame (http://homepages.ihug.co.nz/~jefx/doom9/green_frame79575.jpg) about half way through the movie. There may possibly be more, but I was scanning for a suitable place to split the encode into 2 CD's when I found it. I was about to curse DivX, but loaded the avs into VDubMod and sure enough the green frame was in the source too.

I've just now made a new d2v with the original DVD2AVI and loaded the avs script using MPEG2Dec3 1.10, and no green frame... then using MPEG2Dec3dg the green frame is there at the identical frame number as before, so realized it wasn't the d2v file. Also using the d2v file made by DVD2AVIdg, but substituting MPEG2Dec3 1.10 then the green frame is no longer there either, only when using MPEG2Dec3dg.

It was a NTSC DVD with Force Film enabled. Also I've determined that the frame is part way in vob3, not at the beginning or end.

I'm not sure what other info you would like to help with this?

Regards
Jeff

[hakko504]

Originally posted by neuron2
I agree that Decomb override files could be automatically created, and that it might be useful in some scenarios. But rather than modifying DVD2AVI to do it, it would easy to make a program that reads the D2V and spits out a Decomb override file. In fact, a slight modification of ParseD2V would do it. I'll try to find time to implement that.
Thank you :)
This thing you wrote elsewhere worries me:Actually it is even worse, it decimates every 5th field, so that if you have a correctly telecined 1t1b 1t2b 2t3b 3t3b 4t4b sequence, it will produce 1t1b 2t2b 3t3b 4t4b. But if you have NTSC 1t1b 2t2b 3t3b 4t4b 5t5b then you will get 1t1b 3t2b 4t3b 5t5b. Ouch! top first becomes bottom first.

If that is true it needs to be fixed! I plan to investigate further about this. Maybe it explains why Force Film is often unsatisfactory when it is not clear why that should be so. Maybe there is a better way to do Force Film, and that way would obviate the need for special Decomb processing of hybrids (to put it simply: make better decimation for video sections in DVD2AVI itself when Force Film is enabled). Quite frankly, I'm not so sure it is correct. When I first wrote it I had only a basic knowledge of the code, and it was written with the intent of keeping people from using FORCE FILM on NTSC stuff. After re-examining the code today, I'm more inclined to say that it is full frames that are dropped, not fields. Still, an improved process for dropping frames (or fields) would be beneficious in many cases.

[Guest]

Originally posted by Jeffster
I think I've found a bug with MPEG2Dec3dg.dll I'll have a good look at the FF mode code tonight. Can you tell me whether it happens only when FF is used, and how do you know the location was not near a transition point between VOBs? Thank you.

[Jeffster]

Originally posted by neuron2
I'll have a good look at the FF mode code tonight. Can you tell me whether it happens only when FF is used

hmmm... well I just made another d2v with Field Operation set to None, and there isn't a green frame at that location in the movie anymore. I don't want to send you searching in the wrong direction but perhaps there is a link with FF mode?

(Video type is FILM, and at the bottom of the d2v says 100.00% Film)



and how do you know the location was not near a transition point between VOBs? Thank you.

I had wondered if it was at a transition point, so I opened each vob directly in VDubMod to find the scene where the green frame appeared, and it was approx. 6200 frames into vob3.

Jeff

[Guest]

Originally posted by Jeffster
so I opened each vob directly in VDubMod to find the scene where the green frame appeared You opened it directly in VDubMod without using MPEG2DEC3dg? And you still got a green frame? Then how can you blame MPEG2DEC3dg?

If I am misunderstanding you, please explain how you opened the VOB directly in VdubMod but still used MPEG2DEC3dg. VDubMod builds its own D2V file and uses that in conjunction with its own MPEG decoder.

[Jeffster]

Originally posted by neuron2
You opened it directly in VDubMod without using MPEG2DEC3dg? And you still got a green frame? Then how can you blame MPEG2DEC3dg?

If I am misunderstanding you, please explain how you opened the VOB directly in VdubMod but still used MPEG2DEC3dg. VDubMod builds its own D2V file and uses that in conjunction with its own MPEG decoder.

You are correct that VdubMod parsed the vob file itself when I opened it. What I meant was, that is how I knew it wasn't at a transition point, by viewing the vob file directly to find the position where that scene appeared in the vobs... and there was no green frame in the vob file. The only reason I tried to load the vob files directly like that was to see if it was at a transition point.
It is only when loading the d2v via an avs script using MPEG2Dec3dg I got a green frame.

I hope that makes more sense?

Jeff

[Eyes`Only]

Originally posted by neuron2
Yes, strange, but not worth worrying about.

I'd appreciate feedback on whether beta 18 works OK with respect to this issue. Thank you.

BTW, you should be able to achieve the goals of the HDD feature using available options. Is that not the case?

I am not doing many DVDs these days (I'm coding rather than backing up DVDs) so I'll let my excellent testers like D3s7 do the feedback reports :)

Yes, I believe the new switches you added/changed will do the same thing, once I've figured them out and adjusted the code.

[D3s7]

I'd like to put in a request for next beta..

would it be possible that if run from CLI (command line) that the GOP closed warning not pop up.....

running on 60+ VOBID's and having to sit here to click that "OK" on 20+ kinda sucks :)

Thanks

- D3s7

[Guest]

Sure, I can do that. But why do 20+ of your VOBs have open initial GOPs?

[D3s7]

Good question..... wasn't really 20.. that was a slight overage... more like 5-8

actually was more of a firm point then reality :)

[Guest]

@Jeffster

Please email the D2V file that produces a green frame to me at neuron2@comcast.net. Also, in the email tell me the frame number of the green frame. Thank you.

[Jeffster]

@ neuron2

Email sent :)

I've also cut a small piece from the 3rd vob file (8.4 MB) and uploaded it to my homepage server. I'll leave it there for a few days if you want to download it and try to reproduce the problem (take note of frame 97). You can download it here (http://homepages.ihug.co.nz/~jefx/doom9/).

Using DVD2AVIdg with FF enabled, and loading an avs file with a LoadPlugin and MPEG2source line, I still get a green frame even from the extracted vob sample.

I wonder if there is some weird anomaly with this vob file that is causing the problem, if so that would be good news... on the other hand, why does MPEG2Dec3 v110 not produce a green frame.
:confused:

Hope this helps

Jeff

[Guest]

Thank you, Jeffster. With your VOB I was able to duplicate the problem. Force film is indeed broken. I will fix it this evening.

Interestingly, your bug has revealed something about force film that hasn't been explicitly noted before, at least by me if not others. Previously we thought you treated the film by just ignoring the RFF flags and the video by decimating (skipping) 1 in 5 frames. But you can also have a need to add (repeat) frames! If your flags sequence is for example 13131313..., and you just ignore RFFs, your result will play too fast at 24fps, and frames need to be repeated. My code did not allow for this.

Your D2V had a flags sequence around frame 97 of 3131, and that triggered a repeat in the FrameList table, which my code is (temporarily) unable to understand. :(

[Jeffster]

Thanks neuron2. I don't pretend to understand everything you just said, but it's lucky that you do (I can see the 3131 where you said, but wouldn't want to wade through a D2V for the complete movie to find it). :)

I'm glad it wasn't a false lead, and may have helped to improve the great work you are doing. Sorry if it means more work for you though.

Jeff

[AndyP]

Hi

Quick question. I think this has been answered already but can I just confirm that I can replace the dvdavicli.exe and mpeg2dec3.dll in the doitfast4u 1.3.1 package (which the changelog says is compatible with the commandline options) with the new ones here, and DoItFast4U will still work. I have tried it and everything appears to be in order but I just wanted to check I am not screwing anything up!

Thanks,
Andy

[Eyes`Only]

Except for the hdd demux feature, I believe it to be compatible. I haven't included it because IMO it is still being refined, and I'd rather not have my NTSC users complaining to me about rushing an integration. I haven't tweaked the hdd demux yet though (hdd demux always takes low priority on my list of to-do)

[len0x]

Originally posted by AndyP
I have tried it and everything appears to be in order but I just wanted to check I am not screwing anything up!


You should be fine as long as you have Output Method set to Demux by default in DVD2AVI.ini file (coz this is new option in 1.77.3 and hence is not implemented in the tools using 1.76 CLI)