DGMPGDec 1.4.0 Final!

[Guest]

This version provides the following new features relative to version 1.3.0:

1. Standard call wrappers for dgdecode.dll access functions for use by Visual Basic, etc. E.g.: getRGBFrame_SC().

2. Fix for slice error recovery bug that caused some (rare) picture decoding errors.

3. Program streams with video stream IDs other than 0xE0 are now supported.

4. The preview info box of DGIndex now shows the audio type of all the audio tracks. This is populated when doing a Preview (F5).

5. Fixed decoding errors due to improper recovery from corruption of transport streams.

6. Fixed the pitch=width assumption, thereby allowing proper operation under newer versions of Avisynth that modify the alignment rules (revisions kindly contributed by 'tritical').

7. Fixed the emulated header problem by properly parsing the pack or transport layer when getting the initial sequence header.

8. Corrected an error in the D2V format document (bits 6 and 7 of the per-frame flags byte was erroneously reversed).

9. The process priority can now be changed in DGIndex during a Save Project operation.

10. A bug in the PAT/PMT parser was repaired that could cause DGIndex to erroneously think that a PAT/PMT is not present.

11. Added the .vro and .mpv file types to the DGIndex open dialog.

12. Fixed the Reference IDCT (type 4). Changes by jackei derived from his latest DVD2AVI version.

13. MPEG1 is now supported.

14. DGVfapi now supports multiple instantiation, i.e., multiple "fake" AVIs served at the same time. It can also open AVS scripts as well as D2V files. Thanks to "tritical" for these enhancements.

15. DGParse and DGFix have been integrated into a new menu pulldown of DGIndex called "Tools".

16. The integrated DGParse info now shows the GOP structure, and properly shows the effect of the field operations.

17. Fixed a bug such that during preview the info dialog did not show the audio track information for transport streams and PVA streams.

18. The Detect PIDs dialog now has a "Done" button.

19. Fixed a bug in parsing of transport streams.

20. Removed YV12toYUY2() and YV12toRGB24() because they duplicate Avisynth native filters.

21. Replaced the buggy LumaFilter() with a new, optimized LumaYV12() filter by ARDA.

22. Added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps.

23. Added a new CLI option, -SD, that allows setting of a custom delimiter character.

24. "Process WAV" functionality was removed. SRC/normalization can no longer be applied to LPCM.

25. LPCM support was improved: 1) 48K/96K, 16bit/24/bit, and mono/stereo are now supported. 2) The format info is included in the filename and the info dialog. 3) Demux Track and Demux All Tracks now work for LPCM (no special handling).

26. The D2V format version is now checked when loading a D2V file.

27. IDCT support was fixed: 1) The IDCT algorithm specified in the INI or D2V file is now not automatically promoted (e.g., previously if you had IDCT=1 in the INI file and then started DGIndex, you'd end up with IDCT=3). However, the IDCT is scaled down if it is not supported by the processor. 2) A bug in DGDecode was fixed that caused SSEMMX to be used when SSE2MMX was requested. 3) The IDCT algorithm is now consistently numbered between the CLI, D2V, etc.

28. Added audio processing to the Quick Start guide.

29. Fixed a problem that caused failure of AC3 audio demuxing from a
transport stream if the audio stream was not contained in the PAT/PMT
tables.

30. Fixed a problem in DGVfapi that caused conversion of AVS scripts
to fail when they delivered RGB32. [fix by 'tritical']

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

[Boulder]

Did you notice the problem with the latest Avisynth beta?

http://forum.doom9.org/showthread.php?s=&threadid=85826&perpage=20&pagenumber=5

[tritical]

I made a quick fix for this... it took a few more changes then I thought it would because of the way field based PP is done. The changes were in store.cpp where the postprocess() call is made, in postprocess I added a new parameter called iPP so that the fast_copy code would work in field based mode when the pitches weren't the same, and then in avisynthapi.cpp I changed the postprocess() calls in blindpp. Also, there seemed to be a bug in YV12 BlindPP with iPP=true, the src pitch needed to be doubled and wasn't being. I tested it with the new avisynth and it seemed to work fine... the changed files are in the zip below, originally from v1.3 source.

EDIT: needed another small change to the main postprocess routine for field based pp to work when pitch and width weren't equal.

[Guest]

Nope, I didn't notice that. I'll incorporate the fixes and release a new beta. Thank you Boulder for pointing it out, and tritical for the patches.

[tritical]

Thought about it some more and my patch is still busted for field based PP when pitch doesn't match width. The copying will work, and it will process all the pixels, but the QP pointer will be incorrect for the second half of each line due to the extra pixels in the middle. Possible fixes I can think of: change a lot of stuff in the post-processing code, forget changing the pping code and just add in an extra copy step where needed so that field based post-processing is always done on a buffer with pitch==width, or forget about changing that other stuff and simply change the env->NewVideoFrame calls to return 16/8 byte aligned frames as before. There is probably another, better option that I am not thinking of, hopefully you or someone else can :).

[tritical]

Was making another fix today just using copies where field based post-processing is used, and realized this problem runs deeper then just post-processing. Specifically, the copy functions at the bottom of vfapidec.cpp are broken if width != pitch and you pass the larger one first so it only shows up if rff's are present. Those can be fixed easily, but then some of the colorspace conversions seem to depend on width == pitch as well (420 to 422 and 422 to 444). That can also be fixed without too much hassle, but who knows if there are still other places that need changing. It seems to be quite a mess when width != pitch :D.

[Guest]

I want to know why the author made this change to Avisynth and why it is seen as so important that he is happy to break existing applications, and important ones at that. To be quite honest, I can't say I'm particularly motivated to fix all this, especially when I had no say in the decision. Maybe the author will clean up the mess?

How about some polymorphism, so that existing applications can work the old way?

And just in case anyone wants to rag on me, I inherited all this code assuming pitch = width; I didn't write a single line of it. All the precursors of DGDecode are going to be broken too.

[tritical]

Don't know that, though I suspect the change was mainly for sse2/sse3 optimization purposes. Its only a beta so I'm sure there is some room for discussion on the change.

env->NewVideoFrame() already allows one to call with a negative align argument that will force a specific alignment even if it is less then the default. That could be used to get the same alignment as before, but the filters that request frames from a clip (blindpp, etc..) could still get 32byte aligned frames as input. Though technically it is possible they could get that type of alignment now if another filter up the chain calls env->NewVideoFrame() with an align value other then the default. However, fixing those few filters for when pitch!=width would definitely be much easier then the core stuff.

I'm sure no one is blaming you for it. I forgot that this would also break previous mpeg2dec3 versions as well.

[Guest]

OK, I'll chill. It's only been a day since it came to light, and, as you say, it's a beta.

And oh, thanks for your analyses! Saves me quite a bit of thinking, which gets harder as I get older, and, anyway, I'm obsessed with the metaphysics of QM these days, which limits my available cerebral bandwidth, sad to say. Some argue it was quite limited to start with, but I won't dignify that.

[Nic]

"I'm obsessed with the metaphysics of QM"
So, your too involved with unimportant things like a formula for it god exists or not when you could be adding MPEG-1 support to your DVD2AVI suite? ;)

If you need to me look at any particular pitch != width problems let me know...

Cheers,
-Nic

[Gabrielgoc]

neuron,

It is possible to add the sample rate to each audio stream, in the information window?

thx

Gabriel

[CyberGuy]

I’m not sure if this is a problem with MPlayer 1.0pre7, AviSynth 2.5.6b3 or the DGDECODE alignment issue, but I can play the following script fine in Windows Media Player, but it is garbage when played in MPlayer 1.0pre7. Is there something I can add to the script to make it work? I’m using MPlayer to convert the file to raw I420.

LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0)
Return(Source)

[Cyberia]

DGDecode can output I420, just set i420=True.LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0, i420=TRUE)
Return(Source)

[Guest]

First try reverting to Avisynth 2.5.5. If it still plays bad in MPlayer 1.0pre7, then it is likely a problem in MPlayer.

[CyberGuy]

Originally posted by neuron2
First try reverting to Avisynth 2.5.5. If it still plays bad in MPlayer 1.0pre7, then it is likely a problem in MPlayer.

It plays fine with AviSynth 2.5.5 and MPlayer 1.0pre7.

[Guest]

Originally posted by Gabrielgoc
It is possible to add the sample rate to each audio stream, in the information window?
I'll have a look. Thanks for the suggestion.

[Guest]

Originally posted by CyberGuy
It plays fine with AviSynth 2.5.5 and MPlayer 1.0pre7. Then you'll have to wait for a resolution to the alignment issue before you can use DGDecode under the Avisynth beta. It's only been 2 days, so please be patient.

[CyberGuy]

Originally posted by Cyberia
DGDecode can output I420, just set i420=True.LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0, i420=TRUE)
Return(Source)

Same problem.

[CyberGuy]

Originally posted by neuron2
Then you'll have to wait for a resolution to the alignment issue before you can use DGDecode under the Avisynth beta. It's only been 2 days, so please be patient.
Thank you. Return(Source).Info returns a Video Pitch of 720 with AviSynth 2.5.5 and a Video Pitch of 736 with AviSynth 2.5.6.b3. I just wanted confirmation that it was the same problem, since it played fine in Windows Media Player. I'll be patient... :)

[Guest]

env->NewVideoFrame() already allows one to call with a negative align argument that will force a specific alignment even if it is less then the default As a quick test, here is a hack that does this (mpeg2source() only). Someone please test it under 2.5.6b3.

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

I just did this:

PVideoFrame frame = env->NewVideoFrame(vi, -16);

EDIT: It appears I need -8 instead of -16. I'll put up another version tonight.

[CyberGuy]

Originally posted by neuron2
As a quick test, here is a hack that does this (mpeg2source() only). Someone please test it under 2.5.6b3.

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

I just did this:

PVideoFrame frame = env->NewVideoFrame(vi, -16);

EDIT: It appears I need -8 instead of -16. I'll put up another version tonight.
It still returns a Video Pitch of 736 bytes with AviSynth 2.5.6b3 when it should be 720 bytes.

LoadPlugin("DGDECODEX.DLL")
Source = Mpeg2Source("Video.D2V", iDCT=4, CPU=0)
Return(Source)

[Cyberia]

FYI: This didn't fix it.

[Guest]

Hellooooo?! Didn't you guys read my EDIT?

Download using the same link to get the one I just put up. It uses -8. Please test that one. Thank you!

[Cyberia]

Fixed

[CyberGuy]

Originally posted by neuron2
Hellooooo?! Didn't you guys read my EDIT?

Download using the same link to get the one I just put up. It uses -8. Please test that one. Thank you!
It works! Thanks for the quick fix. Now I notice that LanczosResize/Lanczos4Resize breaks it again, but I guess that's a post for another thread.

[Guest]

@CyberGuy

Please post the script that breaks. Thank you.

[CyberGuy]

Originally posted by neuron2
@CyberGuy

Please post the script that breaks. Thank you.
LoadPlugin("DGDECODE.DLL")
Source = Mpeg2Source("VIDEO.D2V", iDCT=4, CPU=0)
Source = Trim(Source, 70, 3145)
Source = Crop(Source, 0, 76, -0, -76)
Source = LanczosResize(Source, 720, 304, Taps=8)
Return(Source)

If I comment out "Source = LanczosResize(Source, 720, 304, Taps=8)", then it plays correctly in MPlayer. The LancosResize changes the Video Pitch from 720 to 736. The original source is 720x576. If resizing to 704x304, then the video pitch is 704, so this appears to happen when width is not changed.

[cw_uk]

Is it possible thats theres a problem with DGIndex not flushing the last frames from a previously loaded file, Whilst backing up Agent Cody Banks i noticed on the finished file that the first frame or two was from the menu which i had loaded just to check it out before hand. the finished file had audio/video sync issues which might have been down to this. im reencoding the file now to confirm.

[Guest]

Originally posted by CyberGuy
The LancosResize changes the Video Pitch from 720 to 736. You need to report this in the Avisynth beta thread. Apparently there are several filters that need to be revised to work with the new alignment.

@cw_uk

It's highly doubtful. Maybe you forgot to delete the VOB from the VOB list.

[CyberGuy]

Originally posted by neuron2
You need to report this in the Avisynth beta thread. Apparently there are several filters that need to be revised to work with the new alignment.
It's not a problem after all, I had read in one of the forum posts mod 16, but it's actually mod 32, so AviSynth 2.5.6 is working correctly.

See: http://forum.doom9.org/showthread.php?s=&threadid=90527&perpage=20&pagenumber=2

[Guest]

Here is beta 4. This version corrects a decoding error caused by improper recovery from an MPEG2 syntax error (caused by corruption of a transport stream). The issue is described in this thread:

http://forum.doom9.org/showthread.php?s=&threadid=94382

Here is the fixed version:

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

[guada 2]

Gently but surely. :)
I appreciate your step of work.

Thank you very much Neuron2 and long life with DGindex and the devellopor which contribute to waitings of the listeners of planet.

Goodbye ;)

[cw_uk]

Originally posted by neuron2
@cw_uk

It's highly doubtful. Maybe you forgot to delete the VOB from the VOB list.

Reripped it and this time all is fine no more stray few frames knocking everything out of sync, The only thing that i did diffrently though was not check the menu (Vob 0) this time. I thought the same as you to begin with but if i had forgot to remove the entire menu vob from the list i would have the entire menu appended to the beginning of the movie.

[Guest]

Originally posted by cw_uk
The only thing that i did diffrently though was not check the menu (Vob 0) this time. I don't know what you are talking about. "Check the menu"? That doesn't sound like a DGIndex operation.

[cw_uk]

Originally posted by cw_uk
Is it possible thats theres a problem with DGIndex not flushing the last frames from a previously loaded file, Whilst backing up Agent Cody Banks i noticed on the finished file that the first frame or two was from the menu which i had loaded just to check it out before hand. the finished file had audio/video sync issues which might have been down to this. im reencoding the file now to confirm.
Originally posted by neuron2
You need to report this in the Avisynth beta thread. Apparently there are several filters that need to be revised to work with the new alignment.

@cw_uk

It's highly doubtful. Maybe you forgot to delete the VOB from the VOB list.
Originally posted by cw_uk
Reripped it and this time all is fine no more stray few frames knocking everything out of sync, The only thing that i did diffrently though was not check the menu (Vob 0) this time. I thought the same as you to begin with but if i had forgot to remove the entire menu vob from the list i would have the entire menu appended to the beginning of the movie.

VTS_01_0 <-- menu VOB

apologies for my lack of words and effort but im off to bed and couldnt be bothered to type out a explaination.

[sh0dan]

Originally posted by neuron2
EDIT: It appears I need -8 instead of -16. I'll put up another version tonight.

DON'T DO THAT, unless you realign frames afterwards (by a bitblit). Planar images returned by your filter MUST have mod 16 on the Y-plane pitch. This is not guaranteed by using "-8". You risk breaking a bunch of filters that process 16 bytes/loop. Snippet from the documentation (from WorkingWithPlanarImages (http://www.avisynth.org/WorkingWithPlanarImages)):


Some (producing) filters may want to set a forced pitch. Per default, when you request a videoframe with a specific modX pitch it might be overruled by AviSynth.(You do this by using env->NewVideoFrame(VideoInfo, [alignment])) In this (very rare case), you can use a negative alignment. This will make the alignment forced.

If you force an alignment you MUST also apply the AlignPlanar(!PClip) filter after your own, otherwise your filter will not produce valid output. See source.cpp for examples.

[Guest]

The -8 sets up 8-alignment on the chroma and 16-alignment on the luma under the new beta.

[Guest]

Here is 1.3.1 beta 5. This beta adds a fully correct fix for the pitch=width assumption, thereby allowing correct operation under the current Avisynth 2.5.6 beta, as well as the stable 2.5.5 version. Our friend tritical kindly developed and contributed this code revision. Thank you, tritical!

tritical also removed the limitation of a maximum of 1,000,000 frames.

I added a fix for the emulated header problem by properly parsing the pack layer or transport layer if needed when getting the initial sequence header.

I also corrected an error in the D2V file format document.

Please beat up on this hard because the changes are extensive. Thank you.

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

[iNFO-DVD]

Just tried your beta5, remember that 'green line' (earlier post) I was getting down the left side on certain clips..... well it's now gone.

Well done.

[Guest]

@iNFO-DVD

Thank you for your test result. That is good to know.

[ccfilms]

I must've missed this earlier today - downloading now. :)

[jarthel]

if i'm using an avisynth version prior to 2.5.6beta3., should I stick with older versions of dgmpgdec?

[AlexeyS]

2 neuron2

Is this possible to DGMPGDec automatically made deinterlace (all types of pulldown removal)?

I have some "problem" movies, when movie has interlaced NTSC and FILM parts. Avisynth can't make ideal deinterlace with such movie. :(

[Guest]

Originally posted by jarthel
if i'm using an avisynth version prior to 2.5.6beta3., should I stick with older versions of dgmpgdec? No need for that. The new version should work fine with Avisynth 2.5.5 and below. If not, please let me know. :)

[Guest]

Originally posted by AlexeyS
Is this possible to DGMPGDec automatically made deinterlace (all types of pulldown removal)?

I have some "problem" movies, when movie has interlaced NTSC and FILM parts. Avisynth can't make ideal deinterlace with such movie. I don't understand what you are asking for. You say you have a hybrid with mixed 24 and 30fps sections? Define how you'd like that processed and I'll tell you if it is possible.

DGDecode serves an AVI, which can have only one frame rate. You can use Force Film to remove the pulldown, but you'll get jerkiness in the 30fps sections. Decomb (and others) are designed to give you more options for these kinds of clips.

If you have a magic bullet to share with us, please speak up.

[Leak]

Originally posted by neuron2
If you have a magic bullet to share with us, please speak up.

You know, somehow the term "sharing a magic bullet" sounds quite painful and deadly to me... :D

*runs for cover*

[ccfilms]

http://www.redgiantsoftware.com/magbulsuit.html

;) Pun intended. lol.



EDIT:

For my own personal, I'm looking for a filter that does pulldown removal professionally the same way Adobe Premiere, Final Cut Pro, Sony Vegas, and Adobe After Effects and Avid Xpress Pro do it. So that I can take footage shot on, say, an XL2 or DVX100A that uses either 2:3 (24p) or 2:3:3:2 (24pa) pulldown and remove it really quickly, just like those apps do. They don't seem to need to process the DV footage (at least it doesn't seem like it) and the footage is just as crisp as a pure progressive frame and no resolution loss. And do it quickly. Actually, they do it in real time. And when you import footage into them, it says "DV (removing 2:3:3:2 pulldown)". I wonder if anyone will be able to come up with a filter that does just that to DV footage that is 24p or 24pa since it always follows one of those two specs.

But that might be a little bit too much. I think there's gotta be a way since those apps all know how to read that type of DV footage.

[AlexeyS]

Originally posted by neuron2
[B]I don't understand what you are asking for. You say you have a hybrid with mixed 24 and 30fps sections? Define how you'd like that processed and I'll tell you if it is possible.
I'm asking about automatic deinterlace. For example, user open MPEG2 file in DGMPGDec and DGMPGDec automatically makes best deinterlace (pulldown removal) or automatically makes sample of AVS script, such as you recommended for my Matrxi movie:
MPEG2Source("d:\Matrix\matrixhd.d2v")
telecide(order=1,post=0)

I think it will be greatest help for 95% of DGMPGDec users and especially bewbies.

DGDecode serves an AVI, which can have only one frame rate. You can use Force Film to remove the pulldown, but you'll get jerkiness in the 30fps sections. Decomb (and others) are designed to give you more options for these kinds of clips.
I've I've asked already on our local forum and heard same answer. :(

[Cyberia]

Deinterlacing is not the purpose of DGMPGDec. The newbiew can learn about deinterlacing plugins, and then they won't be newbies.

[AlexeyS]

Originally posted by Cyberia
Deinterlacing is not the purpose of DGMPGDec. The newbiew can learn about deinterlacing plugins, and then they won't be newbies.
Yes, but I still can't imagine how to know what type of deinterlace I need for movie. Also, I usually can't be 100% sure that I use right deinterlace method. :(

[Boulder]

Even if DGIndex could do the deinterlacing, it would have the same problem to solve. To determine the needed method, you must use your own eyes.

[Cyberia]

Originally posted by AlexeyS
Yes, but I still can't imagine how to know what type of deinterlace I need for movie. Also, I usually can't be 100% sure that I use right deinterlace method. :(

Well, start with the sticky threads at the top of this forum. Especially the one about IVTC and Deinterlacing methods.

[AlexeyS]

Originally posted by Cyberia
Well, start with the sticky threads at the top of this forum. Especially the one about IVTC and Deinterlacing methods.
Ok. But every newbie must become video editing professional before he can make ideal deinterlace. ;)

I think such utility will be greatest video editing utility ever, because a lot of people looking for good deinterlace and 99% are nothing know about video editing. :)

[Cyberia]

Originally posted by AlexeyS
I think such utility will be greatest video editing utility ever

Well, I won't argue with that, but no one has made such a utility yet...

[MacAddict]

Is it fairly safe to just use iPP default settings at this point on interlaced material? The default is apparently 'auto' based on flags correct?

[Cyberia]

It's safe, but iPP doesn't deinterlace. It's a deblocker/deringer.

[midnightsun]

Hello there Neuron2, I use your application all the time and I think it's great. I would have one minor request if it's not too much trouble: would it be possible to include the .vro extension in the list of common mpeg program stream files that DG autodetects when you go to the open window? Of course I can still open these files choosing "all files" when the explorer window pops up, but I thought it would be neat if these program streams were automatically detected.

.vro, in case you're not familiar with it, is a mpeg-2 program stream used by dvd recorders in VR mode. It usually contains one mpeg-2 video stream and one mpeg, ac3 or pcm audio stream.

Thanks again!

[Guest]

Sure, no problem. Thanks for pointing it out.

[midnightsun]

Cool :cool:

Thanks again!

[onesoul]

While we're at it maybe it would be worth to add .mpv extension which is delivered by cce. I usually generate a d2v file from cce output for testing purpose (comparison with other settings/encoders) which I load through avscompare.

Saying so, it is not a big deal anyway :).

[Guest]

Hey, onesoul! For you, anything. :)

Here is DGMPGDec 1.3.1b6. The following changes are made:

* The process priority can now be changed in DGIndex during a Save Project operation.

* A bug in the PAT/PMT parser was repaired that could cause DGIndex to erroneously think that a PAT/PMT is not present.

* Added the .vro and .mpv file types to the DGIndex open dialog.

* Fixed the broken Reference IDCT (type 4). Changes by jackei, derived from his latest DVD2AVI version.

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

[onesoul]

Thank you neuron2 :), your work is much appreciated.

[Zyphon]

Thanks for the update of your excellent tool neuron2. :)

[gizmau]

@neuron2

could you implement an indicator for dgindex beeing in pause-mode, because the only hint for hybernate ist the time elapsed/remain not running. a little PAUSE would be more user friendly, i think.

i dont know if my examples are just picky, but for me dgindex only shows the status of the first two audio stream of a vob, even when there are more present. is this a common behaviour or belonging to my files?

keep up the good work!

[Guest]

because the only hint for hybernate I don't understand this at all. Care to explain what you're talking about?

dgindex only shows the status of the first two audio stream of a vob, even when there are more present Can you provide a VOB fragment that demonstrates this? How are you determining that there are more tracks? What kind of audio is missing?

[gizmau]

I don't understand this at all. Care to explain what you're talking about?

i attached this screenshot of dgindex' information window:

http://img136.echo.cx/img136/6497/dgindexnotshowingpause7lg.png (http://www.imageshack.us)

is dgindex working right now or just stopped by pressing space bar?
you cant tell, because there is no message which indicates the current state of operation. i would like to see a simple PAUSE or STOPPED in den "Info"-field.

Can you provide a VOB fragment that demonstrates this? How are you determining that there are more tracks? What kind of audio is missing?

as to be seen on the screenshot, only two streams are shown, allthough there are 2x DD 384, 2x DD 192 and 1x DTS 768. dgindex even demuxes them correctly, but the information windows doesnt show them. i'll upload a sample to your ftp.

[Guest]

i would like to see a simple PAUSE or STOPPED in den "Info"-field. Why would you like that, given that you can see from the main window whether it is running or not?

i'll upload a sample to your ftp. I downloaded your file. When I open it in DGIndex I get total garbage for the video. I won't spend any time on it until you advise about that.

[Guest]

OK, never mind, I was able to use the file even though the video was garbage. I found the bug and it will be fixed in the next beta. Thank you for pointing it put. The bug causes a maximum of only two tracks to be shown, when it should be eight.

[gizmau]

Why would you like that, given that you can see from the main window whether it is running or not?

when dgindex is running at low priority and another task with highest priority eats up all the cpu-time there is no movement in the progress bar.

I downloaded your file. When I open it in DGIndex I get total garbage for the video. I won't spend any time on it until you advise about that.

hm, no distorsion here.. MD5-checksum is 9B0C02A1AA5FD1809CBEC457ACC4AE06 - can you verify that?

I found the bug and it will be fixed in the next beta. Thank you for pointing it put.

too fast! ;) thank you for fixing!

[Guest]

when dgindex is running at low priority and another task with highest priority eats up all the cpu-time there is no movement in the progress bar. And you forget whether you have paused or not???

Try beta 7 for the fix to the audio track info:

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

[acrespo]

Is possible to decode MPA audio directly to WAV? I need to convert MPA to WAV with Besweet to load in WAVSource() avisynth filter. If DGIndex do this convert, I need less steps to create my final video.

[Cyberia]

Is possible to decode MPA audio directly to WAV? I need to convert MPA to WAV with Besweet to load in WAVSource() avisynth filter. If DGIndex do this convert, I need less steps to create my final video.
You will need to continue using BeSweet. DGIndex cannot convert MPA to WAV, and all the decoding abilities will be removed before much longer.

[acrespo]

Why remove features instead add more options to already exists features?

[gizmau]

And you forget whether you have paused or not???

sure. maybe i am the only one who likes to get the actual status from the information window, but i thinks its useful, maybe just for optical reasons.


Try beta 7 for the fix to the audio track info:
works fine - thank you! :)

[Cyberia]

Why remove features instead add more options to already exists features?
Because BeSweet is MUCH better and faster at decoding, because the decoding code has, er, never been updated, because supporting decoding takes time away from other features, because....

[Cyberia]

And you forget whether you have paused or not???

Don, yes, this is a low priority issue, but along these lines maybe consider adding a new button to the GUI that toggles between Play/Pause.

That would solve the indicator issue, and I'd use it.

[Guest]

Here is the first stage beta for MPEG1 support. So far, only DGIndex has been modified. Do not try to load an MPEG1 D2V in DGDecode. Your CPU will overheat and melt, maybe even explode, if you do. You have been warned! This beta is to get some decoding exposure for the MPEG1 support in DGIndex. Note that the Info dialog works and the D2V file is generated. Again, do not try to load an MPEG1 D2V with DGDecode (MPEG2 is fine). That will be done in the second stage beta. Also note that this beta bumps the D2V file version to add an MPEG type field.

Please give me your feedback on the MPEG1 support in DGIndex. I also need to know if I have broken anything in the existing MPEG2 support. Thank you.

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

[iNFO-DVD]

Hi, you are a busy man........

Right, when you say MPEG1 support do you mean 'normal' MPEG1 or/and VideoCD MPEG1 files?

Anyway, I just tried 2 different VCD mpg's, one PAL the other NTSC.

The one loaded in, but when I went to preview, or save, it said:
No data. Check your PIDS.

The other file, during load sort of locked up the program, apart from the titlebar it all went white...

Wee-hee...... my 100th post :D

[iradic]

Great news! Thanks.
Will try it as soon as possible...
Bye

[Guest]

OK, it looks like it supports only elementary streams right now, not MPEG1 program streams. I'll fix that and make a new beta.

[Guest]

OK, here's a version that should open MPEG1 program streams. All the previous caveats apply. I also should advise that the audio is not yet supported either. Right now, I just want to shake down the MPEG1 video. Please advise if you find any MPEG1 files that cannot be decoded. Also, please advise if you find any regressions in the existing MPEG2 support. Thank you.

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

[Cyberia]

I have a few giving the "warning: opening gop not closed" message. Does MPEG1 have gops?

Also, mpegs with 160 pixels or less vertically, make the slider bar and buttons disappear.

Besides that, every one of my test mpegs played!

[iradic]

Hi, just to say its working for mpeg1 here...

one question... it says interlaced - can this be true ..
mpeg1 is captured with pctv and re/de muxed a few times
burned to vcd and extracted from it ... ?

[Guest]

I have a few giving the "warning: opening gop not closed" message. Does MPEG1 have gops? Yes, MPEG1 has GOPs.

Also, mpegs with 160 pixels or less vertically, make the slider bar and buttons disappear. Yes, I saw that too. It resizes correctly when you hit F5, strangely.

Besides that, every one of my test mpegs played! Good. Thanks for the feedback.

[Guest]

one question... it says interlaced - can this be true ..
No, it can't be true, because MPEG1 doesn't have the concept of interlacing. I just forgot about that info box item. Thanks for pointing it out.

Does anyone have a VOB with MPEG1 in it. I need one for testing.

[SeeMoreDigital]

No, it can't be true, because MPEG1 doesn't have the concept of interlacing. I just forgot about that info box item. Thanks for pointing it out.

Does anyone have a VOB with MPEG1 in it. I need one for testing.I noticed this too!

I tried using TMPGEnc and MuxMan to create some Mpeg1 in VOB files but keep getting GOP warnings :(


Cheers

[Nic]

@neuron2: If you use QuEnc and set the mux profile to DVD and the codec to MPEG-1 you will get a VOB file with MPEG-1 video (make sure to have Audio in the AVS too, otherwise just a raw m1v stream will be created)

-Nic

[iNFO-DVD]

DGIndex used on MPEG1 I mastered as a DVD file then ripped the VOB file and loaded that VOB file in:

http://www.clonead.pwp.blueyonder.co.uk/aviprogram/DGi.jpg

Picked up the Audio too and made the D2V file and MPA file, cool, worked fine.

[Guest]

:goodpost:

Thanks, Nic and iNFO-DVD. It's not picking up the audio from MPEG1 program streams, though (VOB is MPEG2 program stream). I'm going to finish up MPEG1 video in DGDecode and then go back and straighten out the audio.

[Cyberia]

MPEG-1 video appears to be demuxing correctly too! Sweet.

Although, the demuxed file has an .m2v extension. Shouldn't it be .m1v?

[Guest]

Shouldn't it be .m1v? That's a rhetorical question, I assume. :)

Me will fix. Thank you for your feedback.

[Cyberia]

Does MPEG1 have an Aspect_Ratio flag?

If not, how is the Info panel determining this (or is that an incomplete section of the great masterpiece?)

[Guest]

Does MPEG1 have an Aspect_Ratio flag? Yes: pel_aspect_ratio, as defined in ISO 11172-2.

[Guest]

Getting closer, people...

I bumped the beta version to 1.4.0b1 to reflect the major addition of MPEG1 support. This version adds MPEG1 support to DGDecode. Please beat on it.

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

Still remaining are the following tasks to complete the job:

1. Fix window sizing problem with small frame size in DGIndex.

2. Add audio demuxing from MPEG1 program streams in DGIndex.

3. Grab video PTS and generate audio delay in filenames in DGIndex.

4. Use correct MPEG1 chroma siting for upsampling (currently uses MPEG2, although you'd be hard pressed to see the difference).

[ChickenMan]

Darn, just tried it with DVD2SVCD and I get a "Floating point division by zero" just before CCE starts encoding :( Oh well, thought it would be to good to be true. Maybe Mr DVD2SVCD needs to do a bit of tweeking to support this new version :)

EDIT: Just tried it with a MPEG2 stream as well, different errors, so looks like its back to good old ver 1.11 :)

[Guest]

The D2V file format is changed, so that may be the reason. I don't know how DVD2SVCD uses DGMPGDec.

Are you able to decode the MPEG1 just using DGIndex/DGDecode?

[ChickenMan]

Yep I suspect the changed D2V format is the problem, so we all just wait for an updated DVD2SVCD then :)

My few test MPEG1 mpegs (PAL & NTSC) all loaded into DGIndex okay (never found the audio though but all listed as Progressive), saved Project and that loaded and encoded fine with TMPGenc. Havent tried any avisyth scripts yet.

[SeeMoreDigital]

Are you able to decode the MPEG1 just using DGIndex/DGDecode?Mpeg1 video and audio de-muxing works perfectly for me!

I managed to find an 1GB .VOB file (Mpeg1 video @ 352x240 and MP2 audio), which 1.4.0 beta 1 had no difficulty in de-muxing. However, I was unable to use MuxMan to re-mux the streams back to .VOB as it complained of GOP length error!


Cheers

[absinthe]

Are you able to decode the MPEG1 just using DGIndex/DGDecode?I was able to decode MPG1 and MPA audio from a VOB with no prob (hey, that rhymed).

Doesn't recognize DAT files (had to change extension to MPG ... no big deal there, though).

Does not seem to demux audio from VCD MPG file (is it suposed to?), but does demux the video fine.

Thanks!

-abs

[Guest]

never found the audio though I said that audio demuxing from MPEG1 program streams isn't there yet. I do have it working here and will release a new beta shortly.

However, I was unable to use MuxMan to re-mux the streams back to .VOB as it complained of GOP length error! DGIndex does not modify the GOP in any way. Can you please follow this up with mpucoder?

Doesn't recognize DAT files (had to change extension to MPG ... no big deal there, though).

Does not seem to demux audio from VCD MPG file (is it suposed to?), but does demux the video fine. You shouldn't have to change the filename. Either drop the file on DGIndex, or use "Files of type" to select All Files in the open dialog.

VCD is an MPEG1 program stream so the above point about the audio applies. I have it working and will release a new beta with everything done just as soon as I complete the delay calculation. Should be within an hour.

Thanks, folks, for your useful feedback.

[Guest]

Here is the next beta. It now can get MPEG audio out of an MPEG1 program stream. I addressed the window problem with tiny MPEG1 files by implementing a minimum window display size for DGIndex of 320x240. I was able to make it size correctly for (e.g.) 160x120, but the trackbar becomes a joke. So this seems like a reasonable solution to always have a usable trackbar.

Note that the chroma siting issue affects only conversion to RGB so it affects only the built-in conversion filter YV12toRGB24 and VFAPI. I would like to remove the built-in conversion filters (YV12toYUY2 and YV12toRGB24) because Avisynth has better ones. Any objections? I will modify VFAPI in a next beta.

Still, there is an interesting issue raised. If you can decode MPEG1 or MPEG2 and send it to Avisynth and then somewhere later a conversion to RGB is done, how does that conversion know whether to use MPEG1 or MPEG2 chroma siting??? Fortunately, the difference is very small and perhaps not of practical significance.

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

Your feedback on this beta will be greatly appreciated.

[SeeMoreDigital]

DGIndex does not modify the GOP in any way. Can you please follow this up with mpucoder? I did and his reply was: -

Mpeg-1 has always been possible. But the same GOP constraints apply. This is not a Muxman restriction, but DVD. And considering that mpeg-1 has only frame pictures, more than 36 pictures means morethan 36 frames - twice the limit for DVD.
Make sure gop headers are not being removed - look at the original DVD with VobEdit to see how often [gop] occurs in the left pane. It should happen every I frame.And his more recent reply was: -
A gop must start with an I frame, so if there are not enough I frames to make shorter gop's then the video must be re-encoded.
There is a reason for the gop length restriction, and it has nothing to do with picture quality (arithmetic error accummulation) or any decoder related issues. The gop length restriction sets the maximum size of the most basic unit used to compose a VOBU. And VOBU's in turn have length restrictions as well of 0.4 to 1.0 second except the last of a cell, which may be as long as 1.2 second. Having gop's longer than 0.6 seconds (the difference between the shortest and longest allowable VOBU) would create situations where it is impossible to compose a compliant VOBU.
And a gop longer than 36 frames is either 1.2 or 1.44 seconds long, depending on television standard, which is longer than a legitimate VOBU.
If DVB streams are not DVD compliant then they can't simply be stuffed into a vob to be played on a DVD player, they must be processed before authoring.
Cheers

[Guest]

Thank you for that useful information, SeeMoreDigital! It does not, however, appear relevant.

You said that you demuxed the video from a DVD. It must therefore have DVD-compliant GOPs. Can you please make that point to mpucoder?

Can you please upload a chunk of the VOB to my server so that I can analyse it? Thank you.

[len0x]

Aspect ratio doesn't seem to be right for mpeg1 sources. For instance for 352x288 PAL source DGIndex displayed 4:3,625 when its clearly should have been 4:3...

[len0x]

More about AR in mpeg1 sources: I've got a few very weird ones - AR is displayed as 0.6735 (30fps 320x240) which is strange coz it doesn't have usual x:y notation at all. Its probably wrongly mastered (its still should have been 4:3) but it would be nice to see format of AR line in d2v file in generic form. Also what is the decimal separator used for AR values? It seems that sometimes its comma (3,625) and sometimes its dot (0.6735)...

[SeeMoreDigital]

Hi len0x,

I have a couple of PAL sources, that are both described as being 4:3, 625 even though they have been professionally encoded using different resolutions: -

http://img99.echo.cx/img99/1148/pal43352x2886dj.png

http://img39.echo.cx/img39/8944/pal43368x2243oi.png


And my NTSC sources are described as being 4:3, 525: -

http://img99.echo.cx/img99/5012/ntsc43352x2400gl.png

It seems as though the 625 and 525 expressions are with regard to the analogue vertical line count.


Cheers

[len0x]

ah, that explains it! I think that vertical line count could be removed from AR line as its not really needed and just messes up parsers :) Still wondering about AR of 0.6735 though...

[SeeMoreDigital]

ah, that explains it! I think that vertical line count could be removed from AR line as its not really needed and just messes up parsers :) Still wondering about AR of 0.6735 though...Which reminds me... Does anybody know of any tools that can re-write the PAR/DAR codes for Mpeg1 streams - without re-encoding?

I've tried ReStream, which although the developer says only works with Mpeg2 streams, it does seem to be able to change the PAR/DAR codes of Mpeg1 streams to either 1:1 and 16:9... but not 4:3.


Cheers

[midnightsun]

it looks to me as if 4:3,625 means 4:3 PAL (625 being the scan lines of a 50Hz PAL tv) and 4:3,525 means 4:3 NTSC (525 being the NTSC counterpart of 625 as explained above)

[Guest]

The Aspect Ratio field just reports the value from the ISO spec as I mentioned in an earlier posting. You can look at the table in the spec for details. Yes, ",625" means 625 lines, etc. That is the way it is described in the spec. There are oddball values without X:Y counterparts. That's why you see the funny decimal. Why it was used by the encoder I cannot tell you.

[Guest]

Beta 3 adds multiple instantiation for DGVfapi. Also, DGVfapi can now convert AVS scripts in addition to D2V files! Sort of a bundled AVS2AVI, if you will. Please give a hearty round of applause to tritical for contributing these enhancements. :thanks:

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

This is close to my release feature set. I want to integrate DGParse and DGFix and add GOP structure printout in DGParse output. Is there anything else that should be considered before drawing the line on the 1.4.0 release?

[mimage]

Beta 3 adds multiple instantiation for DGVfapi. Also, DGVfapi can now convert AVS scripts in addition to D2V files! Sort of a bundled AVS2AVI, if you will. Please give a hearty round of applause to tritical for contributing these enhancements. :thanks:

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

This is close to my release feature set. I want to integrate DGParse and DGFix and add GOP structure printout in DGParse output. Is there anything else that should be considered before drawing the line on the 1.4.0 release?It works so great for importing AVS files into Vegas!! Thanks a bunch for this release, it has made my day! :)

[kikounet]

More about AR in mpeg1 sources: I've got a few very weird ones - AR is displayed as 0.6735 (30fps 320x240) which is strange coz it doesn't have usual x:y notation at all. Its probably wrongly mastered (its still should have been 4:3) but it would be nice to see format of AR line in d2v file in generic form. Also what is the decimal separator used for AR values? It seems that sometimes its comma (3,625) and sometimes its dot (0.6735)...
VideoCD standard never had complied to 1:1 Pixel Aspect Ratio (PAR)!
4/3 is 1.3333 but 352/288 is 1.2222 (PAL) and 352/240 is 1.4666 (NTSC)
Professionaly encoded VideoCD complies to standards, so we have to deal with that, sorry... ;)

[len0x]

The Aspect Ratio field just reports the value from the ISO spec as I mentioned in an earlier posting. You can look at the table in the spec for details.

Can you point me to link with the spec, please? (is it hosted in your library?)

*Edit* I found the document on your website (mpgvideo.doc), but the table for pel_aspect_ratio seems to have mostly decimal values without corresponding AR like 4:3 for instance. How do you get values like 4:3,525 from it?

[guada 2]

Neuron and Tritical

Very Big and Good work. :thanks:

Good bye ;)

[Guest]

I found the document on your website (mpgvideo.doc), but the table for pel_aspect_ratio seems to have mostly decimal values without corresponding AR like 4:3 for instance. How do you get values like 4:3,525 from it? Here's the table from the document:
pel_aspect_ratio height/width example
0000 forbidden
0001 1.0000 VGA etc.
0010 0.6735
0011 0.7031 16:9, 625line
0100 0.7615
0101 0.8055
0110 0.8437 16:9, 525line
0111 0.8935
1000 0.9375 CCIR601, 625line
1001 0.9815
1010 1.0255
1011 1.0695
1100 1.1250 CCIR601, 525line
1101 1.1575
1110 1.2015
1111 reserved I have a later version of the spec at works that replaces the CCIR601 with 4:3.

[scharfis_brain]

are you sure, that those values are really the correct ones?

they all seem to be generic PAR, which is not recommended by ITU...

[SeeMoreDigital]

The 4:3 and 16:9 (NTSC/PAL) values are exactly the same settings I use when adding DAR signalling to my Mpeg4 streams.... nice!

[len0x]

Here's the table from the document:
I have a later version of the spec at works that replaces the CCIR601 with 4:3.

Ah, that explains it. Thanks.

[Guest]

are you sure, that those values are really the correct ones?

they all seem to be generic PAR, which is not recommended by ITU... I just display the contents of the field as per the MPEG1 spec. Are you asking if the spec is correct?

[scharfis_brain]

the problem I saw is just this:

PAL-VCD has 352x288 pixels, that need to be streched te 384x288

the table above shows:
1000 0.9375 CCIR601, 625line

but 352 / 0.9375 = 375,7 ???

the same for NTSC-VCD:
352x240 is squeezed to 320x240

the table shows:
1100 1.1250 CCIR601, 525line

352 / 1.125 = 312,9

So I am asking:
what is going on here?

[Arachnotron]

PAL-VCD has 352x288 pixels, that need to be streched te 384x288

the table above shows:
1000 0.9375 CCIR601, 625line

but 352 / 0.9375 = 375,7 ???352x288 PAL VCD has a playback sample rate of 6.75 MHz, so the line length is 352/6.75 = 52.14815 µs. Square pixel 384 x 288 describes only 52 µs. So you need to crop of 2 pixels first before stretching.

[Arachnotron]

@Sharfi

This (http://groups.google.com/groups?selm=9704042219.AA21866%40python.pictel.com) link seems to explain where your 375 came from. I found it amongst the references at the end of this (http://www.uwasa.fi/~f76998/video/conversion/#4.11)page.

[edit] it seems that somewhere along the way, they *defined* 352 pixels = 384 sq. pixels, even though with the VCD sample of 6.75 rate, 351 pels equals 384 as a sort of compromise to *simplify* things. (note that in this post the PAL acive area is set to 704 13.5 MHz pixels, while that should be 702)

So now there are two sets of values: those based on sample rates and the BT471 4:3 active window of 52 µs x 576 lines and those based on the assumption that the PAL active window is 704x576/352x288

I imagine something similar happend with NTSC.

[edit 2] 0.9375 is based on the (mistaken) assumption that the 720x576 DVD frame maps to a 4:3 area, so equals 768x576. That is of course wrong, it should either be 702x576 (if you want to be exact) or 704x576 (if you follow the compromise above)

[Cyberia]

FYI - Here are two links to some very good Aspect Ratio conversion pages:

http://www.mir.com/DMG/aspect.html

http://www.uwasa.fi/~f76998/video/conversion/

[Guest]

tritical sent a bug fix for the VFAPI support. I also added something. See if you can find it. :)

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

[SeeMoreDigital]

Cool....

http://img185.echo.cx/img185/2347/dgindex140b44wo.png

....what do I win?


Cheers

[mp3dom]

I have a problem with the 1.4.x version of DGIndex. I have a 50Mbps MPEG-2 (all I frames) produced with Pinnacle Chrome HD. When I open the 50 Mbps file in DGIndex I have a bad preview (all colors seems to be wrong) and the creation of D2V require a LOT of time (about 5 hours for a 30 min. movie).
This problem doesn't appear with the 1.3.x version (the D2V creation require about 5 min).

[Guest]

I have a problem with the 1.4.x version of DGIndex. I have a 50Mbps MPEG-2 (all I frames) produced with Pinnacle Chrome HD. When I open the 50 Mbps file in DGIndex I have a bad preview (all colors seems to be wrong) and the creation of D2V require a LOT of time (about 5 hours for a 30 min. movie).
This problem doesn't appear with the 1.3.x version (the D2V creation require about 5 min). Please upload the file or a portion of the beginning to my FTP server and notify here when it is there. Up to a couple hundred MBytes is fine.

Also, can you fill in the x and tell me exactly which was the first version to exhibit the problem?

Also, please see if it is being incorrectly decoded as MPEG1 by looking at the Profile field of the info dialog during preview. Does it say "[MPEG1]"?

[E-Male]

is there a way to add many vob files at once via command line (i mean 100+)?

thx

[Cyberia]

is there a way to add many vob files at once via command line (i mean 100+)?

thx

RTM. Just a little poking around and you would have solved this for yourself. Read the file "CommandLine.txt" in the directory where you installed DGMPGDec.

Either the -BF or -AIF commands should be what you're looking for.

Admittedly, the information pertaining to DGIndex is scattered around several files/web pages/secret caches/etc. I am working on an actual DGIndex manual that will centralize all this witchcraft into one location.

But still, is "CommandLine.txt" not obvious enough?

[E-Male]

in my commandline.txt there only are 2 input options:
-AIF <-- won't work, the filenames aren't 'numbered' enough
-IF <-- won't work either, or can i put 100+ filenames in one command-line

EDIT:
my file was outdated (and the new updates don't contain commandline.txt)
found -BF

[Guest]

my file was outdated (and the new updates don't contain commandline.txt) The beta releases don't include all the documents. Go back to the last released version; in this case, 1.3.0. Sorry for the inconvenience.

[Guest]

I have a problem with the 1.4.x version of DGIndex. Are you still there? I'm getting a release package together and I'm really keen to get this issue resolved before the next release. I responded to your post with a query for some further information (see several posts above). Thank you.

[SCIF]

neuron2, update link for DGMPEGDec 1.4.0 beta 4 at your home page.
Thanks for your great work.

[Guest]

neuron2, update link for DGMPEGDec 1.4.0 beta 4 at your home page.
Thanks for your great work. Thanks for the pointer, but I don't update the home page until I'm reasonably confident of the stability. You Doom9'ers are the guinea pigs. Right now, I'm waiting for mp3dom to elaborate on his problem, because if it's true, it is a big deal.

[E-Male]

The beta releases don't include all the documents. Go back to the last released version; in this case, 1.3.0. Sorry for the inconvenience.
i now have 1.3.0 and beta 4 copied over it
thx

[Guest]

I've now reached feature cutoff for 1.4.0 with this beta. This version adds the following changes:

* The integrated DGParse info now shows the GOP structure.

* Fixed a bug such that during preview the info dialog did not show the audio track information for transport streams and PVA streams.

* The Detect PIDs dialog now has a "Done" button.

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

Now we are in bug fixing mode only for 1.4.0. So pound away!

[Guest]

This beta fixes mp3dom's reported bug.

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

Everybody should get this correction because b5 is significantly broken. I've also corrected the D2V format document after Cyberia pointed out several problems in it.

Thanks mp3dom for catching this bug, and Cyberia for the corrections.
:thanks:

[Guest]

This one fixes some bugs in the integrated Parse D2V feature, and enhances it to properly show the effect of the field operations.

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

[len0x]

Does current version open DAT files (VCD) directly without renaming to mpg extension?
(I'd try myself but don't have any VCDs at hand).

[Guest]

Does current version open DAT files (VCD) directly without renaming to mpg extension? Yes, but they won't show up in the open dialog unless you choose "All files" in the "Files of type" pulldown, or drag them onto the DGIndex window. CLI of course can specify them directly.

BTW, I've seen an MPEG1 that had a height not a multiple of 16. But DGMPGDec is riddled through with the assumption that the display width/height are the same as the encoded width/height. The result is a black bar at the bottom. The workaround (for now) is to put Crop() in the script.

[len0x]

ok, thanks.

[Cyberia]

FYI: drag-n-drop also works for dat files.

[Guest]

This addresses a bug in transport parsing. For details, see here: http://forum.doom9.org/showthread.php?t=93190

DGMPGDec 1.4.0b8:

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

[Guest]

Here is 1.4.0 release candidate 1. The changes from beta 8 are as follows:

* Removed YV12toYUY2() and YV12toRGB24() because they duplicate Avisynth native filters.

* Changed the LumaFilter() offset parameter default to 0 (from -2).

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

[Cyberia]

I thought we had those colorspace converters because AviSynth did not have the necessary information to upsample interlaced formats correctly some of the time? (ie: PROGRESSIVE_FRAME flag)

EDIT - See this thread: http://forum.doom9.org/showthread.php?t=76609&highlight=YV12toYUY2%28%29

EDIT2: I remembered in the old MPEG2Dec3 manual the lumaoff parameter was set to -2 with a comment "for iago", so I did a search for "iago mpeg2dec3" and found this thread: http://forum.doom9.org/showthread.php?t=31301&page=7&pp=20&highlight=iago+mpeg2dec3 which basically says MarcFD set the lumaoff to -2 to avoid luma blocks. It is a long thread, but just look for iago and MarkFD's comments.

Summary: iago did some extensive testing and saw blocks in the black areas, but seting lumaoff=-2 tweaked the luma just enough to remove the blocks without changing the original image in a perceptable way. MarkFD accepted it, but thought it was not the best solution.

[Guest]

I thought we had those colorspace converters because AviSynth did not have the necessary information to upsample interlaced formats correctly some of the time? (ie: PROGRESSIVE_FRAME flag) Nope. Those filters did not, and could not, use the progressive_frame flag. They receive decoded video from MPEG2Source(). And anyway, if you need that capability, you use upConv=true.

Summary: iago did some extensive testing and saw blocks in the black areas, but seting lumaoff=-2 tweaked the luma just enough to remove the blocks without changing the original image in a perceptable way. MarkFD accepted it, but thought it was not the best solution. Users can set -2 if they like it. Mention it in the manual if you like. But it sounds silly to me.

[ARDA]

@neuron2

I address you about this subject for second time
First time here http://forum.doom9.org/showthread.php?p=655698#post655698
As I think I couldn't make me understand I''ll try to be more clear now

LumaFilter had serveral bugs and special features

First time a bug was detected was about LumOffsetMask and LumGainMask
http://forum.doom9.org/showthread.php?p=322136#post322136
I've spotted to Nic but for what I've seen just half of the bug has been
fixed.The way the variables were declared (__declspec(align(8)) static __int16)
didn't allow a second instance of the filter in the same chain; cause it repeat the
first input parameters; are still present in two cases in DGDecode.dll.
In fact what I've done was completely change the way to pass the parameters

Another question it has not parameters controls.In some cases it can output corropted
images.I've also included that.

There also an important feature which I've also pointed
in this thread http://forum.doom9.org/showthread.php?t=71452
more than a year ago.Nobody answered.
Finally I've believe that when MarcFd tested LumaFilter was in time when there
was a SeparateFieldsYV12 in MPEG2Dec3 0.94 which worked creating two real new frames
in different memory areas.SeparateFields the internal one just redifine the size of pitches
and readjust the pointers.That is why any filter built over frame area (pitch*height)
will not work correctly.To avoid that I've include row loops when vi.IsFieldBased()=true
By now is an easy solution but I'm not sure if it is the best.
Anyway for my own use I've modified a little bit SeparateFieldsYV12 as an idependant plugin
If anyone is interested to bring it up just ask.

Obviously the -2 parameters as default you've already corrected

And finally I've made separate assemblers codes for SSE2 ISSE and MMX
where I've added some optimizations.
There is a lot of duplicated code and I hope as always you can be generous
in your opinions. This plugin was renamed as you can see for one I've found more
appropiate and to avoid conflicts

Many would ask why all this; just to improve perfomance and in some of my machines
more than 50%.
***********************************************************************************
LumaYV12 plugin for Avisynth 2.5 by ARDA.

LumaYV12 is a new version of LumaFilter included in MPEG2DEC3.dll by MarcFD.

It assumes [0->255] YUV range, and not CCIR 601 [16->235].
Use limiter() afterwards if you think you need it.

Syntax: LumaYV12(lumoff=param,lumgain=param) or LumaYV12(param,param)

WARNING!!WARNING!!

lumoff=-256 to 256 (integer) ; default 0 and will do nothing.
lumgain=0 to 2.0 (float) ; 1.0 is default and will do nothing.
************************************************************************************
WARNING!!WARNING!!

This plugins was done for my own use trying to achieve a better perfomance
in my pentium4 cpu; I've also included Integer SSE and MMX routines but
perfomance was not tested.
It must run on any SSE2 machine but perfomance is not guaranteed.

I've also included row routines to avoid first line problem after separatefields.
Seems there is not real two frames, but a redefintion of pointers and pitches.
Maybe there's another way to avoid that problem but I couldn't find an easier one.
Row loops will be here till SeparateFields could be modified.

Actually they are exercises; so there are a lot of unnecessary duplicated code.
There must be a lot of spanglish variable names; my apologizes for that.

Please be patient!.-
I'm an eternal newbie coder.-
************************************************************************************


download
http://ardaversions.iespana.es/lumayv12.7z

As always I hope this can be useful.
ARDA

[Guest]

The way the variables were declared (__declspec(align(8)) static __int16) didn't allow a second instance of the filter in the same chain; cause it repeat the first input parameters; are still present in two cases in DGDecode.dll. Agreed. Thanks for pointing it out.

Another question it has not parameters controls.In some cases it can output corropted images. Range checking? Fair enough.

There also an important feature which I've also pointed
in this thread... I've duplicated this and it is a bad problem. I'm not sure I like the way you've fixed it. I have to think about it.

And finally I've made separate assemblers codes for SSE2 ISSE and MMX where I've added some optimizations. That sounds useful.

I'll test your filter version and if it appears OK, I'll replace the existing broken one with it. Thanks for your contribution.

Also, if you could report your issues in the development thread prior to the release candidates appearing, it would be appreciated.

[Marius-the-Mad]

neuron2, thank you very much for MPEG 1 support. :) DGDecode is great and now it's even better. :)

I have a question connected to MPEG 1 support. DGDecode seems to output YV12 by default for MPEG 1. Is it intended behaviour ? If it is, does using upconv=true result in original YUY2 or is it the upsampled version ?

Sorry if I'm being silly, but I couldn't find anything about it. :(

[Guest]

DGDecode seems to output YV12 by default for MPEG 1. Is it intended behaviour? Yes. Do you think it shouldn't be?

If it is, does using upconv=true result in original YUY2 or is it the upsampled version? I don't know what you mean by "original YUY2".

[Marius-the-Mad]

:eek: Sorry. It was my impression that MPEG 1 used YUY2 instead of YV12. I thought it would be nice to have it in YUY2 by default.

Again, sorry if I'm confusing things.

[Cyberia]

Without YV12toRGB24() do we still need the TVScale option in DGIndex?

[Guest]

Can anyone give a reason why LumaFilter() should not be dropped altogether since the Avisynth native filter ColorYUV() is more capable?

[ARDA]

Originally Posted by neuron2
I've duplicated this and it is a bad problem. I'm not sure I like the way you've fixed it. I have to think about it.
I agree with both affirmation


Originally Posted by ARDA
By now is an easy solution but I'm not sure if it is the best
Row loops will be here till SeparateFields could be modified.

Also, if you could report your issues in the development thread prior to the release candidates appearing, it would be appreciated

You're right my apologizes next time I'll just upload that parts of code I think
could be usefull.

But I hope you understand after looking at the sources that I've used such filter as exercise for many other things.

Your mate
ARDA

[ARDA]

Just one with the optimizations I've done the difference in perfomance would be giant.
Obviously in those functions with similar results.
That could be a simple reason if speed is important in some cases.

ARDA

[Guest]

It was my impression that MPEG 1 used YUY2 instead of YV12. Oh, I see your point now. MPEG2 supports 4:2:0 and 4:2:2, but MPEG1 supports only 4:2:0. Even if it had 4:2:2 it could be handled in the same way as MPEG2 (leaving aside chroma siting).

[Guest]

Just one with the optimizations I've done the difference in perfomance would be giant.
Obviously in those functions with similar results.
That could be a simple reason if speed is important in some cases.
OK, thanks.

[Marius-the-Mad]

MPEG2 supports 4:2:0 and 4:2:2, but MPEG1 supports only 4:2:0. Even if it had 4:2:2 it could be handled in the same way as MPEG2 (leaving aside chroma siting).Thank you for the explanation. :) I have to remember that.

[SeeMoreDigital]

Hi Donald,

Earlier today approached mpucoder about with the following suggestion: -Hi mpucoder,

Would it be possible to increase the range of the of the "Delay" settings [of MuxMan]. The current range is between -300ms to +300ms.

Earlier today I used DGIndex to de-mux 5No clips (with different run times) from within the same .VOB file and obtained audio streams at -320, -160, -448ms, -224 and -288.

However, when I used MuxMan to re-mux the -448 .AC3 stream to the .M2V stream, it was sadly out by miles Followed by my second post: -...I often receive "Show Reel" DVD's from people within the media industry that contain multiple short clips of their work - TV/cinema commercials mostly, pop promos, short films and the like...

A typical TV/cinema commercial can run anything from between 10 to 90 seconds and usually a DVD arrives on my door step with several clips running one after another, burned into one .VOB and with no chapter breaks!

What I currently do is use DVD Decrypter to drag the .VOB file(s) onto my PC and then DGIndex to separate and select the start and end points for each clip.... But this creates individual de-muxed clips with very different audio delays!

If the delays are no greater than -300 to +300ms I can correct them perfectly with MuxMan... but not, if the are outside of those limits
To which mpucoder replied: -...this is caused by not de-multiplexing the audio properly. When extracting elementary streams, does it not make sense to extract the streams in sync? That is, to extract the audio that corresponds to the video. Why not go here [your DGIndex thread] and ask for a fix to the problem.

And if there are de-multiplexers that do this properly, my apologies for not mentioning them - feel free to speak up. (If you require reading all the posts please look here (herehttp://forum.doom9.org/showthread.php?p=673237#post673237))

I wonder, is this a DGIndex problem or an I going about this entire exercise the wrong way?


Regards

[Guest]

@SeeMoreDigital

If mpucoder is serious about his point that the demuxer should take care of this, then he should not have a delay adjustment at all! If he has one, it should cover the range of delays typically encountered.

All other tools that I know of do not have this limitation on delay adjustment, e.g., VirtualDub, Avisynth, TMPGEnc, etc.

It is on the development list already to produce no-delay audio files (within the limits of frame granularity). I'll start experimenting with it, but it won't be in 1.4.0. A workaround for you is 3rd-party delay correctors, such as AC3DelayCorrector.

Why is it such a big deal for mpucoder to widen his range a little?

[Cyberia]

TVScale in DGIndex is needed for VFAPI isn't it? I may have answered my own question.

[SeeMoreDigital]

Why is it such a big deal for mpucoder to widen his range a little?I dunno, maybe mpucoder is having a bad day!

I have to say, I'm using DGIndex and MuxMan almost every day now and to be honest although I'm not 100% familiar with every facet of their individual functionality, I don't consider myself as a novice!

As a matter of interest, what "delay" range would you consider as being useful?


Cheers

[mpucoder]

Not having a bad day, as said in this post (http://forum.doom9.org/showthread.php?p=673272#post673272) the inaccuracy not only causes excess audio at the start, but also a premature end. And nothing but the demuxer can fix that (unless you
concatenate the next cell's audio). So it's better to fix this in the demuxers.

Also MuxMan 0.14f is the last of 0.14, 0.15 features are frozen (nothing but bug fixes) and 0.16 will have the ability to set start/stop points within source streams, making the delay setting redundant for negative delay.

I didn't want the delay setting at all, but it was put in as a concession, with a range of plus/minus 300ms. That range is more than enough for dropped frames, anything higher indicates a problem in the demux.

[stephanV]

@neuron2

As a matter of interest, how do you tend to "fix" this delay? By padding or removing frames from the audio stream? If so, I kindly request to at least leave the option open to keep the delay. :)

[SeeMoreDigital]

Personally speaking when it comes to setting, plus/minus audio delays I would rather it to be measured by the frame rather than millisecond ;)

That said, I think it will be a while yet before every de-muxer will be able to offer perfectly synced de-muxed streams, so it would be a great shame to drop this implementation in MuxMan altogether (always useful to have a backup plan).

Thankfully all the Mpeg de-muxers I've tried so far highlight the delay time, making it easier to re-sync the streams in MuxMan.


Cheers

[Guest]

As a matter of interest, how do you intend to "fix" this delay? By padding or removing frames from the audio stream? If so, I kindly request to at least leave the option open to keep the delay. Yes, of course you'll be able to choose to correct or not. I'm not sure how I'll do it yet. Either the audio or the video could be changed. The former has the complication of lots of different audio types. The latter has the complication of orphaned reference frames, etc.

[kikounet]

To SeeMoreDigital.
Sorry to be so curious,
What I currently do is use DVD Decrypter to drag the .VOB file(s) onto my PC and then DGIndex to separate and select the start and end points for each clip.... But this creates individual de-muxed clips with very different audio delays!
Why don't you ask DVD Decrypter to do the demux and separation by CELL ID? :confused:

[SeeMoreDigital]

To SeeMoreDigital.
Sorry to be so curious,

Why don't you ask DVD Decrypter to do the demux and separation by CELL ID? :confused:You may well ask ;)

Here's the file structure of a typical DVD I receive: -

http://img298.echo.cx/img298/9262/disclayout1wm.png

As you can see, this DVD only has a total run time of 7 min 32 sec and yet it has 2No VTS segments. The first segment contains 2No chapters with 19No and 2No Cells respectively. The second segment contains 1No chapter with 7No Cells....

If you ripped all these separately you would end up with this lot: -

http://img298.echo.cx/img298/2439/cellidlist7gz.png

By the way, this disc only contains 10No TV commercials: -

1No Alton Towers - RITA
1No Coca-Cola - Bring me Sunshine
2No Peugeot - Man Hair / Woman Fantasy
2No INPES Passive Smoking - Marie / Luke
1No HSBC Bank - Careful German Driver
3No AM/PM Stores - It's 3:30 / Student Driver / Commitment


Cheers

[Guest]

Here is 1.4.0 RC2. The changes from RC1 are as follows:

* Replaced the buggy LumaFilter() with a new, optimized LumaYV12() filter by ARDA. Thank you for your contribution, ARDA! The DGDecode manual was updated appropriately.

* Minor GUI cosmetic changes in DGIndex.

* The integrated ParseD2V and FixD2v functions now reject obsolete D2V files (ones with earlier D2V format).

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

[bbouchaib2002]

Thank you very match for your work ;)

I used dgindex specialy to encode my ts files (recorded by dreambox satellite receiver) to divx.

But since version 1.3.1beta5 (unil 1.4.0RC2) I can not read my ts files.
The program hangs and do noting after choosing the ts file and clicking on OK.

What happend for the recent releases ?

[Guest]

Thank you very match for your work ;)

I used dgindex specialy to encode my ts files (recorded by dreambox satellite receiver) to divx.

But since version 1.3.1beta5 (unil 1.4.0RC2) I can not read my ts files.
The program hangs and do noting after choosing the ts file and clicking on OK.

What happend for the recent releases ? Please upload a test file to my ftp server and notify me here of its file name. With the test file I'll be able to quickly resolve your problem. Thank you.

Also, it would be appreciated if you did not wait for a release candidate to report your issues!

[bbouchaib2002]

it would be appreciated if you did not wait for a release candidate to report your issues!

Excuse me, I have not encode any thing from a while, and when I test the last version yesterday, it do no work for me an I download the previous versions one after one untile v1.3.1b4 that work.

I have make some tests today and this is what I have discover :

When I open a file from my local drive it work, but if I open it directly from its original location (the hdd of dreambox shared with samba) it not work.

with 1.3.1b4 no problems, I always open files directly from \\192.168.0.3\Harddisk\movie\ (I prefer because files are very big)


Have you change the manner of opening files between 1.3.1b4 and 1.3.1b5 ?

[Guest]

There's been no change to file opening. Please explain exactly what you mean by "it not work". Is there an error popup? What do you see?

[bbouchaib2002]

No there is no popup, when I add the file in the "file list", and after I press the "OK" button, 2 things can happends after :
1- in 90 % of cases, it return to the main interface and the "stream" menu is disabled and nothing happend after (as if I just open the program)
2- in the others cases it return to the main interface and the "stream" menu is enabled, but if I click on it the program hangs and I have to kill it.

[Guest]

Version 1.4.0 RC 3 fixes the problem with opening across the network, as reported by bbouchaib2002. I also added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps. :)

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

Could this be the winner?

[iNFO-DVD]

Let me be really cheeky and ask you what's the chance of you changing something before this goes final.....

Due to the use of the "[" and "]" to parse your filename in the CLI we can not use them symbols in a path and/or filename.

What's the chances of changing them to "<" and ">" because this issue would never arise again because you can't use "<" and ">" in a filename/path anyway.

I'm sure this would be very quick for you to do and the only downside I can see would be programs would need to change the way they call DGIndex slightly but that's not a problem because they would have to change their programs slightly anyway because of the updated D2V format.

I hope you can please do this..... you'll be my biggest hero :)

[SeeMoreDigital]

... I also added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps. :)

...Could this be the winner?Errrrm!

Would it be possible to add a frame counter... at some time. Or would this be too much like "very hard" work?


Cheers

[Backwoods]

Another day and another upgrade, awesome thank you.

Also if you remember a month or so ago there was a problem with my captured M2T files. They would freeze up the program for a bit then run, then the error was supposed to be fix, it wasn't. In these latest betas, no problems what so ever.

Just thought I'd run that by you. Thanks again.


EDIT: spelling (program -> problem, duh)

[Guest]

What's the chances of changing them to "<" and ">" because this issue would never arise again because you can't use "<" and ">" in a filename/path anyway. Not possible. The DOS shell interprets them as redirection.

Actually, the [ and ] may be totally superfluous anyway. I'll look into it.

Would it be possible to add a frame counter... at some time. Or would this be too much like "very hard" work? There's one in the Info dialog already. Are you asking for something else? If so, be specific.

Also if you remember a month or so ago there was a program with my captured M2T files. They would freeze up the program for a bit then run, then the error was supposed to be fix, it wasn't. In these latest betas, no problems what so ever. Great. Thanks for the feedback.

@all

Stop with the new feature requests at RC time, people, or you'll make me mad. :) I mean, we've had like 15 betas leading up to this. That's what betas are for.

[SeeMoreDigital]

There's one in the Info dialog already. Are you asking for something else? If so, be specific.I apologise in advance if I've missed something but when I use the seek option to set start and end points, many details in the "Information" panel disappears: -

http://img78.echo.cx/img78/4017/dgindexframeseeking0bn.png


Cheers

[iNFO-DVD]

Not possible. The DOS shell interprets them as redirection.Oh OK, how about one of the others: \ / : * ? |
Actually, the [ and ] may be totally superfluous anyway. I'll look into it.I hope so, I know it probably sounds quite trivial but it is quite important to me.

[gizmau]

[QUOTE=iNFO-DVD]Oh OK, how about one of the others: \ / : * ? |
QUOTE]

\ and : are used for paths, / introduces parameters, * and ? are wildcards, | is used for pipe - i hope i remembered right :rolleyes:

[iNFO-DVD]

Well there must be something... Or drop the "[" and "]" altogether, how about "{" and "}"?

[Cyberia]

@INFO-DVD - I have already answered this question for you in the Development thread! Let me quote:Your only option would be to use the -BF([filelist]) option. I just tested it with [ ] in filenames and it does work fine.


As other people here have said, the characters you mention are illegal because they are used as functional characters.

Changing them to a { } doen't solve the problem. Then someone using {} will complain. There is only ONE possibility:

Don, would it be possible to use quotes " to delimit the file name, since thats what DOS uses also?

[iNFO-DVD]

yes I read your quote though that's hardly ideal, I didn't want to mess about making/using yet another batch/list of files......

I wonder why the "[" and "]" were used in the first place by DVD2AVI in the CLI? Like you say, you'd think it would be just the 'normal' name in quotes....

[SCIF]

At first page www.doom9.org wrote "DGMPGDec 1.40 RC4 fixes a problem opening files across the network. It also contains rudimentary playback speed control." Is it misprint?

[Selur]

typo, doom9 ment rc3 ;)
1.4.0 Release Candidate 3
Version 1.4.0 RC 3 fixes the problem with opening across the network, as reported by bbouchaib2002. I also added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps.

Cu Selur

[Guest]

when I use the seek option to set start and end points, many details in the "Information" panel disappears The information panel is fully populated only during a preview operation.

With the current architecture there's no way to tell you the frame number corresponding to a trackbar position.

What is it exactly that you are trying to achieve and why?

[Guest]

I wonder why the "[" and "]" were used in the first place by DVD2AVI in the CLI? Like you say, you'd think it would be just the 'normal' name in quotes.... Actually, even quotes are not needed, because the string is adequately delimited by the = and the following space, comma, or EOL. So, I made a version that accepts the syntax with or without the [] delimiters. I want to test it a bit better before letting you have it.

[iNFO-DVD]

cool, look forward to the release. :)

[SeeMoreDigital]

What is it exactly that you are trying to achieve and why?I've been using DGIndex for cutting out clips of Mpeg2 video (and audio), directly from DVD sources (ie: no ripping to the HDD first).

For future disc examination purposes I like to make notes on the DVD's inlay card, where the start and end frames are for each clip.

Also, after compiling a quantity of clips (in their elementary stream form) I can calculate where the start and end frame points are for each clip and create a text file which I can load into MuxMan.... granted, there are other ways I can obtain the frame information... I just thought it may be useful.

As a test, yesterday, I did made DVB-T capture from a music video channel. I was able to use DGIndex to cut out several music video's of interest. And after re-syncing the audio I used MuxMan to create an 4GB DVD with chapter points for each music video.


Cheers

[Guest]

cool, look forward to the release. Oops, Cyberia reminded me that a space can be part of a filename or path, so my approach won't work. I'll see if I can get quotes working.

[Guest]

We can't use quotes, because the DOS shell strips them. We could escape them by doing \" but that's silly.

I'm going to add a new option -SD for Set Delimiter.

Then you can do:

-SD=! -IF=!file1.vob,file2.vob! -OF=!clip!

The default will be [ and ] for backward compatibility.

[kikounet]

Oops, Cyberia reminded me that a space can be part of a filename or path, so my approach won't work. I'll see if I can get quotes working. Don't you realize that charachters '[' and ']' can too be part of a filename ?

[iNFO-DVD]

Ummm Yes, that's the whole point....

[Teegedeck]

Hm, RC3 seems to crash on this VOB.

http://img201.echo.cx/img201/2793/dgindexerror29hd.th.png (http://img201.echo.cx/my.php?image=dgindexerror29hd.png)

http://img201.echo.cx/img201/640/dgindexerror1ml.th.png (http://img201.echo.cx/my.php?image=dgindexerror1ml.png)

An old DGIndex version I still have on my HD doesn't seem to have a problem with it:

http://img201.echo.cx/img201/4007/dgindex10127dn.th.png (http://img201.echo.cx/my.php?image=dgindex10127dn.png)

[Guest]

Hm, RC3 seems to crash on this VOB. Please upload the first part of the VOB to my FTP server and tell me the filename here. You can put up to several hundred MBytes, or only as much as is needed to show the problem, i.e., working in 1.0.12 but not in 1.4.0. Thank you.

[Teegedeck]

In progress. Thanks for always promptly reacting to stuff like that. :)

Edit: Ah, filename: kumonomukou.vob

[Teegedeck]

I hope you don't mind that it is almost 1 GB (889 MB). But I only know how to get parts from a VOB with MPEG2Cut; and that 'repairs' the file as a result. Just close the connection if you think it better.

Edit: Just got '550 Can't check for file existence' and transfer starts anew. Pure-FTPd is not always fun, is it?

Edit: OK, several times the same error; aborting.

[Guest]

Please stop your upload. I don't have enough space. Thank you. I've already got 70Meg of it. It should be enough.

[Guest]

Hm, RC3 seems to crash on this VOB. Your vob has about 630 KB of stuff before the first pack header (mostly zeroes)! So it was not detected as a program stream, because I was looking only at a much smaller portion of the beginning of the file to look for pack headers. I have the fix already and will release it tonight. Thanks for pointing this out.

[Cyberia]

Try using a progam called "Chopper XP" to cut the vob. See if that 'repairs' the vob too.

EDIT: Nevermind

[Teegedeck]

Your vob has about 630 KB of stuff before the first pack header (mostly zeroes)! So it was not detected as a program stream, because I was looking only at a much smaller portion of the beginning of the file to look for pack headers. I have the fix already and will release it tonight. Thanks for pointing this out.
Brilliant! :) Sorry for stopping the transfer belated, I had to leave the PC unattended for some time and only looked at the error messages of FireFTP when coming back.

[Guest]

@Teegedeck

Where did that VOB come from? Did you rip it from a DVD? It appears to have been made with Sonic ROM Formatter. But what is all that junk before the first pack header? I'm a little worried about having to parse into 1 MByte of streams looking for a pack header due to the possibility of start code emulation.

[fccHandler]

You can virtually eliminate mistakes by verifying the marker bits and fields. Pack headers are especially robust because they have several marker bits which must be set and at least one field (mux rate) which cannot be zero.

Also, it's my understanding that a valid MPEG-2 program stream MUST have a pack header at least every 0.7 seconds. The number of bytes you'd have to search depends on the bitrate, but there should definitely be a finite point where you can declare the stream invalid.

[Guest]

Thanks, fccHandler. I just independently wrote code to check all the marker bits, but I didn't think to check the mux_rate.

So here is RC4. It fixes Teeg's issue and adds the promised -SD CLI option.

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

[fccHandler]

Something else I just remembered... In program streams a pack header must be followed by either a system header or a PES packet. You can verify those too if you want to be really robust. :)

[Guest]

Did you go that far? Of course, I am very partial to robust coding. :)

[fccHandler]

Not quite that far. And I think I set my search limit at 200 KB, and only because I once encountered a video file (on a commercial CD) that had like, 150+ KB of junk at the beginning. Nothing I had could open it at the time, but I was convinced it had an MPEG inside and I eventually proved it with VirtualDub-MPEG2.

As I recall, you were supposed to install some stupid player software on the CD, which I wasn't keen to do. It was an M2M CD, BTW...

[iNFO-DVD]

I added DGIndex to avi.NET, changed some stuff in my program because of the update and done some testing.....

I am very very happy :)

Rather than use the -SD=! as a "!" can be used in a filename/path I tried -SD=* and have got to say it worked a treat, really pleased, now I can use any path/filename via the CLI.

Thanks Don, I know it probably seemed a trivial request at first but I know it was for the best ;)

Thanks again

[Guest]

That really surprises me, because I thought the DOS shell would try to perform globbing on * characters. I'll try that tonight just for grins.

EDIT: I just googled around and found that it is the DOS commands themselves that process the wildcard characters, and not the shell itself! So your approach should be fine, as long as you don't use a 3rd party shell that does globbing.

[iNFO-DVD]

I've just tried everyone..... * < > : \ / ? | they all work :)

[Cyberia]

How is it possible that < > and | work? These should be shell-interpreted.

[iNFO-DVD]

Well without looking into it and having a quick guess I wonder if it has anything to do with the fact I'm not calling a dos/console app but just passing parameters to a windows GUI program?

[iNFO-DVD]

Infact Don, you could probably drop the -SD completely as quotes works fine. Just tried, SD="

example:

-SD=" -AIF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB" -OF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB.TEMP\GO_01_PGC_01_1" -Exit

No problems at all

[Teegedeck]

@Donald: If only I knew. I've found it on my constant quest for high-quality trailers in MPEG-2 format some 4 months back...

[Leak]

How is it possible that < > and | work? These should be shell-interpreted.

They are, but if you execute an .exe-file using the appropriate system calls you're not even getting near a shell; those are interpreted by the/a shell before using the same system calls...

np: Stewart Walker - Sprites (Grounded In Existence)

[Leak]

Infact Don, you could probably drop the -SD completely as quotes works fine. Just tried, SD="

example:

-SD=" -AIF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB" -OF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB.TEMP\GO_01_PGC_01_1" -Exit

No problems at all

Yeah, AFAIK the command line gets passed exactly as it is to the newly started process. You can get it using the GetCommandLine() function.

np: Stewart Walker - Chimera (Grounded In Existence)

[Guest]

Infact Don, you could probably drop the -SD completely as quotes works fine. Just tried, SD="
What about people that write DOS batch files?

I think I'll just leave it as is now.

[iNFO-DVD]

got ya, well I'm happy with it, works fine for what I want to do, cheers again.

[jang0]

What about people that write DOS batch files?

I think I'll just leave it as is now.

I just tried in a DOS command shell sth. like:

lame.exe --alt-preset 128 "C:\Path with Spaces\test.wav" and it worked. So there must be a way. Without qoutes it doesn't work, then it says: Could not find "C:\Path".
Just as a little hint. (and I think that's how most CLI programs handle file paths in (Win)DO(w)S)

[Guest]

@jang0

lame.exe does not receive the quotes in its argument string; DOS strips them. We want DGIndex to receive the delimiter character. If it was simply the case that we wanted to be able to pass spaces in filenames, it would be easy as you say.

[Leak]

@jang0

lame.exe does not receive the quotes in its argument string; DOS strips them. We want DGIndex to receive the delimiter character. If it was simply the case that we wanted to be able to pass spaces in filenames, it would be easy as you say.

And there I was thinking all the fuzz here was about being able to pass a filename with spaces to DGIndex... :confused:

Or, in other words - what do you need the delimiter characters for if you know the whole next parameter is a complete filename?

If this is about the comma separated list of file names - how about doing it like loads of GNU software does it?

DGIndex -IF "path to\file1" -IF "path to\file2" -IF "yet another\path to\file3"

etc.?

np: MC Frontalot - Which MC Was That? (demo)

[Guest]

We have a working solution and compatibility with existing tools. I'm not interested in spending any more time on it, nor do I think it is worth it.

[stax76]

We have a working solution and compatibility with existing tools

compatibility shouldn't be the problem, pseudo code:


if commandline contains "-SD=" or
commandline contains "-IF=" or
commandline contains "-BF=" or
commandline contains and so on then

use old syntax and parser
else
use new syntax and parser

[PetraPan]

hi there, might be a silly question, but if i demux a vob file that was ripped of in ifo mode with decrypter, the generated stream information file shows me audio delay of -80, but the filename of the demuxed audio shows 0 ms, so what is the correct value? is this stream delayed, yes or no? would be nice if somebody can help me out here, so that i can encode this audio with proper delay in besweet.

cheers :)

[Trahald]

imo i think you should go with dgindex' value. DD can sometimes be wrong. (i am assuming the 0ms delay was from dgindex.)
Oh..and welcome to the forum.

[Moitah]

Not quite that far. And I think I set my search limit at 200 KB, and only because I once encountered a video file (on a commercial CD) that had like, 150+ KB of junk at the beginning. Nothing I had could open it at the time, but I was convinced it had an MPEG inside and I eventually proved it with VirtualDub-MPEG2.

As I recall, you were supposed to install some stupid player software on the CD, which I wasn't keen to do. It was an M2M CD, BTW...
You're talking about the video on Shades Of Purple? Hmm, DGIndex has problems with that:

http://www.moitah.net/misc/m2msopmpg.png

VLC/Windows Media Player play it fine, but other software has trouble. Just a weird file I guess, but I will upload it if anyone wants.

EDIT: Screenshot is from 1.4.0RC4

[Guest]

You know I'm going you to ask you to upload it, so why waste time asking me? :)

OK, here we go. Please upload it to my FTP server and tell the file name here. Thank you.

[Moitah]

You know I'm going you to ask you to upload it, so why waste time asking me? :)

OK, here we go. Please upload it to my FTP server and tell the file name here. Thank you.
:)

Okay, it's up: m2msophcd001.mpg

[Guest]

Muchos gracias!

I will inspect it right now.

[Guest]

I like the popcorn explosion. And the chicks are hot.

OK, so this one had 2.2 MBytes of garbage before the first pack header. What if the next one has 20 MBytes? 200 MBytes? Where are you getting these things?

I have to think about this.

EDIT: She sounds like Britney.

[Cyberia]

Don, create a small dialog with some kind of progress bar (or maybe just a label saying "Scanning for Pack Header...."), and a Cancel button.

Then you can scan the whole file for the pack header, and users know DGIndex isn't locked up, and they can abort if desired.

[Seed]

OK, so this one had 2.2 MBytes of garbage before the first pack header. What if the next one has 20 MBytes? 200 MBytes? Where are you getting these things?

Just a quick thought. How about an "Extended Option" mode in "File Open" menu (like in Virtualdub), where an option "scan aggressively for first pack header" where DGIndex will scan even the whole file (or an user specified Mbytes) looking for first pack header.

In the default setting, DGIndex scans only the first 200 Kbytes. If it fails to find first pack header, a pop-up box will tell the user something like "File unrecognised. You may want to try open it with Extended Option".

Edit: Cyberia posted while I wrote. A progress bar is nice.

[fccHandler]

m2msophcd001.mpg
That's the one! I don't remember it having 2.2 MBytes of junk, but it was quite a while back. I dug up my old CD of this, and in fact the current VirtualDub-MPEG2 won't open it. You would have to raise the SEARCH_SYSTEM_LIMIT #define and recompile.

Now it's all coming back to me. Interesting that they gave the file an .mpg extension. And yes the chicks are hot, but better than Britney IMHO. :D


EDIT: VLC/Windows Media Player play it fine, but other software has trouble.
Hmm, I almost overlooked this statement. I don't have VLC installed, and on my computer WMP6.4 and WMP10 won't play it. (Indeed, NOTHING I have right now will play it.)

[Moitah]

Hmm, I almost overlooked this statement. I don't have VLC installed, and on my computer WMP6.4 and WMP10 won't play it. (Indeed, NOTHING I have right now will play it.)
I think it's because I see a filter called "Ulead MPEG Splitter" being used. When I use the overrides in MPC to disable that, other MPEGs play fine but not this one.

[SeeMoreDigital]

You guys might be interested to know that after running the "m2msophcd001.mpg" clip thru' VCDGear (using it's mpeg -> mpeg setting), it's possible to generate a fully working (and in sync) file. That in-turn, can be recognised by all your media players and DGIndex again :D


Cheers

[dlight]

When I demux and try to load into VDubMod I get the error "Old or Obsolete D2V file". I tried to fix the D2V file but DGIndex says that there are no errors.

[dlight]

You guys might be interested to know that after running the "m2msophcd001.mpg" clip thru' VCDGear (using it's mpeg -> mpeg setting), it's possible to generate a fully working (and in sync) file. That in-turn, can be recognised by all your media players and DGIndex again :D


Cheers

I am not sure what you mean can you elaborate? Let me elaborate. Does this only concern this particular file or have you discovered a method of resyncing bad files?

[Guest]

When I demux and try to load into VDubMod I get the error "Old or Obsolete D2V file". I tried to fix the D2V file but DGIndex says that there are no errors. I don't know what you are doing so I'll guess.

You cannot load DGIndex D2V files directly in VDM. You have to serve the D2V through an Avisynth script using DGDecode. If you are in fact doing that and you still get the error, then be sure that you are using matched versions of DGIndex and DGDecode, and that the D2V file is generated with the correct version of DGIndex. You can't always load D2Vs created with earlier versions of DGIndex, because the D2V file format sometimes changes.

[dlight]

I don't know what you are doing so I'll guess.

You cannot load DGIndex D2V files directly in VDM. You have to serve the D2V through an Avisynth script using DGDecode. If you are in fact doing that and you still get the error, then be sure that you are using matched versions of DGIndex and DGDecode, and that the D2V file is generated with the correct version of DGIndex. You can't always load D2Vs created with earlier versions of DGIndex, because the D2V file format sometimes changes.

I am loading the avs script. The versions of DGIndex and DGDecode are the ones in the most recent RC4 set so that shouldn't be an issue. I'll try demuxing again and see what happens.

[Guest]

I am loading the avs script. The versions of DGIndex and DGDecode are the ones in the most recent RC4 set so that shouldn't be an issue. I'll try demuxing again and see what happens. Sometimes you pick up an unexpected version of DGDecode, for example, from your Avisynth plugins directory. Use the info=1 option of DGDecode to display the version number and verify that it is the one you think it is.

[calinb]

I cannot use dgindex to re-open a project file, previously saved with the same version of dgindex (currently using RC4). This functionality was lost sometime within the last few revs. :( The d2v file works fine with dgdecode.dll, GKnot, etc. Source is an mpeg2 transport stream.

Sorry if this is a known bug (or change in behavior). I seached this thread but don't have time to search any further right now. :)

[Guest]

I cannot use dgindex to re-open a project file Load project is not restoring the PIDs. I will fix it. Thank you for pointing it out.

[calinb]

Thanks, Donald! Your work is much appreciated and I love the new features.

[Guest]

Here is RC5. The changes versus RC4 are as follows:

* Legacy audio conversion functionality was removed as discussed here: http://forum.doom9.org/showthread.php?t=96524.

* LPCM support was improved: 1) 48K/96K, 16bit/24bit, and mono/stereo are now supported. 2) The format info is included in the filename and the info dialog. 3) Demux Track and Demux All now work for LPCM (no special handling).

* The D2V format version is now checked when loading a D2V file.

* IDCT support was fixed: 1) The IDCT algorithm specified in the INI or D2V file is now not automatically promoted (e.g., previously if you had IDCT=1 in the INI file and then started DGIndex, you'd end up with IDCT=3). However, the IDCT is scaled down if it is not supported by the processor. 2) A bug in DGDecode was fixed that caused SSEMMX to be used when SSE2MMX was requested. 3) The IDCT algorithm is now consistently numbered between the CLI, D2V, etc.

* Fixed setup of PIDs when loading a D2V file (fixes calinb's issue).

* Increased the parse depth for a first pack header to 2,500,000 bytes and added additional emulation protection (fixes Moitah's weird popcorn explosion MPEG1 stream).

* Added audio processing to the Quick Start guide.

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

I hope this can go final soon. :)

[Cyberia]

Don, the IDCT menu item only displays the supported IDCT types, so why would it fall back if the type was unsupported?

Do you mean, in case someone edits the INI or D2V and designates a unsupported value there, then we fall back?

[Guest]

Do you mean, in case someone edits the INI or D2V and designates a unsupported value there, then we fall back? Yes, exactly.

[iNFO-DVD]

I apologise if this shouldn't really be posted here :confused:

I've noticed in this post and other posts when people have a problem with a VOB or MPG file a clip/sample is needed. I know there's programs to already do it but I was bored so quickly knocked this up.

It's really simple, just load in the file and tell it how much MB you want to take out to a seperate clip. Simple as that and it's only 36K.

Nothing is changed in the file/sample, just copied exactly as was in the original.

SampleSlice.NET (http://www.clonead.pwp.blueyonder.co.uk/aviprogram/SampleSlice.NET.zip)

[LigH]

* Increased the parse depth for a first pack header to 2,500,000 bytes and added additional emulation protection (fixes Moitah's weird popcorn explosion MPEG1 stream).
Might this be a reason that a member in the german board reported DGIndex taking a remarkable amount of time (> 30 s) to open an MPEG2 ES demuxed by ProjectX (so I'd guess it once was DVB)?

http://forum.gleitz.info/showthread.php?p=210026#post210026

I'll ask him to add more details here, if required.
__

@ iNFO-DVD:

:thanks: I'll post this tool in the german board for you, if you don't mind.

[iNFO-DVD]

Fine, no probs, go ahead.

[Guest]

Might this be a reason that a member in the german board reported DGIndex taking a remarkable amount of time (> 30 s) to open an MPEG2 ES demuxed by ProjectX (so I'd guess it once was DVB)?

http://forum.gleitz.info/showthread.php?p=210026#post210026

I'll ask him to add more details here, if required.
It's doubtful, but you never know. 30 sec to read 2.5Meg?

If he would like to make the stream available I'll be happy to have a look at it. I can't help directy because the link you gave is German and I'm monolingual.

[LigH]

akapuma sometimes posts here, too. I think he may use rapidshare for a "cutlet". ;)

[akapuma]

Hello,

here is the small part, announced by LigH.

The way of this part:

- recording with the technisat SkyStar2-DVB-Card and the Software DVBViewer 3.1 PRO (TS-format)
- error fixing and demuxing with ProjectX, converting to m2v (and mpa)
- cutting with MPEG2Schnitt

I need approx 30s to open this file with DGIndex 1.4.0 RC4 and RC5. RC3 and before: less then 1 second. Without cutting with MPEG2Schnitt, the problem is the same.

I hope, the attatchment is helpfully.

Best regards

akapuma

http://rapidshare.de/files/2757733/dgtest.m2v.html

[Leak]

I need approx 30s to open this file with DGIndex 1.4.0 RC4 and RC5. RC3 and before: less then 1 second. Without cutting with MPEG2Schnitt, the problem is the same.

If this already happened with RC4 it's probably not related to the parsing depth change in RC5...

Just my 0.02 €.

np: Pole - Stadt (2)

[LigH]

You are probably right... but I didn't find many changes described in detail from RC3 to RC4, except "fix for Teegedecks problem". Here, only DG will know exactly what was changed to fix this.

[Guest]

I need approx 30s to open this file with DGIndex 1.4.0 RC4 and RC5. It takes about 2 seconds on my machine with RC5.

I can't think of a possible cause right now. Is it that way with all your elementary streams? Are you loading off a hard disk?

[akapuma]

Hello,

I tested my testfile again with new installations of DGIndex:
- DGIndex 1.4.0RC2: less then 1 second
- DGIndex 1.4.0RC3: less then 1 second
- DGIndex 1.4.0RC4: approx 30s
- DGIndex 1.4.0RC5: approx 30s

I tested this whith different streams, the problem is always the same. I loaded the file directly from my harddisk. Additionaly, I tested this with different movies:

- recorded in TS, demuxed, fixed and converted in mpv with ProjectX: long time to open
- recorded in TS with another software (DVBPortal), demuxed, fixed and converted in mpv with ProjectX: long time to open
- recorded in mpg, demuxed, fixed and converted in mpv with ProjectX: long time to open
- recorded in mpg: fast time to open

I have an Athlon 1400 and Windows 98SE.

Best regards

akapuma

[Guest]

OK, people, help me out. Is anyone else getting long load times with the file that akapuma posted a link to?

[LigH]

Duron-800, 256 MB; W2KSP4:

- RC1: immediately
- RC2: immediately
- RC3: immediately
- RC4: 3 seconds
- RC5: 7 seconds

[Pasqui]

@neuron2
It takes about 3 seconds with my Athlon XP 2600+

[LigH]

Duron-800 (same system); W98SE:

- RC1: immediately
- RC2: immediately
- RC3: immediately
- RC4: 16 seconds
- RC5: 29 seconds

[sunbeam]

P4 2.8GH, W2KSP4

- RC1: immediately
- RC2: immediately
- RC3: immediately
- RC4: 5 seconds
- RC5: 10 seconds

same results with all other files handled in the same way akapuma described above.

[Krismen]

RC1: immediately
RC2: immediately
RC3: immediately
RC4: 2 seconds
RC5: 4 seconds

My CPU: AXP1700+, Os: Win XP SP2

[SeeMoreDigital]

P4 2.8GHz with 512MB RAM, WinXP Pro SP2

RC1: Immediately
RC2: Immediately
RC3: Immediately
RC4: Around 6 seconds
RC5: Around 11 seconds


Cheers

[Guest]

Thanks, people.

akapuma, do normal VOBs open fast? I.e., is it only elementary streams that are slow?

If so, I will probably restore the original pack parsing depth and add an extra open option callsed something like "deep open" that would have the longer parse depth for the files with junk at the start.

[LigH]

For me, VOBs always open immediately.

[Trahald]

* Increased the parse depth for a first pack header to 2,500,000 bytes and added additional emulation protection (fixes Moitah's weird popcorn explosion MPEG1 stream).

That helped on some files i had as well. Thank you

[akapuma]

Hello,

some tests with the RC5:

- my testfile:
approx. 30s

- my testfile, muxed with audio to a mpg (with "mplex1 with gui"):
immediately

- VOB's:
immediately

Best regards

akapuma

[iNFO-DVD]

'neuron2'

Can I just get some clarification on the 'WAV' naming convention used....

[AC3]
VTS_01_PGC_01_1 T01 3_2ch 384Kbps DELAY -31ms.ac3
[NAME]-[TRACK]-[CHANNELS]-[BITRATE]-[DELAY]

[MPA]
SVCD T01 DELAY 0ms.mpa
[NAME]-[TRACK]-[DELAY]

[WAV]
VTS_01_PGC_05_1 T01 48K 16bit 2ch.wav
[NAME]-[TRACK]-[BITRATE]-[CHANNELS]

I notice there's no 'DELAY' for wav, is that always like that?
Is that something I need not worry about?

[Guest]

The WAV files should always have 0 delay.

[Cyberia]

Can the WAV naming scheme work more like the other formats? Meaning, add a bitrate and move the channel info forward.

eg: VTS_01_PGC_05_1 T01 48K 16bit 2ch.wav becomes VTS_01_PGC_05_1 T01 2_0ch 384Kbps 48K 16bit.wav

Could you also add a frequency value for the other formats?

:D

[iNFO-DVD]

I was just messing with the MPEG-1 support and did notice something and just wondered why this happens or if it supposed to happen.

The 'Aspect_Ratio' format is usually like this: Aspect_Ratio=4:3,525 (clip was 352x288)
But just done another one and the ratio is like this: Aspect_Ratio=0.6735 (clip was 352x240)

Is it supposed to be using these 2 different formats?

Latest RC5 was used.

[Guest]

Can the WAV naming scheme work more like the other formats? Meaning, add a bitrate and move the channel info forward.
Not worth the bother. Anyway, for uncompressed audio, the bitrate and the sample rate of simple multiples of each other.

[Guest]

Is it supposed to be using these 2 different formats?
Yes, per ISO spec, as discussed earlier in the thread.

[Guest]

Here is RC6. It addresses akapuma's issue with the long open time. It now uses normal parsing depth unless the "Deep Parse" checkbox is checked on the file list dialog. Check it only to open the problematic program streams with a lot of junk before the first pack header.

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

[akapuma]

Here is RC6. It addresses akapuma's issue with the long open time.Thank you, it works fine.

Best regards

akapuma

[fccHandler]

VirtualDub-MPEG2 1.6.8 (http://fcchandler.home.comcast.net/stable) can open the M2M video now. It will automatically do a "deep parse" up to 3 MB if necessary (for M2M), but there should be no additional cost when opening a normal MPEG or m2v. If you're interested, the relevant code is in Mpeg2.cpp, in MPEGFileParser::Verify().

[buzzqw]

[Wrong topic]
I have several problem opening mpeg or m2v with vdubmpeg 168
but will see in other thread

BHH

[Guest]

@fccHandler

I considered something like your solution but I was worried by emulated codes in the junk content and I thought it was not worth the effort. Maybe I'll rethink that if your solution doesn't run into any problems.

Thank you for the new version of VirtualDub MPEG2. I see you have RFF handling now. Cool. Can we hope for "force film" and multiple source file support in a future version? Force film would be desirable because one doesn't have the ability to invoke external Avisynth IVTC filters.

[hartford]

Thanks!

[Guest]

Here is 1.4.0 RC7. It's a hybrid of RC4 and RC6.

* Restored the legacy support for decoding AC3 to WAV.
* Removed "Process WAV".
* Can no longer apply SRC/normalization to LPCM; it just gets demuxed.
* Implemented a scheme similar to fccHandler's to do an automatic "deep parse" for pack headers.

I'd really like to release this one. A couple guys want the source code, and I prefer to release only final code. So please beat on it. Thank you.

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

[scharfis_brain]

There seems to be a weird chroma problem.
Until now I saw it several times with clips that are not 100% Film.
So using Fieldoperation none.

Everytime when the pattern breaks and the vide becomes interlaced for a few frames, the chroma of the even field is swapped to the odd and vice versa.
This creates a horrible chroma-combing when I do an IVTC afterwards.

http://home.arcor.de/scharfis_brain/samples/scottz.mpg

I do not know, whether it is a problem of all of these files, so concluding the encoders are failing (I've several Files showing this very odd behaviour!)
or a problem of the MPEG-Decoders...

[Guest]

Can you please post the full script with IVTC, so I can exactly duplicate the issue?

[Guest]

I served it with Ignore Pulldown Flags and then did assumetff.separatefields. That puts DGDecode pulldown code out of consideration.

Stepping through frames after frame 274, you can see the problem in the source fields.

It's frame structure, so it's highly unlikely that the MPEG2 decoder is doing anything untoward. And the fact that it occurs only when 3:2 sections temporarily stop, even though DGDecode is ignoring pulldown, is suspicious. It just looks like strange source to me.

[ron spencer]

ac-3 to wav is back?

BTW can it do 5.1 to 2.0 WAV?

[scharfis_brain]

@neuron2:
thanks for investigating this.

It just looks like strange source to me.

hmm :rolleyes:
this isn't the only source showing this weird behaviour.
even DEFT NTSC->PAL conversions (IVTC+Speedup)
are showinc this on pattern breaks :(

one of those commonly used IVTC-machines must have a big big chroma problem...

[Guest]

ac-3 to wav is back?

BTW can it do 5.1 to 2.0 WAV? Yes. Yes (if you mean 5.1 AC3).

[mic]

@neuron2:
thanks for investigating this.

It just looks like strange source to me.

hmm :rolleyes:
this isn't the only source showing this weird behaviour.
even DEFT NTSC->PAL conversions (IVTC+Speedup)
are showinc this on pattern breaks :(

one of those commonly used IVTC-machines must have a big big chroma problem...

Some observations, for what it's worth and all...

Downloaded source file (scottz.mpg) and it seems a bit off. Looked at the orig. video in Vegas (2 versions -- 2 decoders) at various fps & frame settings. Used latest DGIndex followed by VFAPI in both Vegas & V/Dub, then AviSynth to V/Dub. Lastly tried a few methods of repair and/or conversion.

To my very untrained eye I'd guess that the downloaded video stream was partially processed (IVT) with mixed (non-consistent) flags that tended to confuse every app I tried. The frame numbers appeared consistent, but the length of the video varied by ~2 sec.. Software I used often wanted to insert frames (3:2), and these varied from black to heavily interlaced to frame doubling to std. animation tweeners.

At any rate, I was just curious with a bit of time to offer... If I'm correct in my guessing, you might be able to repair the headers &/or flags, or you could probably find a combination of settings in your normal workflow that works for you... FWIW, using the original file or ignoring flags in DGIndex, I was able to get what I thought reasonable output in V/Dub or Vegas forcing 23.976 p.

[Guest]

In my experience, the best way to flush out the last bugs is to release the final version. :)

So DGMPGDec 1.4.0 is now released. The changes from RC7 are as follows:

* Fixed a problem that caused failure of AC3 audio demuxing from a
transport stream if the audio stream was not contained in the PAT/PMT
tables.

* Fixed a problem in DGVfapi that caused conversion of AVS scripts to fail
when they delivered RGB32. [fix by 'tritical']

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

The source code is available and a DGIndex Reference Manual by Cyberia and myself will be added shortly.

Thank you to all the contributors to this thread for your extremely valuable suggestions, bug reports, and feedback. Special thanks to tritical for his code contributions, to Cyberia for his moderating, housekeeping on the development list, keeping me honest, and reference manual contributions, and to fccHandler for his VirtualDub MPEG2, which served as a model for the dual MPEG1/MPEG2 support, and for his other helpful analyses and suggestions. Remember that aphorism about standing on the shoulders of giants? In real life, I'm a midget. ;)

I'm ready to crank 1.4.1 when the last bug reports roll in. Please don't disappoint me!

[video_magic]

Thanks a lot for your work Neuron2! :) And to all the others whose work is in this
I'm really starting to get into using it and Avisynth, I really appreciate it.

[Backwoods]

I'm ready to crank 1.4.1 when the last bug reports roll in. Please don't disappoint me!

Do you think 1.4.1 can include "Decode MPA to WAV"? sorry for asking so late but the final release now says "Decode AC3 to WAV" now and it snapped as to why the MPA wasn't being decoded from the start now. For us HDV cam users ya knaws. If not, np there is always BeSweet/Light.

[ron spencer]

hey thanks!!!! over at Videohelp they are calling this a beta in their history notes though...this is final.

thanks!!!

[Guest]

Do you think 1.4.1 can include "Decode MPA to WAV"? I'm surprised you didn't contribute to this thread:

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

I'll never say never, but it's unlikely to rise high on the priority list anytime soon.

[Backwoods]

Ah, I remember that thread when it started but I failed to keep up with it.

That thread talked me into to keep using BeSweet/Light.

[tritical]

I've got one minor bug report, line 256 in vfapidec.cpp... the fscanf format string has a %s where it should have %dx%d. It doesn't make much difference since those values are never used, but it does cause some stack corruption around the integer variables which causes an error when trying to use a debug build.

[Guest]

I've got one minor bug report, line 256 in vfapidec.cpp LOL. It's been like that since at least 1.0.12! Thanks for pointing it out.

[Doom9]

I have a feature request for the commandline if you wouldn't mind: allow the selection of multiple audio track IDs to be demuxed. Right now, it's none, one or everything. I guess one is the most commonly used, but two isn't out of the question either, and if your source has more than two, you end up wasting space for an extracted track you do not need (and if dgindex is run from a third party software, routines have to be written to re-identify the proper files (not that it is much of a problem but it would be nice to get around that from the start)).

[Guest]

@Doom9

Just out of curiosity, how does your program know which tracks to select?

[Doom9]

well.. this currently works only for AC3 (I've asked people to report back to me if they have DVDs with PCM or MP2 tracks.. I don't have such discs to test). I get the track ID from the DVD Decrypter info file. Let's say the user selects the first and second audio track, which have IDs 0x80 and 0x82 respectively. DGIndex turns that into T01 and T03. So, I store the relative ID difference before indexing, then go searching the output folder for T01 and T03 in the filename, and excluding DTS files that might interfere. I guess this could conflict if the source also has PCM and/or MP2 audio, so being able to limit which tracks I want would solve that problem as well.

[gte024h]

I think I found a bug in the "Decode AC3 Track to WAV" function in DGIndex 1.4.0. Sometimes the WAV file is about 2 seconds shorter than the video. Using DGIndex 1.3.0 with the same VOB produces a correct length WAV file. This has happened on 3 different DVD's so I think it's not a problem with the content.

I would post a sample VOB for you to examine, but if I cut a 20mb slice out and post it, the problem will hardly be detectable. For a 2 hour video, audio shrinkage of about 2 seconds is minor but it ruins dialog synchronization.

I understand why you don't want to implement audio decoding in DGIndex (simple tools that do thier job very well, other tools already do it well, etc.) but it is convenient to have AC3 automatically converted to WAV. Perhaps it would be easier to demux the audio track, and if the user selected AC3 to WAV, then have DGIndex run azid (with the appropriate command line flags) to convert the file. It would be as good as doing it manually with BeSweet, but fully automated for us lazy people ;-) Of course it would require that the user have a copy of Azid and that DGIndex knew where it was located.

[Guest]

I just tried it with 1.3.0 and 1.4.0 and the two wave files were identical.

If you are right, even a 20MB sample VOB ought to produce two files that are different in file length. So, please post a VOB and all the DGIndex settings.

[gte024h]

I just ran the demuxed AC3 through Azid and it complained of CRC errors in a couple of spots. I also notice in the DGIndex Info area it says "audio error" when processing the VOB. I suppose that the way audio errors are handled has changed in the most recent version of DGIndex.

If you would still like a sample, I can try to cut a part out of this VOB where the error is. Just let me know and I'll see if I can get a good sample (with errors) online for you.

[Guest]

Yes, I'm interested, because nothing should have changed. You can upload it to my FTP server and inform me of the file name here. Thank you for your trouble report.

[fmonroy]

I just ran the demuxed AC3 through Azid and it complained of CRC errors in a couple of spots. I also notice in the DGIndex Info area it says "audio error" when processing the VOB. I suppose that the way audio errors are handled has changed in the most recent version of DGIndex.

If you would still like a sample, I can try to cut a part out of this VOB where the error is. Just let me know and I'll see if I can get a good sample (with errors) online for you.

check if some scene has multi-angle, i got the same audio error with one of them;if yes just try to rip the correct angle.

hope it helps.

[Cyberia]

I have a feature request for the commandline if you wouldn't mind: allow the selection of multiple audio track IDs to be demuxed.
I tend to agree, this would be a Good Thing. We could eliminate the "Demux All" option and add a "All Tracks" option to the track selection sub-menu. This would give us "Demux" and "Decode" processing options and the track selection would be All, then Tracks 1-8 (allowing multiselect)

Hmmm, worth considering.

Perhaps it would be easier to demux the audio track, and if the user selected AC3 to WAV, then have DGIndex run azid (with the appropriate command line flags) to convert the file.
This was the original idea behind removing the Decoding stuff. Just push the audio directly into BeSweet (or azid since BeSweet will just send it into azid)

The only problem I see with that, is what about all the BeSweet options? We're not going to build a BeSweet GUI into DGIndex. Perhaps DGIndex could Demux and then launch BeSweet. Can the BeSweet GUI be launched with an input/output file already specified?

I'm not even sure this is worth re-addressing. Experienced users are going to use the AC3 directly, or use BeSweet if they need to convert it. The Decoding is there only for users who want an integrated solution, but it certainly is substandard for a 'production' environment.

[ScottZ]

Apologize for asking, but just to confirm... 140rc7 should be working with AviSynth 2.5.6b4?

Thanks

[Wilbert]

AviSynth v2.5.6b4 (and v2.5.6 final when it is ready) will work with all versions of dgdecode. AviSynth v2.5.7 will require dgdecode 1.4.0.

[Guest]

Regarding Doom9's feature request:

Obviously, if that is implemented for the CLI it would be implemented for the menus as well. I have multi track selection working for demuxing; it's not difficult. But decoding is a different matter, because the decoder files in the AC3 directory are implemented using a lot of global variables, meaning supporting multiple decodes is not possible without a big overhaul (which I'm not motivated to undertake).

So, would it still be worthwhile making this change if the decoding has to enforce a single track selection while demuxing has multiple track selection support?

[Doom9]

So, would it still be worthwhile making this change if the decoding has to enforce a single track selection while demuxing has multiple track selection support?Imho yes since the decoding feature is less important than the demuxing feature.. the former is much less used than the latter.

I think pretty much all the programs that automate DGIndex would profit from this change (well, assuming they offer multiple track selection obviously).

[Guest]

@Doom9

OK. Please see the new 1.4.1 beta thread. Thank you for your suggestion.