DGMPGDec 1.4.6 Final [Archive]

Guest

10th October 2005, 15:47

Here is 1.4.6 Final.

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

1. Fixed a bug in indexing for some field structure streams.

2. The 'This I picture starts a new GOP' flag in the D2V file was not being
set correctly. This flag is not used by DGDecode, so the impact was only to
the diagnostics produced by Parse D2V.

3. The D2V file format version number was bumped to 12. (This should have
been done for version 1.4.5; better late than never.)

4. Fixed a problem in DGDecode that could cause a lockup when navigating
on the timeline with some unusual field structure streams.

5. Increased the maximum number of input files from 256 to 512.

6. Incorporated fix to DGVfapi (by 'tritical') that prevents a failure when
a large number of VFAPI-served files are opened at once.

7. Changed DGIndex/DGDecode so that when DGDecode sets the frame rate
in Avisynth, it uses the exact fractional representation for
fps_numerator/fps_denominator (changes by 'tritical').

This way, e.g., NTSC clips get the exact 24000/1001, 30000/1001, or
60000/1001 rate instead of 23.976, 29.970, or 59.94.

DGIndex was actually getting the framerate correct, but when it wrote the
d2v file, it would multiply the floating point value up by 1000 and then save
it. Then DGDecode would use that value for the numerator and 1000 for the
denominator. Now, when DGIndex gets the fps value from the lookup table it
also gets numerator/denominator values from a lookup table. Then in the d2v
file it writes, e.g.:

Frame_Rate=29970 (30000/1001)

with numerator and denominator in parentheses. DGDecode then uses those
values when setting the frame rate in Avisynth.

This change bumps the D2V file format version number to 13.

8. The message box that pops up for transport streams when no data is
found has been clarified to direct the user to use the Stream menu to set
the PIDs.

9. Fixed a hang when the CLI -HIDE option is used and the input file cannot
be opened.

10. The video overlay is now not claimed when the -HIDE or -MINIMIZE CLI
options are used.

11. File version properties were added for DGIndex, DGDecode, and DGVfapi.
If you right click on the EXE, DLL, or VFP files and select properties, you can
now obtain file version information.

12. The DGIndex Information dialog now shows an overall average bitrate for
the entire previewed video in addition to the windowed value. The windowed
value now reports every 32 frames instead of every 64 frames.

13. 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'.

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

15. Fixed the truncation of the last few bytes of demuxed M2V files.

16. Fixed a problem that limited the number of files that could be opened at
once from the File Open Dialog (drag-and-drop to the DGIndex window was
OK). It should now be possible to open up to 512 files at once via the open
dialog.

richardlfyang

11th October 2005, 02:59

Tks! I'll try it! :)

AllTimeSToneD

13th October 2005, 13:02

It seems like i discovered accidently a bug (or a limitation)?

If i try to open 314 transport stream files each 100mb in size DGIndex gives me a error window and crashed once clicked OK or Cancel.

Something about "0x00418e82 ..... Memory 0x00000000"

I could post a screenshot of the error window but that probably wouldn't help much as my WinXP is on german. I've tried to limit the number of files to 256 files and it worked. So it looks to me like a limitation of max 256 files.

Is that one fix-able? I would like to be able to open all the files at once.

Btw the bug/limitation exists on both (using drag and drop and open file/add).

Guest

13th October 2005, 13:41

MAX_FILE_NUMBER is currently 256, as you suggest. I will bump it to 512 in the next beta. Will that be enough? What is your application scenario that causes such a situation?

AllTimeSToneD

13th October 2005, 17:16

Will that be enough?
Yes probably yes :thanks:

What is your application scenario that causes such a situation?

Capping a European HD stream of RotK while the streaming software splits the incoming stream in 100MB chunks. That would result as you can already guess in a few hundred ts files. :D

pbkg

14th October 2005, 12:38

Is there any difference between the processing of PAL and NTSC in the program? If not then I guess you could ignore this, but otherwise, there may be a problem...

Why? Looking through the source code of previous versions, it seems that unless framerate == 25 fps, then the preview gives the video type as NTSC when it should be PAL. But, the two Australian government owned broadcasters both have decided that their "High Definition" (snigger, snigger), service should be 50 fps, rather than the standard 25 fps (two of the commercial stations run their HD at 1080i PAL @ 25 fps as far as I can tell, and the other is all over the place like a dogs breakfast for me, with their "HD" service PID currently the same as the SD PID, ie the same video, but different audio....). As far as I can tell, this is part of the digital standard (50fps via PAL @ 720x576), but it could catch people out. I would upload a copy of a file, but I would be here all night on my connection....

Guest

14th October 2005, 13:06

That is only a display issue for the info dialog. Thanks for pointing it out. Maybe it's worth displaying 50fps as "PAL".

Tima

14th October 2005, 21:33

As far as I can see, there's no explanation in help files about what 'Video %xx' in 'Video Type' means.. 'Bug'? :)

foxyshadis

15th October 2005, 09:06

As far as I can see, there's no explanation in help files about what 'Video %xx' in 'Video Type' means.. 'Bug'? :)
http://neuron2.net/dgmpgdec/DGIndexManual.html#FieldOp

This is the same help file that comes with DGIndex. (Although you sort of have to know what you're looking for to look for this chapter.)

Guest

15th October 2005, 13:19

Actually, Tima found a document bug, because I still had "FILM" vs. "NTSC", although the display now shows "Film" vs. "Video". Here are the corrected sections:

http://neuron2.net/dgmpgdec/DGIndexManual.html#FieldOp
http://neuron2.net/dgmpgdec/DGIndexManual.html#video

calinb

18th October 2005, 22:36

I’m having trouble with HDTV .mpg files created by my Dvico Fusion5 card. Dgdecode doesn't find/demux the AC3 audio track. Dgdecode handles Fusion5 .ts files okay but, for some strange reason, my Fusion5 card creates corrupted .ts files from one QAM channel that I like to watch (PBS) so I must record to .mpg files on this channel. I found that the Windows mpeg demultiplexer DSF works great (audio + video), but the Windows splitter DSF and MPC internal parser/splitter seek very poorly. The Elecard/Moonlight DSF doesn’t work at all! The Fusion playback filters work fine, of course.

Any chance I could interest you in a sample file, Donald? Thanks much, if you have the time to take a look.

Guest

18th October 2005, 22:40

Yes, sure. Upload it to my FTP and notify me of the filename. You didn't say what problem you have with DGIndex!

I am involved in another thread about this card using .mpg, in which DGIndex can't get the audio right, but gets the video fine.

Is yours the Australian or ATSC format card?

calinb

18th October 2005, 22:46

doh! Sorry Donald, I just realized my ommision and edited my posting, but you replied before I could get it finished. Yeah, it's the audio. I'm posting to the Dvico Q/A site about the corrupted .ts files on this one cable 256 QAM channel too, but the card should create either .mpg or .ts (.tp) output files. Both output options work on all channels but this one, which requires mpg output. I have the ATSC card. Point me to the other thread and maybe I can help there too. They could try transport stream output, as an alternative.

AMED

21st October 2005, 07:27

I have a small request with regarding saving a project file.

Could the default behaviour be changed to check the name of the parent folder and if it isn't named VIDEO_TS then use that name of the parent folder for the project name?

eg.
if parent folder name is not VIDEO_TS
use parent folder name for naming of project when saving
else parent folder name is VIDEO_TS or files are from multiple locations
use current naming convention
end

Guest

21st October 2005, 14:07

Guest

21st October 2005, 14:09

Could the default behaviour be changed to check the name of the parent folder and if it isn't named VIDEO_TS then use that name of the parent folder for the project name? Sorry, but no. Different people have different conventions for where they save project files, and if I try to implement them all, they'd conflict. Better to keep it simple and basic.

calinb

21st October 2005, 19:15

http://forum.doom9.org/showthread.php?t=101507

It appears to be a very similar, if not identical case.

I don't see a file uploaded from you yet.
Sorry about the delay in uploading the samples, Donald. I uploaded calinb_cap.zip to the site. I also sent the zip file to Dvico (Fusion developer). It contains an .mpg, .tp, and .m2t file.

Fusion crashes after many seconds or a few minutes with .tp capture only. The .tp files are usually corrupted. Dvico is working that issue.

The .tp and .m2t files may or may not be useful to you in getting to the bottom of this. The .m2t file was captured from the firewire port of my cable STB on the same channel. with my Apple Mac mini. Again, may or may not be related to gumballguy's and my problem. If you can make DGIndex work with the .mpg file, we could abandon other cumbersome workarounds!

Donald, please check my PM for a Dvico contact address. Again, may or may not be useful.
:thanks:

mg262

6th November 2005, 00:20

In the MPEG2Source documentation with this release, there is the following line:

0: Use value specified by DGIndex (iDCTs 6 and 7 unavailable in DGIndex)

I have no problem selecting those modes in DGIndex, and they are documented in its manual. Is it that this line has not been updated yet (which would be entirely understandable given the rate at which you update the software), or -- probably more likely -- am I misreading it completely? If the latter, I would be grateful for the correct reading...

This is a very minor point... I hope you don't mind me bringing it up.

Thanks in advance,
M.

Guest

6th November 2005, 02:49

It's a document bug. Read it this way:

0: Use value specified by DGIndex

Thank you for pointing it out. It will be repaired in the next beta.

Tima

7th November 2005, 22:13

Donald, how much is the write buffer of DGIngex for now? Could you make it configurable to o just bigger (to make user able to avoid fragmentation of files that are written during demux, when f.e. used vobs are on the same drive)?

Guest

7th November 2005, 22:32

Right now I don't call setvbuf() at all, so I just get whatever the default is for fopen(). How big a buffer are you thinking of and do you have a good reason to believe it will actually reduce fragmentation?

What does this mean: "f.e. used vobs"?

Tima

8th November 2005, 00:20

Ehm.. bad english, sorry :)

f.e. = e.g.

I don't know about the exact influence of buffer on fragmentation, but I'd like to choose the the size of blocks I'll feed my HDD with. I believe it'll at least improve the performance.. ;)

Two hours ago I had a situation when my two demuхed 384MB and 192MB files had about 3000 fragments each.. I think that buffer should be _at least_ 512KB.. (or configurable in range 512KB - 16MB or maybe even more).

Also _maybe_ it's good to specify read and write buffers separately..

Guest

8th November 2005, 00:30

I'll experiment with it. What tool are you using to assess fragmentation of a given file?

Tima

8th November 2005, 00:39

I use Raxco PerfectDisk 7.0, but it can de done also with Windows built-in defrag utility.

Guest

20th November 2005, 17:37

* Fixed a problem in DGDecode that could cause a lockup when navigating
on the timeline with some unusual field structure streams.

* Increased the maximum number of input files from 256 to 512.

* Incorporated fix to DGVfapi (by 'tritical') that prevents a failure when
a large number of VFAPI-served files are opened at once.

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

SeeMoreDigital

11th December 2005, 18:47

Hi Donald,

A few days ago I was given a 75MB 1920x1080/88 MPEG-2 .TS sample with DTS audio to try with an high-def network capable DVD player I'm currently beta testing.

While the sample provided appears to play perfectly in the affore mentioned player. When I run the sample thru' DGIndex 1.4.6 beta 2, only the video stream is de-muxed.

I tried manually adusting the PID's (there are only two) but withut success!

Would this e a sample you are interested in? If so I will upload it to your server!

Cheers

Guest

12th December 2005, 05:44

Sure, go ahead. Upload it and then PM me with the file name. Thank you.

Tima

22nd December 2005, 22:10

Donald, how can I tell dgdecode to return all frames, even corrupted?

I have an mpeg-2 file (tv-capture). I make d2v file from it (and demux the audio in mpa file, and getting wav from it) and then put it into Avisynth script:
mpeg2source("E:\!TV Rec\МиМ 5 [NeXT]\МиМ 5 [NeXT].d2v", idct=0).AssumeFrameBased()The last frame's number is 85737.

Then i put that mpeg-2 file in script via DirectShowSource():
DirectShowSource("E:\!TV Rec\МиМ 5.raw.mpg").AssumeFrameBased()The last frame's number is 85771 in this case. In particular, it shows extra frame #0, that is corrupted.

While looking the movie in media player (MPC) the movie plays synchronized.
When i take video from dgdecode, and audio from demuxed file, it's not synchronized in the end - video plays earlier.

My goal is to get synchronized video and audio using only DGMPGDec and avisynth.

Guest

23rd December 2005, 04:44

The frame count from DGIndex should be accurate. When indexing, the frames are not decoded, so frames will only be lost if key sequence codes are corrupted.

Regarding the synchronization, did you get an offset in the demuxed audio's filename and if so did you correct for that? Is the desync a constant offset or does it grow bigger as the movie progresses?

I regret that I can't look at your material until I return from vacation.

Tima

23rd December 2005, 11:02

Regarding the synchronization, did you get an offset in the demuxed audio's filename and if so did you correct for that?
Yes, the delay was -131ms, and I corrected it when converting to wav. But in the end there's a misalignment about 1-2 seconds, not +-0.131 :)

Is the desync a constant offset or does it grow bigger as the movie progresses?Can't determine exactly, but it appears that audio shifts somewhere in the end of movie..

AMED

24th December 2005, 12:09

I think i've found a bug/quirk in DGMPGDec 1.4.6 beta 2.

Things you need to reproduce
DGMPGDec 1.4.6 beta 2
My computer window

load a movie into DGMPGDec and save the .d2v project, while the slider is moving from left to right and while DGMPGDec is not minimised, right click any folder in the my computer window, and choose properties, click cancel on the properties box, then right click on a blank area in the my computer window, have a look at DGMPGDec and you'll see that is has paused the processing the movie, until you exit that last right click menu.

Guest

25th December 2005, 06:37

Can't determine exactly, but it appears that audio shifts somewhere in the end of movie.. DGindex determines the delay only once at the start of the project range. You'll have to fix it manually by dividing the project into two pieces.

Guest

25th December 2005, 06:39

AMED

25th December 2005, 09:35

That sounds like a windows quirk, but I'll have a look at it when I return from vacation. Thank you for pointing it out.I had a feeling it was that, have a great vacation and a merry christmas.

Cyberia

31st December 2005, 08:45

CEC

8th January 2006, 12:55

I found this line in the "DGDecodeManual.html":

"All of the available options are IEEE-1180 compliant, except for SSE/MMX (Skal)."

If "SSE/MMX (Skal)" is not IEEE-1180 compliant, then why it is the default option in DGindex???
How much quality do I lose when I use this algorithm???

Thanks!

Guest

8th January 2006, 17:04

If "SSE/MMX (Skal)" is not IEEE-1180 compliant, then why it is the default option in DGindex? Because that is what I use and I am the author; as Britney might say: "It's my prerogative". If you prefer a different one, select it and it will be saved in the INI file.

How much quality do I lose when I use this algorithm? It's completely imperceptible, as you can see by using this script:

skal=MPEG2Source("E:\tmp\manono\LloydSample.d2v",idct=6)
ieee=MPEG2Source("E:\tmp\manono\LloydSample.d2v",idct=5)
subtract(skal,ieee)

Guest

8th January 2006, 17:36

A few days ago I was given a 75MB 1920x1080/88 MPEG-2 .TS sample with DTS audio to try with an high-def network capable DVD player I'm currently beta testing.

While the sample provided appears to play perfectly in the affore mentioned player. When I run the sample thru' DGIndex 1.4.6 beta 2, only the video stream is de-muxed. We have two problems:

1. DGIndex does not support demuxing DTS from a transport stream. I'm not aware of any spec that defines syntax for that in the transport stream. Are you?

2. The stream sends a PMT specifying the audio as AC3. But there is never an AC3 sync word, so demuxing fails.

Unless you can point me to a spec that defines this situation, i.e., DTS audio in DVB/ATSC transport, I cannot help with this. Can you get some clarification from the guys who gave you the stream?

Guest

8th January 2006, 18:53

Here is version 1.4.6b3:

* Changed DGIndex/DGDecode so that when DGDecode sets the frame rate
in Avisynth, it uses the exact fractional representation for
fps_numerator/fps_denominator (changes by 'tritical').

This way, e.g., NTSC clips get the exact 24000/1001, 30000/1001, or
60000/1001 rate instead of 23.976, 29.970, or 59.94.

DGIndex was actually getting the framerate correct, but when it wrote the
d2v file, it would multiply the floating point value up by 1000 and then save
it. Then DGDecode would use that value for the numerator and 1000 for the
denominator. Now, when DGIndex gets the fps value from the lookup table it
also gets numerator/denominator values from a lookup table. Then in the d2v
file it writes, e.g.:

Frame_Rate=29970 (30000,1001)

with numerator and denominator in parentheses. DGDecode then uses those
values when setting the frame rate in Avisynth.

This change bumps the D2V file format version number to 13.

* The message box that pops up for transport streams when no data is
found has been clarified to direct the user to use the Stream menu to set
the PIDs.

* Fixed a hang when the CLI -HIDE option is used and the input file cannot
be opened.

* The video overlay is now not claimed when the -HIDE or -MINIMIZE CLI
options are used.

* File version properties were added for DGIndex, DGDecode, and DGVfapi.
If you right click on the EXE, DLL, or VFP files and select properties, you can
now obtain file version information.

* The DGIndex Information dialog now shows an overall average bitrate for
the entire previewed video in addition to the windowed value. The windowed
value now reports every 32 frames instead of every 64 frames.

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

(I am still working on the fix for the loss of 4 bytes at the end of a demuxed video file.)

Rockas

9th January 2006, 14:02

(I am still working on the fix for the loss of 4 bytes at the end of a demuxed video file.)
Is this happening on every previous releases?

Guest

9th January 2006, 14:17

Is this happening on every previous releases? Yes. But please note that not all streams are affected, and even for ones that are, it is often harmless.

Trahald

9th January 2006, 16:41

usually last 4 bytes is the sequence end code. not critical for most applications.

lexor

9th January 2006, 20:07

hey neuron, any word on that problem of only being able to add 64 .ts files I had in beta2? I'm at work can't check out the new beta right now :(

AllTimeSToneD

9th January 2006, 20:08

usually last 4 bytes is the sequence end code. not critical for most applications.
Yes, thats uselly the case with Vob's but if you have a .ts as input from an atsc station its uselly the last frame which in most cases will then be a missing/undecodable B-Frame/P-Frame. :(

...problem of only being able to add 64 .ts files...
I had no problem loading 256 .ts file in beta2. Beta3 now supports up to 512 (not tested myself yet though).

Are you sure you havn't accidently loaded diffrent resolution or PID'd .ts files?

lexor

9th January 2006, 22:17

here is the link to my thread (which started as help call for gray line issue):
http://forum.doom9.org/showthread.php?t=103850

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.

AllTimeSToneD

10th January 2006, 03:55

Try drag and dropping them all at once in the DGindex window. I uselly just drag and drop them bcuz im to lazy to use the "File-Open" gui. :p

lexor

10th January 2006, 04:25

Try drag and dropping them all at once in the DGindex window. I uselly just drag and drop them bcuz im to lazy to use the "File-Open" gui. :p
holy flipping... drag&drop all at once into the main window did add them all to the list at once! but still I would expect normal add procedure to work as well.

Rockas

11th January 2006, 14:08

Yes. But please note that not all streams are affected, and even for ones that are, it is often harmless.
usually last 4 bytes is the sequence end code. not critical for most applications.
Thanks for the information.
Yes, thats uselly the case with Vob's but if you have a .ts as input from an atsc station its uselly the last frame which in most cases will then be a missing/undecodable B-Frame/P-Frame.
Can this, somehow, affect MPEG files too?

Guest

11th January 2006, 15:05

Can this, somehow, affect MPEG files too? All video demuxing is affected.

Guest

12th January 2006, 06:00

Beta 4 fixes a problem in setting of the frame rate in Avisynth by DGDecode (merging error when absorbing tritical's fix).

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

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..

Guest

3rd February 2006, 22:14

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

4th February 2006, 00:07

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

Fishman0919

4th February 2006, 15:44

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

4th February 2006, 15:44

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

video_magic

5th February 2006, 22:24

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

6th February 2006, 00:06

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

6th February 2006, 02:07

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

6th February 2006, 14:24

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

6th February 2006, 14:35

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

6th February 2006, 17:55

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

6th February 2006, 18:44

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

12th February 2006, 13:05

@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

12th February 2006, 18:28

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

12th February 2006, 21:08

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

12th February 2006, 21:28

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

AllTimeSToneD

13th February 2006, 11:22

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

16th February 2006, 01:19

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

16th February 2006, 01:56

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

16th February 2006, 03:13

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

Inventive Software

16th February 2006, 12:43

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

16th February 2006, 15:25

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

Inventive Software

16th February 2006, 21:45

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

16th February 2006, 22:02

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

16th February 2006, 22:03

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

21st February 2006, 03:08

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?