Support forum for DG Tools

Here's a new toy to play with. It's an auto-indexing version of 64-bit DGDecode.dll. Currently Avisynth only. Make sure that DGIndex.exe is in the same directory as DGDecode.dll. Sample script:

loadplugin("...\DGDecode.dll")
MPEG2Source("Nature.ts")

Note that this build also fixes long-standing problems with the parameters: idct, showQ, and info were all broken (d2v and fieldop were OK).

Your test results will be appreciated. This will be ported to the 32-bit version and DGDecNV, as well as Vapoursynth when it is shaken down. Thank you.

https://rationalqm.us/misc/DGDecode64_test.rar

EDIT: Added the link.

Test file: https://rationalqm.us/misc/lainvob.vob

Error message: MPEG2Source: cannot index the source file "C:\lainvob.vob"

Opening the new DGIndex.exe GUI to manually create the d2v file works fine though.

It's probably something trivial that's blocking it on my system somehow.

I do see for a split second a window open and then close, as if it's trying to do something. But it stays on screen too short to know what it's doing. Maybe has the wrong path or something.

I'm on Windows 7 logged in as Administrator and User Account Control set to its lowest security setting, no Antivirus software installed.

I think I know what's happening - that lain.vob file has some unusual field order transition which throws a warning message which is halting DGIndex. Perhaps an "ignore warnings" setting is needed.

By the way, here is another clip from that same DVD which cannot be indexed with DGIndex, but can be indexed by LWLibav: https://drive.google.com/u/0/uc?id=1QaV ... t=download

DGIndex halts with "picture error". I'm guessing the MPEG2 stream has some stream errors in it? It would be nice if DGIndex was more fault-tolerant I guess.

In case it's of any help here is another test file that DGIndex cannot process ("picture error"):
https://drive.google.com/u/0/uc?id=1xz_ ... t=download

Thank you and welcome to the forum, flossy_cake. I'll do some investigating and reply later today.

Let's start with lainvob.vob. It works fine for me. The order transition popup is automatically suppressed in CLI mode. Sounds like it simply is not finding DGIndex.exe. Can you do three things:

1. Tell me how you open the script.
2. Double check that DGIndex.exe is in the same directory as the DGDecode.dll that you are using.
3. Please give me your script. Here is mine:

loadplugin("D:\Don\Programming\C++\DGMPGDec_VS2019\DGDecode64\x64\Release\DGDecode.dll")
MPEG2Source("lainvob.vob")

Note that DGIndex.exe is in the same directory as the plugin path above.

Regarding the picture errors, DGMPGDec does not support MKV files! It is derived from jackei's DVD2AVI, which worked with DVDs so started off in life supporting only VOB. It was subsequently enhanced by others to support elementary streams, program streams (.mpg), and transport streams. For MKV support you need the DGDecNV variant. Do not rip to MKV if you want to use DGMPGDec. Or demux them and load the M2V elementary stream in your script.

BTW, jackei is the guy who first figured out how to do TFF/RFF handling (and force film) correctly. He's a legend.

It sort of plays for a while before crashing but that is just luck. I should add a check to reject MKVs. It also might help to mention in the user manual what stream types are accepted. In our defense, realize that back then MKV did not yet exist.

While many still use DGMPGDec for DVDs it's hardly a state-of-the-art solution these days. However, it still works well in its domain and stands as an open-source example of how to do TFF/RFF correctly, which I understand is your motivation here. There should be no excuse for flubbing that.

OT: You should seriously consider switching to an nVidia card. You won't regret it! It's kinda like when I finally ditched my flip phone for a smart phone. Why did I wait so long?! People were laughing at me.

Less talking, more doing.

Just ignore Natasha. I tried to get her banned but she has a reputation. Maybe DG has a thing for her.

when u take over the forum and become admin u can ban her

I updated the test build to explicitly test if DGIndex.exe is where it should be.

https://rationalqm.us/misc/DGDecode64_test.rar

Rocky wrote: ↑

Fri Dec 01, 2023 8:52 am

I updated the test build to explicitly test if DGIndex.exe is where it should be.

https://rationalqm.us/misc/DGDecode64_test.rar

Thanks, and I'm still getting the same error message. I tried at ffmpeg.exe command line and in MPC-HC, same error message on both. Avisynth version 3.7.3 r3936.



Incompatibility with mkv's is kind of a dealbreaker for me - I converted all my physical copy DVDs to mkv's with MakeMKV. Having to go back and redo them all as vobs would take weeks, maybe even months.

I'm surprised about this repeat field issue because if RFF is not supported, many NTSC DVDs will not play properly, either with wrong frame pacing or audio sync issues, as you've written about here and is consistent with my experience also. It seems the only avisynth filters which can obey RFF are DGDecode and LWLibAv. There is also FFMS2 filter but it the RFF handling is broken - I lodged an issue to the git here but it probably won't get fixed so LWLibav and DGDecode are probably the only 2 options for correct NTSC DVD playback on PC.

Ah! I just forgot to generate the command line with quote marks around the arguments so if any path has a space it will bomb. OK that will be easy to fix, which I will do tomorrow. Thank you for the feedback that made that clear.

Sorry you've done everything in MKV. Actions have consequences. But you keep neglecting DGDecNV which accepts MKV and does TFF/RFF correctly too! As I said: You should seriously consider switching to an nVidia card. Or demux to ES when processing.

I might be able to fix ffmpeg. I'll have a look. The link you gave to your git entry appears wrong (points to one of my posts here). Can you give me the correct link please?

You said LWLibav works. Why can't you use that?

Rocky wrote: ↑

Fri Dec 01, 2023 9:30 pm

I might be able to fix ffmpeg. I'll have a look. The link you gave to your git entry appears wrong (points to one of my posts here). Can you give me the correct link please?

Fixed the link, thanks. I think it might just be a field order problem, so maybe it's repeating the wrong field. I'm not sure though. AssumeTFF/BFF doesn't fix it, it seems dynamically wrong which is consistent with the repeat field alternating between top and bottom in line with the 3:2 cadence.

Rocky wrote: ↑

Fri Dec 01, 2023 9:30 pm

You said LWLibav works. Why can't you use that?

I do use it but would like to have something else as a backup in case certain DVDs don't play nice with it. For example that S01E01 of Lain DVD when remuxed to MKV is not playable with LWLibAV with repeat field enabled (which is necessary for that DVD). Strangely I found that chopping off 0.5 sec from the end of the MKV file makes it work perfectly though - I guess there must be some strange data in that last 0.5 sec of the mkv that LWLibAV can't deal with. Or maybe MakeMKV screwed something up.

Rocky wrote: ↑

Fri Dec 01, 2023 9:30 pm

As I said: You should seriously consider switching to an nVidia card.

My lounge HTPC is Nvidia while the desktop used for the ripping/archiving work is AMD. It then gets transferred to the lounge HTPC for screening, so I'll definitely be giving it a try.

Great. Since you have LWLibAV and DGDecNV at your disposal, I'm not going to mess with ffmpeg. Could be a nightmare anyway. And StvG says he's looking into it.

Let me know how DGDecNV works out for you. I'm going to add the media file open functionality, which I have working now with proper quoting.

Thank you for your assistance in debugging this functionality.

I updated the test build with the quoting fix so if you could test that I'd be grateful.

https://rationalqm.us/misc/DGDecode64_test.rar

Rocky wrote: ↑

Fri Dec 01, 2023 11:50 pm

I updated the test build with the quoting fix so if you could test that I'd be grateful.

https://rationalqm.us/misc/DGDecode64_test.rar

Yep, it works, just not with mkv's like this one posted previously.

However, I somehow got it to create a d2v file with the above clip, which works and plays video. However I'm unable to reproduce the creation of the d2v file again. Either in the DGIndex GUI or through the new auto index functionality, it halts and fails to create the d2v file. So I have no idea how that working d2v file was created. It just somehow got created and works, it's a total mystery.

Here is the d2v file that works for the above clip:

Would be very interested if you are able to create it on your end, as I am unable to.

I'm not even going to try. Behavior is undefined if you try to use an MKV. Things will depend on random memory contents, etc.

I released this for DGMPGDec, so marking resolved. Moving on to DGDecNV...

Moving on up, to the East side.

Never let there be a doubt.

Hey Albert, what do you think about the recent Nobel Prize for the discovery of quantum nonlocality?

It's in the same class as Enrico Fermi's 1938 prize for the discovery of the fictitious elements “ausonium” and “hesperium”.

Noticed this behaviour in Avisynth...
I can avoid it by doing the audio first.

Also an improvement request if I may: could we have a string argument to set the DGIndex configuration. Reason: a fresh DGIndex.exe at default settings will demux all audio tracks and create a bunch of files alongside the source - I don't want to have to rely on instructing the user to manually open DGIndex.exe themselves and set it up to only create the d2v file otherwise they will wonder why its dumping all these audio files and consuming disk space.

Especially could we please have the -OF parameter so we can specify where to put the d2v file. I'm dealing with a huge library and need to have control over where my files go.

And could we please have the same for DGDecNV (I see you have updated that to support auto indexing as well - thank you very much).