DGMPGDec 1.4.4 Final!

[Guest]

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

DGMPGDec 1.4.4 Final has these changes versus 1.4.3:

1. If a CLI D2V creation is invoked on a transport stream with the wrong pids
specified, when you enter the right PIDs, a bug caused an invalid filename
to be generated for the D2V file (".d2v"). This has been repaired.

2. Audio 48KHz -> 44.1KHz and Normalization have been fixed (they were
badly broken but Pre-Scale Decision was OK).

3. The __src__ AVS template macro was changed to __vid__ and an
__aud__ macro was added. Refer to the DGIndex manual for details.

4. The Audio menu options are enabled/grayed based on the selected audio
output method.

5. AVS script file generation was added to the DGIndex manual.

6. A complete and definitive account of the undocumented audio options was
added to the DGIndex user manual. I hope it may dispel some confusion and
misconceptions.

7. Fixed a bug that stopped AVS script creation when -EXIT was used in the CLI.

8. Added -MINIMIZE and -HIDE options to the CLI.

9. The DGIndex INI file is now always loaded from, and saved to, the same
directory that contains DGIndex.exe.

10. The error message for bad D2V opening has been broken into four to
make it easier to troubleshoot: D2V file is empty, DGIndex/DGDecode
mismatch, cannot open one of the source files listed in the D2V file, and
source stream has no sequence header.

11. Fixed an indexing bug in DGIndex that caused incorrect random frame
access in DGDecode in some rare cases.

12. Fixed a problem that caused stepping backward by GOP in DGIndex to fail
in some cases.

13. Added "m1v" to the open dialog "Files of type" string.

14. Increased from 100 to 500 the maximum number of PIDs that can be
displayed when performing Detect PIDs: Raw.

15. "Decode AC3 to WAV" was totally broken for tracks 2-8 (1 was OK). This
has been repaired.

16. A deficiency in the implementation of pulldown in DGDecode was repaired.
The result is that decoding is now resilient to changes of field order. This
makes Fix D2V superfluous, so it has been removed.

17. The right arrow key can now be used to single step in play/preview mode
if the playback speed is set to Single Step (previously just the right arrow button worked).

18. Colorimetry was reported incorrectly for MPEG2 in some cases. This has been fixed.

19. HOME key is now a synonym for the [ button, and END key is a synonym for the ] button.

[Cyberia]

6. A complete and definitive account of the undocumented audio options was added to the DGIndex user manual. I hope it may dispel some confusion and misconceptions.

Givin away all our secrets, man. shhhhh. :devil:

[mgh]

Thanks for adding the __aud__ micro.

[Zep]

DGMPGDec 1.4.4 beta 1 has these changes versus 1.4.3:

2. Audio 48KHz -> 44.1KHz and Normalization have been fixed (they were
badly broken but Pre-Scale Decision was OK).

wow just how bad were they broken? though I rarely if ever use
48KHz -> 44.1KHz, i did and do use Normalization a lot and i'm very
curious as to what it messed up in those encodes.

if i use projectx then I use besweet to do the audio but many
times i go straight to DGindex when i know the .ts had no drops.

Drops are why i'm stuck using projectx. to fix and sync but it is
slow and one more app/step i would rather avoid using if possible
and why i hope some day DGindex will fix streams then index the
fixed stream etc... then convert to wav with Normalization for editing.

I have to admit it would be nice to be able to edit (even at GOP level)
in DGindex. Then DGindex would only have to fix/index 40 minutes of
the show instead of 60.

yes i realize I may be dreaming the impossible dream (zep breaks out
into song even though he is clearly not julie andrews)

:)

[Guest]

@Zep

Let's not dwell on it. Let's just say that those two audio features were accidentally disabled in my source code [see ThreadKill()]. I assume the executable matches the source code. :)

Cutting and error preprocessing are coming; it's not a dream.

[GZZ]

When will a CLI option to totally hide the application doing D2V creation using commando line be added ?

a commando like "-Hide".

GZZ

[Guest]

@GZZ

That is on the development list but is not a high priority. I did some experiments with it and it is not as easy as it sounds. I can't give you any schedule for its implementation.

[Guest]

@GZZ

Lucky you. I dusted off my previous attempt and seem to have got it working OK, but that's what betas are for -- you tell me. :)

So, here is version 1.4.4 beta 2. It adds the CLI options -minimize and -hide. It also fixes a bug that stopped creation of the Avisynth script when -exit is used.

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

[lineman]

@Zep


Cutting and error preprocessing are coming; it's not a dream.

This is awesome news, thanks for all your great work! ;) ;) ;)

[iradic]

why is the "Output_Method=3" for "Demux all tracks" in ini file (i'm still using 1.4.3 final) - intention or mistake?
and why does dgindex leaves ini file behind (creates one in current dir) when started from other than install dir?

sorry if this have been answered before...

[Guest]

why is the "Output_Method=3" for "Demux all tracks" in ini file (i'm still using 1.4.3 final) - intention or mistake? #define AUDIO_NONE 0
#define AUDIO_DEMUX 1
#define AUDIO_DECODE 2
#define AUDIO_DEMUXALL 3

Do you have a problem with that?

and why does dgindex leaves ini file behind (creates one in current dir) when started from other than install dir? Because it's always been coded that way. Do you have a problem with that?

[iradic]

#define AUDIO_NONE 0
#define AUDIO_DEMUX 1
#define AUDIO_DECODE 2
#define AUDIO_DEMUXALL 3

Do you have a problem with that?


no, no problems :)

but cli is different, can be confusing ...
Output Method
-OM=method
0=None, 1=Demux Tracks, 2=Demux All Tracks, 3=Decode AC3 to WAV

forget i asked about ini file

bye

[Matthew]

Lucky you. I dusted off my previous attempt and seem to have got it working OK, but that's what betas are for -- you tell me. :)

Lovely. Works just fine and dandy for me. Calling it in a dos box, the only quibbles are:
a) It doesn't seem to wait for the project file to be saved. This actually suits what I'm using it for but as a general rule doesn't make sense.
b) The cmd window loses focus.

[Guest]

but cli is different, can be confusing ...
Output Method
-OM=method
0=None, 1=Demux Tracks, 2=Demux All Tracks, 3=Decode AC3 to WAV Oh, I see. I've fixed it in the beta below.

forget i asked about ini file Actually, I think you are right. I have fixed it.

Here is version 1.4.4 beta 3. It has these changes:

* The DGIndex INI file is now always loaded from, and saved to, the same directory that contains DGIndex.exe.

* The error message for bad D2V opening has been broken into four to make it easier to troubleshoot: D2V file is empty, DGIndex/DGDecode mismatch, cannot open one of the source files listed in the D2V file, and source stream has no sequence header.

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

[Zyphon]

Wow! Yet another update of your excellent tool. I wonder Donald, do you ever sleep. :D It's great to see this excellent tool going strength to strength with regular updates.

Great work Donald. :)

[Stereodude]

I have a transport file recorded by my DVico Fusion 5 Gold HDTV tuner card from a Comcast's QAM channel that BBDMUX says has a PAT table in it (@ PID 0x0000), that DGIndex 1.43 says doesn't have a PAT/PMT table in it. 1.44b3 also says the same thing. I'm not sure if you're interested in taking a look at a small 10 second recorded file (~35MB) of this. If you are. Let me know.

BTW, thanks for all the hard work on this very useful tool.

[Guest]

Yes, I am interested. Please upload it to my server ASAP and inform me of the filename.

[Stereodude]

Yes, I am interested. Please upload it to my server ASAP and inform me of the filename.
The file has been uploaded. The name is 2005-09-06(Tue)PM0834-CHD935.tp

[Guest]

That stream has private tables for PMT, for which I don't know the semantics. Does BBDMUX actually decode the PAT/PMT and give you the program number-pid pairs, or does it just tell you a PAT is present as a stream?

My parser reports only the first 100 pids it finds. When I increased it to 500, it found the PAT but then failed to find usable PMTs because they carry the private table id 0x40.

If BBDMUX decodes them I can see how from the source, but first tell me what it can tell you. Thank you.

EDIT: Never mind. I tried it and it just prints the same stuff I do after I increased the maximum number of PIDs. All it tells you is that PAT sections are present. But as I said, they point to PMT sections that are coded with private data tables. Neither BBDMUX nor DGIndex can decode those private tables. Sorry.

[Zep]

@Zep

Let's not dwell on it. Let's just say that those two audio features were accidentally disabled in my source code [see ThreadKill()]. I assume the executable matches the source code. :)


oh :D

good thing i kept using 1.2.1 for so long for encodes huh LOL


@Zep
Cutting and error preprocessing are coming; it's not a dream.

Well i knew it was on your plate but your plate is already so full
and it appears to be a major and complex feature addition(s).

have to admit with those features added DGindex would
be the #1 app I would use by far :)

[Xesdeeni]

That stream has private tables for PMT...Neither BBDMUX nor DGIndex can decode those private tables. Sorry.Wouldn't that also be the case for TVs with QAM tuners? So does he have a non-Fusion backup for complaining to the cable operator?

Xesdeeni

[Stereodude]

I have a TV with a QAM tuner, and it can tune the channels just fine, as can the Fusion 5.

I'll have to record another sample since I've already deleted that one by accident, but it seemed like HDTVtoMPEG2 (1.11.0.51) was able to decode the PAT table, but wasn't set up to look for a few hundred PIDs.

[honai]

@neuron2

I have a problem with Appleseed, NTSC, RC1. (Persists since version DGMPGDec version 1.4.0, so probably no regression bug.)

I open VTS_03_1.VOB to VTS_03_7.VOB in DGIndex, hit "Preview", and the preview window shows a jumping back and forth between different sections of the opening credits. The information panel shows that preview source alternates between VOB Cell Id 1 1 and 2 1. I checked the generated project in Virtualdub (via Avisynth), and the rendered video shows the same behavior.

It seems that DGIndex gets confused by different branches (?) in the opening sequence.

However, Nero Recode behaves correctly, i.e. only one branch is shown and processed.

Any idea?

(Oh, and thanks for such a great tool!)

[Leak]

Any idea?
Rip the movie in File mode using DVD Decrypter, turn on Multiangle Processing and choose an angle (probably the first) you want to keep. Then let DGIndex loose on the newly ripped VOBs.

np: Galoppierende Zuversicht LIVE @ [KONTROL] San Francisco - 18.06. 2005

[honai]

That did the job, thanks!

[Guest]

Version 1.4.4 beta 4:

* Fixed an indexing bug in DGIndex that caused incorrect random frame access in DGDecode in some rare cases.

* Fixed a problem that caused stepping backward by GOP in DGIndex to fail in some cases.

* Added "m1v" to the open dialog "Files of type" string.

* Increased from 100 to 500 the maximum number of PIDs that can be displayed when performing Detect PIDs: Raw.

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

[len0x]

I have noticed that CLI doesn't seem to support loading of D2V projects. I think it would be very handy feature later on when cutting is supported (of even now for those who always cut credits for instance).

[Guest]

Let's get this girl to the prom, because I want to start cutting.

Here is version 1.4.4 RC 1:

* "Decode AC3 to WAV" was totally broken for tracks 2-8 (1 was OK). This
has been repaired.

* Fix D2V is now run automatically and the D2V file is repaired (instead of saving the correct D2V file in *.d2v.fixed). The bad version is saved in *.d2v.bad. See the reference manual for details.

* The right arrow key can now be used to single step in play/preview mode if the playback speed is set to Single Step (previously just the right arrow button worked).

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

[len0x]

Is there a reason for change logs to be in a separate files like this: Changes_xxx.txt instead of just one? There are nine files already and the number keeps growing :)

[Marius-the-Mad]

Hello.

neuron2, I have a problem with colorimetry reports, but at this point, I don't know whether the problem lies in DGDecode or HC Encoder. Please bear with me if I'm knocking on the wrong door. :) I reported a problem to hank315, too, but AFAIK he's taking a few day break from programming after a weekend spent in front of the keyboard and hasn't answered yet.


The problem: DGIndex/DGDecode report I470 in my encodes, but converting the output to RGB with simple ConvertToRGB32() (rec601 is the default colour matrix) results in a bit different colours than in the source. ConvertToRGB32(matrix="rec709") results in colours matching the source perfectly.

As I don't know whether colour matrix is being stored in MPEG 2 stream just like quantisation matrix is, I don't know where the problem can and can not lie. I want to report it in case it were an issue with DGDecode.


Some screenshots illustrating the case:

- the source (I709): http://img291.imageshack.us/my.php?image=sourcei7099iz.png

- DGDecode's report: http://img291.imageshack.us/my.php?image=m2vinfo8tn.png

- ConvertToRGB32(): http://img291.imageshack.us/my.php?image=m2vi4704bo.png

- ConvertToRGB32(matrix="rec709"): http://img387.imageshack.us/my.php?image=m2vi7093zv.png


Screenshot from the source needs a comment. DGDecode reported I470 on the DVD, so I used ColorMatrix(mode="rec.601->rec.709"). At this point, I'm a bit lost in the maze of these conversions and am not sure if my screenshots are helpful at all. But I can upload a short sample of the original VOB, if you want me to.



Also, I found an other, but small problem in DGIndex - the state of the option to log quantisation matrices is not being preserved between sessions. Is it intentional ?


Thank you for the new DGIndex, neuron2. :)

Regards
MTM

[Guest]

@Marius-The-Mad

I'm afraid I don't have time to go trekking into the jungle of color space conversions, etc. DGMPGDec simply reports the value of the colorimetry field as contained in the MPEG stream. Unless you are suggesting that it is being reported wrongly, I simply do not have any time to get involved in that.

Perhaps HC is not recording the colorimetry info in the stream properly.

The log quants option is not stored in the INI file, as documented in the reference manual for DGIndex.

@len0x

I'll consolidate them. Thanks for the suggestion. It stems from having separate changes files for linking at my web site.

[Wilbert]

The problem: DGIndex/DGDecode report I470 in my encodes, but converting the output to RGB with simple ConvertToRGB32() (rec601 is the default colour matrix) results in a bit different colours than in the source.
That should indeed be the same since I470 = Rec.601.

The problem: DGIndex/DGDecode report I470 in my encodes, but converting the output to RGB with simple ConvertToRGB32() (rec601 is the default colour matrix) results in a bit different colours than in the source. ConvertToRGB32(matrix="rec709") results in colours matching the source perfectly.
How did you take a screenshot of the source?

[Marius-the-Mad]

Perhaps HC is not recording the colorimetry info in the stream properly.Perhaps. I'm fully aware this may be the case now, I wasn't sure how this information was being retrieved. I will bug hank315 about, then.




The log quants option is not stored in the INI file, as documented in the reference manual for DGIndex.Ooops... :o I'm sorry, it's definitely there, but I managed to overlook it somehow.




How did you take a screenshot of the source?The path:

DGDecode -> pc_to_tv -> ColorMatrix(mode="rec.601->rec.709") -> some_filters -> ConvertToRGB32(matrix="rec709")

I call it "source" because this is what I feed HC with (excluding YUV->RGB conversion, of course). Somewhere in the chain there is a problem with colours, it seems - I'll ask Hank about it again.


<edit> Specified ColorMatrix() parameters.

[Wilbert]

Please do the following test:

Mpeg2source(...) #I470
ColorMatrix(mode="rec.601->rec.709")
ConvertToRGB32(matrix="rec709")

Open this in VDub and take a screenshot. Next script:

Mpeg2source(...) #I470
ConvertToRGB32()

Open this in VDub and take a screenshot. Are both screenshots identical? If not upload a short vob somewhere.

[Marius-the-Mad]

They are identical. I guess this leaves us with wrong colour matrix written into MPEG 2 stream by HC.

Thank you, Wilbert. I couldn't put together a proper test. It seems so obvious I feel ashamed. :o


Unless I'm mistaken, but I think this time I'm not. :thanks:

[Wilbert]

They are identical. I guess this leaves us with wrong colour matrix written into MPEG 2 stream by HC.
You have to ask hank315 about this, but i think the following happens:

1) The Rec.709 coefficients are written in the header of the MPEG-2 stream when feeding HC with RGB material.

2) The Rec.601 coefficients are used for the RGB->YUV conversion (remember MPEG-2 is stored as YUV) which is done in HC.

The coefficients in (1) and (2) should be the same. If this is not the problem some further testing is needed.

Btw, you can easily circumvent the problem by using ColorMatrix() and feeding hc with YUV material.

edit: clarification

[Marius-the-Mad]

I've been doing it from the start. :) There just seems to be a slight problem in HC, because if DGIndex reported a wrong colour matrix, the test you suggested would result with different looking screenshots, I think.

Thank you very much for all the replies. :thanks:

[hank315]

DGMPGDec simply reports the value of the colorimetry field as contained in the MPEG stream.Have a question about it, how do you detect the colorimetry?
Just did a run with DGIndex 1.4.3 on a HC encoded file and it reported ITU-R BT.470-2, seems strange because HC doesn't write the sequence display extension so I expected the default ITU-R BT.709.
The D2V does have the line "YUVRGB_Scale=1" in it.

[tritical]

Have a question about it, how do you detect the colorimetry?
Just did a run with DGIndex 1.4.3 on a HC encoded file and it reported ITU-R BT.470-2, seems strange because HC doesn't write the sequence display extension so I expected the default ITU-R BT.709. Guessing here, but it is probably because when parsing the sequence header dgindex assumes mpeg1 defaults for a couple values: progressive_sequence, chroma_format, and matrix_coefficients thinking that they will be overridden later if the stream is actually mpeg2. However, if the sequence display extension isn't present then the matrix_coefficients value never gets overridden and it defaults to the mpeg1 default of ITU-R BT.470-2 instead of the mpeg2 default of ITU-R BT.709.

[Guest]

If there is no SDE, it is designed to default to 470 for MPEG1 and 709 for MPEG2. Was your stream MPEG2?

I'll run an experiment with HC tonight.

EDIT: Just saw tritical's post. Yes, it's not getting set right for MPEG2 in absence of SDE. I know it's MPEG2, however, from initial_parse(), so I will fix that.

[Guest]

I have it fixed and could give you a new version, but I have this issue:

http://forum.doom9.org/showthread.php?p=714739#post714739

Do you want to wait for that or should I put out an intermediate version?

EDIT: I have that issue fixed too, so I'll make a release tomorrow.

[Guest]

Here's the fixed version:

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

* A deficiency in the implementation of pulldown in DGDecode was repaired.
The result is that decoding is now resilient to changes of field order. This
makes Fix D2V superfluous, so it has been removed.

* Colorimetry was reported incorrectly for MPEG2 in some cases. This has been fixed.

[mg262]

* ... This makes Fix D2V superfluous, so it has been removed.Brilliant! That eliminates some amount of manual labour. Thank you very much.

[Fotis_Greece]

Hi from Greece, It's a great prog which I use a lot. So far it happened to use it with movies with ac3 audio. I just used it with dts and there seems to be a problem there. The dts bitrate is full 1536 and when demuxed I can't play it with no software. Not either powerdvd plays it and reports it as mpeg 2.0 256 audio and can't hear anything apart from hissing.
Needless to say that I have many dts sounds files in my pc which all play fine.
I trancoded the demuxed dts to 6 mono wav files and reencoded back to dts with bitrate 768. The file plays fine .

I authored the dvd using both dts soundtracks (the demuxed and the reencoed by me) and both audio tracks play fine.
So what is wrong there?

[Guest]

I don't have any DTS audio VOBs. Can you supply a fragment of one that you say fails?

[Fotis_Greece]

"There is a house in New Orleans" Animals sing.
Just a small part of it in dvd, authored by me with the most expensive encoders (dts 1536) and authoring software
test it. It plays fine, but when you demux it you can't hear the dts file

http://www.interchefs.com/club/testdvd.rar

512 kb

If you need longer vobs just tell me

[guada2]

Very good optimization.
Thank you very much Neuron2. ;)

[hank315]

Just did some tests, colorimetry reported OK now, thanks.

[Guest]

If you need longer vobs just tell me What I need is for you to tell me what I need to play DTS files. I tried AC3Filter. Nothing. I tried VLC Player. Nothing. I just get no audio. So, how do I play a DTS file? I have downloaded good DTS files from the internet. I can't make them play.

EDIT: Never mind. Media Player Classic plays them.

@Hank

Thank you.

[Guest]

@Fotis_Greece

Everything works fine for me. I demultiplexed the DTS elementary stream from your VOB using DGIndex 1.4.4 RC2 and the resulting DTS file plays just fine with Media Player Classic 6.4.8.4. This process also works for all the other DTS files that I downloaded.