DGMPGDec 1.4.6 Final [Archive] - Page 2

DaveId

13th January 2006, 22:02

Bug found in Beta 4, audio out of sync when using force film. it writes the field operation and proper frame rate to the d2v file, yet the framerate sticks at 29.970 causing the audio to be out of sync. i created a small test avs script with a short d2v project file & tested in media player classic (after realizing an entire dvd rip was screwed up) and the audio was off. i rolled back to 1.45 to fix the problem, and it did indeed fix it. this was not apparent in the last beta. just a heads up. i can provide test files if needed.

MacAddict

13th January 2006, 22:12

Arghhhh!! I been beating my head against the wall on this issue for 3 different movies!!! Thanks so much DaveId for the post.

tritical

13th January 2006, 22:23

Sorry guys, this one is big time my fault. My little patch didn't adjust the num/den values for the force film flag so it writes Frame_Rate=23976 (30000/1001) when it should be adjusting the 30000 at the same time the frame_rate value is adjusted. neuron2 should be able to fix it real quick. Sorry again.

Guest

13th January 2006, 23:21

I'll make a fixed beta by tomorrow morning.

DaveId

14th January 2006, 00:57

sweet, glad i could help get this fixed. i was scratching my head for a bit, and then realized that it was the only piece of software i upgraded. makes me feel good to have contributed at least a little something to the devolopment of a tool that has made my life a lot easier for the last few years of dvd ripping.

Guest

14th January 2006, 18:50

Here is the fix for the frame rate versus Forced Film problem.

http://neuron2.net/dgmpgdec/dgmpgdec146b5.zip

Thank you for pointing out the problem, DaveId.

DaveId

15th January 2006, 19:27

you are definately welcome, thank you for this wonderful program which has allowed me to easily convert 100s of dvds over the years..

TEB

16th January 2006, 17:13

Hi. Just a lil tidbit. I have this clip here that's a Progressive Pal mpeg2 clip in a frame structure.. Dispite that it still says Bottom under field Order, shouldnt it say NA for example there? I didnt know that it was possible to have a field order when the clip is in a frame mode?..

teb

Guest

16th January 2006, 18:23

You can encode interlaced video with frame structure. Therefore, the field order is still required.

TEB

16th January 2006, 19:22

Ok, but my clip was progressive.. shouldnt it then say NA? or am i very much mistaken?

Guest

16th January 2006, 19:27

The stream declares a field order and DGIndex reports it. Are you saying I should suppress that information?

TEB

16th January 2006, 19:43

not at all, im just curious why a progressive stream reports a field order.. gotta be something wrong with the encoder imo..

Guest

16th January 2006, 19:56

Just because the frames are encoded progressive, that doesn't mean that you necessarily have progressive_sequence=1. Anyway, if you want the gory details on the semantics of the TFF flag, please refer to the specification. You need to know the progressive_sequence value, the picture_structure, and the RFF flag value to properly interpret the TFF flag. I just give its value in the info dialog, and do not give an interpetation.

Tima

18th January 2006, 22:47

Maybe a bug.. or I am just doing something wrong?

1. Download http://for_spam.gorodok.net/misc/panic_room.rar (25814 bytes)
2. Drag'N'Drop the content to DGIndex.
3. Make one step left on the timeline :)

I get this error message:
---------------------------
Ошибка
---------------------------
Caught an exception during decoding! See help file.
---------------------------
ОК
---------------------------

Also there is a strange behavior when I try to preview this content..

Guest

18th January 2006, 23:34

Your link is not working. Can you check it?

onesoul

19th January 2006, 00:03

@neuron2
The file is so small that I didn't even see it downloading.

@Tima
I tried it and didn't get any error, I don't know if I did everything right..

Tima

19th January 2006, 00:10

Hmm.. checked it and it works fine..

I have problems with attaching the file to this post, so try this link: http://www.megaupload.com/?d=L75LM8AX

Guest

19th January 2006, 00:56

I downloaded the files and see they are corrupted single frames. But I cannot make DGIndex crash as you have.

Tima

19th January 2006, 03:53

I downloaded the files and see they are corrupted single frames. But I cannot make DGIndex crash as you have.

Do you add two files at once?

shawn8888

19th January 2006, 04:51

Dear neuron2

I found it is not possible to add over 80 vob files in file list window. Some times I got more than 200 vob files when splitting by CellID and it is painful to add them several times.

Another problem I found in 1.46b4 is about synchronization, could you please take a look at this post?
http://forum.doom9.org/showthread.php?t=105933

Thanks a lot!

Guest

21st January 2006, 04:37

* DGVfapi's handling of audio from avisynth scripts was fixed. It didn't set
values for dwBlockAlign and dwReadedSampleCount, and it should be
converting the output to 16-bit integer if it isn't already in that format.
Changes by 'tritical'.

* The old "Fix D2V" tool is back in a new guise: the "Correct Field Order"
option. Refer to the manual for details.

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

Tima

21st January 2006, 13:33

A note about my samples: there's no error message about an exception when I look at these two files independently - the error occurs only when adding both files to one project..

Another 'bug' occurs when DGIndex runs at idle priority and my cpu is heavily loaded with another task at normal priority. If I strike F5 immediately after loading vob, DGIndex complains there's no PID's or something like that. If I wait for some time, it loads and plays good. Maybe DGIndex shouldn't interact with user before the vob is loaded properly..

AllTimeSToneD

21st January 2006, 20:20

Has the demuxing bug (last 4 bytes) been fixed too?

Guest

22nd January 2006, 01:58

Has the demuxing bug (last 4 bytes) been fixed too? Not yet. There are so many termination possibilities that this will require a tough several-day attack, and I just haven't built up the energy for that yet. Patience.

levi

22nd January 2006, 18:09

The old "Fix D2V" tool is back in a new guise: the "Correct Field Order"
option. Refer to the manual for details.

Excellent. Thanks for putting this back in. It really is a handy feature, and unfortunately, I run in to these annoyances quite often.

netchris

23rd January 2006, 00:46

Thanx alot for this fix tool, i run in to these annoyances quite often too when creating d2v files from dvb ones.

Bathrone

23rd January 2006, 09:55

Weve got lots of patience thanks Neuron2. The contribution you have made to the community it simply outstanding. In fact, if you ever come to Australia I see it as my personal mission to show you the delights of this great country.

Tatsh

25th January 2006, 21:55

I had problems with Forced Film (Sopranos Season 4 DVD). It would cause the video to play faster. I reverted back to 1.4.6 beta 1.

Guest

26th January 2006, 02:19

I had problems with Forced Film (Sopranos Season 4 DVD). It would cause the video to play faster. Which version of DGIndex were you using? Does it fail with the latest beta 6?

Guest

27th January 2006, 03:13

This version fixes the truncation of the last few bytes of demuxed M2V files.

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

Guest

27th January 2006, 23:24

all .ts were consistent with each other, and I could add them all to the list, just not all at once, only in batches of 64 at a time.

/edit: ok, just got home, still can't add more than 64 at a time to the list. I'll try to fix this before going final with 1.4.6.

Now is the time to speak up if anybody thinks there are any must-fix issues remaining for release of 1.4.6.

Guest

28th January 2006, 01:30

I'll try to fix this before going final with 1.4.6. OK I have the file loading problem fixed.

Last call for must-have fixes for 1.4.6..........

Tatsh

28th January 2006, 05:27

Which version of DGIndex were you using? Does it fail with the latest beta 6?

Yes. This is why I reverted back.

During conversion, the framerate is sped up rather than converted. These framerate numbers are quite different from the other verison I reverted back to. I can't be sure if it's just these VOBs.

Guest

28th January 2006, 05:49

During conversion, the framerate is sped up rather than converted. These framerate numbers are quite different from the other verison I reverted back to. I can't be sure if it's just these VOBs. Can you post the header part of the D2V file that you made with the failing version, please?

EDIT: I just did a rip of the first episode of Sopranos 4th. I used RC1 to make a forced film project and XviD encoding at 23.976. Everything went perfectly normally.

AllTimeSToneD

28th January 2006, 12:23

This version fixes the truncation of the last few bytes of demuxed M2V files.

Thank you so much for the fix! :)
/me hugs neuron2

Edit:

I have just tested the RC1 build and found that its still dropping the last 4 bytes when demuxing a ts stream? Was the fix applied in the RC1?

How i tested the demux for the fix.

Demuxed with RC1 a hdtv trailer of superman which i capped from hdnet.
Remuxed the ES's with a ts muxer and demuxed using RC1

Guest

28th January 2006, 15:28

Demuxed with RC1 a hdtv trailer of superman which i capped from hdnet. Remuxed the ES's with a ts muxer and demuxed using RC1 How did you rule out that the ts muxer lost the bytes? Can you demonstrate an issue without the extraneous tools?

AllTimeSToneD

29th January 2006, 12:03

How did you rule out...

I've used another ts demuxer, which is simply called xport.exe it can be found in the avsforum (will edit link later) and compared its mpeg es output with the one created by dgindex. I also did a demux->mux->demux with xport.exe before that to verify that it is not the ts muxer(mux) that discards those last 4 bytes. The output of xport was the same as the given input.

I probably could use xport for that task but i really like dgindex and wanted to help iron out this bug. I hope it does not lead to any headaches or sleepless nites. :D I really appreciate your work!

Guest

29th January 2006, 17:49

I've tested the fix only for program streams. I'll look more closely at the handling for transport streams. Do please provide the link for xport.exe.

EDIT: I found xport.exe. Investigating...

AllTimeSToneD

29th January 2006, 18:50

Here is the link to Dr1394's xport.exe (http://www.w6rz.net/xport.zip) including source code, the main site (http://www.w6rz.net/) provides Mpeg2 HD test patterns which from time to time come in handy for ones setup and could also be used as test samples for demuxing ;)

Guest

29th January 2006, 19:04

Rockas

31st January 2006, 23:40

@neuron2
Is there a possibility to add the avrg bitrate to the project file?
I'm asking you this 'cause if you have that function while playing it could be usefull to have it on the project besides... it's faster to access that info on the d2v file than to watch a whole VOB or group of VOBS to know the avrg bitrate :)

I know that there are other tools out there where I can see that info, but comparing those applications with the ones made by you... well... my trust goes totally for you (this is no but kiss lol)

Wilbert

1st February 2006, 00:06

Guest

1st February 2006, 01:32

Bug in colorimetry DGIndex:

http://forum.doom9.org/showthread.php?p=778326#post778326 (and two posts below):

"when I preview the VOB in DGIndex it says BT.709, but after it finishes creating a d2v project file it says SMPTE 170M."

SMPTE 170M should be BT.601. I had a look at the code and things appear OK. I also tested several VOBs and didn't see this. You'll notice that when saving project the Colorimetry box in the Info dialog is blank until the save project operation is done and DGIndex writes a frame to the window. At that time it gives the colorimetry that it last read from the stream, i.e., at the end of the stream. So, I'm wondering if this VOB changes colorimetry. One thing to try is load the VOB and set the range to be the last GOP only. Then do a preview and see which colorimetry is reported.

To diagnose this fully, I need the VOB or a fragment of it that shows the problem.

Guest

1st February 2006, 17:33

@neuron2
Is there a possibility to add the avrg bitrate to the project file? Possibly for the next release. For 1.4.6, I'm only accepting bug reports now, not new features.

Rockas

1st February 2006, 22:28

Thanks... I'll remember you about it :D

jlobee

2nd February 2006, 11:52

Using Scenaid 1.7.0.7 and DGMPGDec 1.4.6 RC1, I get the following error:

Procedure Name: ProcessAVS
Module Name: ProcessAssets

Error Number: 6
Error Description: Overflow
Error Source: ScenAid
Error Line: 90
Call Stack:

The latest DGMPGDec that works is 1.4.6 Beta3, anything after that (Beta 4, 5, 6, and RC1) give this error.

Any suggestions?

Guest

2nd February 2006, 14:51

Sorry I don't know anything about Scenaid. Maybe the D2V file format change messed it up. Please consult the Scenaid authors.

Tima

3rd February 2006, 21:42

What about http://forum.doom9.org/showthread.php?p=772413#post772413 ? :)

Guest

3rd February 2006, 22:01

What about http://forum.doom9.org/showthread.php?p=772413#post772413 ? :) Your frames are corrupted/incomplete. When you concatenate them, it creates incorrect MPEG2 syntax that triggers an exception. I'll have a look to see if I can recover more gracefully, but given that your files are corrupted, you should probably try to fix that at its source.

Tima

3rd February 2006, 22:12

Understood. Maybe DGIndex could indicate the detected corruption of the frames somehow?

Also:
Another 'bug' occurs when DGIndex runs at idle priority and my cpu is heavily loaded with another task at normal priority. If I strike F5 immediately after loading vob, DGIndex complains there's no PID's or something like that. If I wait for some time, it loads and plays good. Maybe DGIndex shouldn't interact with user before the vob is loaded properly..