DGMPGDec 1.4.6 Final

[Guest]

Actually, I just looked again and not only are they corrupted, but they have different frame sizes!

Multiple files loaded at once MUST have the same parameters.

[Tima]

DGIndex should handle this easy situation and prevent user from making mistakes.. ;)

[Fishman0919]

LOL, I go to neuron2 site and download 1.46 rc1 and del the zip by mistake... I go back sec's later to re-download and the final is out

[Guest]

http://neuron2.net/dgmpgdec/dgmpgdec.html

[video_magic]

Hello, I have just used the 146final dgindex and dgdecode on a 4/3 clip and created a d2v. However it doesn't display at 4/3 in preview in dgindex, and when I open the d2v in virtualdub 1612 via the following avs:

loadplugin("C:\asblah\dgmpgdecv146b2\DGDecode.dll")
mpeg2source("D:\gotmj\MJinRomania.d2v")

it also displays not at 4/3.

Here are two screenshots to show what happened.
http://rapidshare.de/files/12643368/dg_v146_mjromania_not_display_43.png.html
http://rapidshare.de/files/12643559/dg_v146_mjromania_not_display_43_d2v_in_Vdub1612.png.html

[Jeffster]

Maybe it's because your clip is 1/2 D1 (352x576) ?

As far as I know DGIndex doesn't resize it's display window for PAR/DAR so this is nothing new to 146 final.

[video_magic]

Oh yeah, I see - it is displaying at pixel dimensions. Sorry, I must not have worked with other clips of those dimensions in dgmpgdec before.

[netchris]

Hi there, i have a prob, that i cant find a solution no matter how hard i searched. :(
Im Using ver. 1.4.6.
First there is an error thats been there for ages, but iirc i could use megui some months ago, nontheless.
When i open an .mpeg file (its a sat stream) in DGIndex, i get the warning "Opening Gop is not closed. The first few frames might not be decoded correctly"
I assume this is related to the way progdvb (a dvp progr with record option) creates mpeg files.
The serious error now..
When i create a d2v file, and try to open it in Megui's avisynth script generator i get this error "DGindex reported 0 frames in this file. This is a fatal error. Please recreate the DGindex project". Creating new d2v files with options correct field order and force open gops in d2v file, doesnt help either.
I think i have my system setup just fine (with DGDecode.dll @ avisynths plugin folder). So im clueless how to fix it.
Any help appreciated.

P.s. i post this here and not the Megui forum because i think its a prob. related to the d2v file created from DGIndex.

[Guest]

P.s. i post this here and not the Megui forum because i think its a prob. related to the d2v file created from DGIndex. This belongs in the Megui forum. I can't help you with Megui. Usually, problems like this are caused by changes in the D2V file format. Ensure that Megui is OK with D2V file format version 13.

The GOP warning is harmless.

[Chainmax]

Sorry for the dumb question, but is v1.4.6 final the one labeled as v1.4.6 or is that one of the betas/RCs? Could you update the page with that information?

[Guest]

Sorry for the dumb question, but is v1.4.6 final the one labeled as v1.4.6 or is that one of the betas/RCs? Could you update the page with that information? Any version without a beta or RC number specified is a final version. Therefore, "1.4.6" is the final (source code released) version of that revision.

[AllTimeSToneD]

@neuron2
Thanks for 1.4.6 final!
btw,did you have a chance to take a look in xport.exe's source code?
Just curious if its gone help fix the 4bit bug somehow ;)

[Guest]

btw,did you have a chance to take a look in xport.exe's source code? I had a brief look and tried several different demuxing tools on a given stream. They all came up with different sizes! One thing I noticed is that DGIndex throws data away until the first sequence header, while some other programs don't. That would provide one reason for a difference in size. I didn't notice any case where the last 4 bytes were missing. Have you?

[AllTimeSToneD]

One thing I noticed is that DGIndex throws data away until the first sequence header, while some other programs don't.
Yes thats something i also noticed while comparing the files (one demux by dgindex and one by xport) in binary mode.
That would provide one reason for a difference in size.
Yes indeed, but seen with a real binary compare that diffrence is applied at the beginning of the demuxed video file but not for the end. At the end dgindex always drops 4bytes no matter how often you demux and remux a file.

Just to make sure i also did a test with 1.4.6 final and results were the same.
http://img472.imageshack.us/img472/5605/comapre1463td.th.jpg (http://img472.imageshack.us/my.php?image=comapre1463td.jpg)
Don't get me wrong i don't want the same output as with xport.
All i wanted is to point out that weird bug/behavior. ;)

[Guest]

Please tell me the exact steps you went through. Thank you.

[AllTimeSToneD]

I've uploaded the ts stream i used for my tests to your ftp. A not to long and not to short teaser trailer of superman :D

1st step:
Demux the ts with DGindex to its elementary streams (lol i dont really have to tell "you" how) :)

2nd step:
Open the muxer.config in muxer.rar (see pm for details) into Notepad (or any other editor) and change the file location for the m2v/ac3 and output file.
Use the muxer to mux the new stream for our 2nd demux.

3rd step:
Demux the newly created ts using DGindex again and compare its m2v using a Hex Editor such as Hex Workshop with the previously demuxed m2v from step 1.

[AMED]

Hi,

I just ran an NTSC movie through DGIndex 1.46 and noticed that the frame rate is incorrectly reported

v1.46 says the movie is 29.970030
http://img145.imageshack.us/img145/2969/ntsc1462od.th.png (http://img145.imageshack.us/my.php?image=ntsc1462od.png)

v1.45 says the movie is 29.970
http://img482.imageshack.us/img482/1672/ntsc1451bq.th.png (http://img482.imageshack.us/my.php?image=ntsc1451bq.png)

[Guest]

I just ran an NTSC movie through DGIndex 1.46 and noticed that the frame rate is incorrectly reported

v1.46 says the movie is 29.970030
v1.45 says the movie is 29.970
Actually, 1.4.5 was not accurately storing and representing the NTSC frame rate.

The NTSC frame rate is 30000/1001 = 29.9700299700299700... ~= 29.970030.

[AMED]

ahh, i was trying v1.46 with AutoGK 2.26 and it fails because of this difference in reporting the frame rate.

[Inventive Software]

I have a slight issue with the "Fix GOP order" setting. I have a short movie that loads and plays absolutely fine without this setting. However, with the setting enabled, there appears to be interlacing artefacts, even though DGIndex reports the movie as "Progressive". I have resorted to not enabling "Fix GOP order" in order to get the movie to convert correctly, but I though I ought to flag the problem up.

[Guest]

Sorry, but I do not know of any "Fix GOP Order" option in DGIndex.

[Inventive Software]

Sorry, Fix GOP Order isn't entirely accurate. What I'm on about is something like (off the top of my head) "Correct Field Order". Does that sound right?

[Guest]

Sorry, Fix GOP Order isn't entirely accurate. What I'm on about is something like (off the top of my head) "Correct Field Order". Does that sound right? If you'd like to upload an unprocessed source fragment to my FTP, I'll have a look at it.

Yes, fixing the order can create combs that need to be deinterlaced. You're able to choose between that and generating an output stream with an inconsistent field order (may not matter for progressive material).

[Inventive Software]

Sorry, the inconsistent field order isn't exactly correct, as the file marked "bad" by DGIndex plays absolutely correctly in any media player and when converted. I'll see what I can do about the sample.

[FreQi]

I noticed that for some reason, .d2v's made by v1.4.6 seem to have Frame Rates that are slightly off. If I use AVISynth's Info() function it'll show a clip that is 720p at 59.940fps as having 59.9401. Here's a couple examples...

Using DGIndex v1.1.0 (DGIndexProjectFile06) - 59.9400fps (http://i1.tinypic.com/o85cwm.png)
Using DGIndex v1.4.5 (DGIndexProjectFile11) - 59.9400fps (http://i1.tinypic.com/o85f2o.png)
Using DGIndex v1.4.6 (DGIndexProjectFile13) - 59.9401fps (http://i1.tinypic.com/o85fur.png)

In fact, even the Information screen from DGIndex (http://i1.tinypic.com/o85hmw.png) shows that the frame rate is weird: 59.940060 fps ...

All three of the above examples were launched using the exact same command line options onthe same transport stream file:

C:\path.to\DGIndex.exe -BF=[F:\path.to\files.bfl] -VP= 31 -AP= 34 -YR=1 -FO=0 -OM=2 -OF=[F:\path.to\files] -exit


I have not tried this on 1080i clips, so I don't know if they are also affected. This is a bug right?

[JuanC]

... Information screen from DGIndex shows that the frame rate is weird: 59.940060 fps ... Take a look at this post from neuron2 (http://forum.doom9.org/showthread.php?p=786228#post786228) in this very same thread. 1.4.6 is more precise than previous versions at handling and displaying frame rates.

[FreQi]

Hrm. I'm not sure how I feel about that.

I've grown up knowing that NTSC is 29.970fps. Am I supposed to believe that 29.97 is now wrong since it's actually more like 29.970030 or do I just ignore anything past the third decimal and just call 29.97 sorta inacurate... VDMod still shows only 3 decimals... does it round or truncate?

I only ponder this because of my work on theeo which is showing this new, and apparently more accurate frame rate, so my sanity checks are failing because 59.94006 <> 59.940 and 23.97602 <> 23.976.

I'll probably end up rounding I guess.

[Wilbert]

I've grown up knowing that NTSC is 29.970fps. Am I supposed to believe that 29.97 is now wrong since it's actually more like 29.970030 or do I just ignore anything past the third decimal and just call 29.97 sorta inacurate...
You are never too old to learn something :) Look up the documentation of avs' ShowSMPTE and read the stuff about drop-frames. This results in the weird looking ratio 30000/1001.