Support forum for DG Tools

Would you kill your own child for being ugly?

It would be an interim measure. If a user reports an issue with fast mode we can have them try slow. The result could help in identifying the cause (sounds weak, I know). All shortcuts to victory are kosher (sounds goofy, I know). At some point the poor ugly baby must be euthanized (sounds cruel, I know). The poor thing had a beautiful life but when your time comes...

Probably going to ditch the garbage stripping option. It's a PITA, Sherman says it's buggy in slow mode anyway, and a demuxer should faithfully demux the disk. Finally I have seen only one disk that would need it and nobody is clamoring for this feature.

Speak now or forever hold your peace.

I wasn't even sure what the option did, had to look it up

Here is a release candidate for the fast mode:

* Remove garbage stripping option.

* -fast is replaced by -slow, so fast mode is now the default. You can get slow mode by issuing the option -slow directly to DGDemux, or by holding down left SHIFT when hitting the Demux button in the GUI.

http://rationalqm.us/dgdemux/binaries/D ... t_test.rar

Rocky, thanks. I'm so excited!

Did some testing with the RC
Looks good

Beat it to death, then turn it over, and beat the other side to death.

"Don't let them say, I wasn't born
That something stopped my heart
I felt each tender squeeze you gave
I've loved you from the start.
Although my body you can't hold,
It doesn't mean I'm gone.
This world was worthy, not, of me
God chose that I move on."

Rocky, this really helped me:

https://www.youtube.com/watch?v=8L96yaa0pes

Somebody help me! Remember that? C'mon c'mon.

Kisses,
Brit

DG tools need a -slow option. Got it, everyone?

Don't rub it in, Nattie. Are you still busy tonight? Give a little, get a little. Right?

Hey there! Long time no see. I found a little glitch

Are you kidding me? Blame it on Sherman. He needs pulling down a peg or two. Will slip a fix into 45 right away.

Thanks and so great to see you, redbtn.

EDIT: All fixed.

Sorry, Rocky. I'm just a kid.

Don't worry, Sherm, you're good and we love you. Just remember that quality control and the last 5% is the key to a successful development. When you release code under the DG imprimatur, it has to be rock solid.

When are you and Peabody gonna rescue DG from the past? We've been waiting a long time. Get 'er done!

I was scared to tell you, Bullwinkle. DG is stuck in the future. We don't know how it happened on a routine Wayback journey, and we don't have any ideas about how to get him back. So sorry.

Sherman murdered DG.

It was an accident!

Hope I am not out-of-line in saying that what Sherman has done with the DGDemux performance enhancement is really quite remarkable, and he is to be highly commended for it. He and I are working together to modify the Wayback Machine to support trips to the future. One would expect the time symmetry of deterministic reality to allow this. We anticipate bringing DG back very soon.

Is the comment from mlp project still correct regarding truehd frame :

DGDemux deletes a minor frame at every segment boundary, which is better still, but not perfect yet

source : https://github.com/domyd/mlp

Correct. Read the thread here if you are interested in the details.

but not perfect yet

The audio and video frames/samples have different duration.
Perfection is an illusion in this case.
You have to consider time usage, coding complexity etc
How sensitive are your ears?

Can anyone detect a 10ms desync with eyes and ears?
And don't forget that the playback chain can also introduce a couple of millisec into it
AVR>Video>TV
AVR>Audio>Amp>Speakers

Then you have the speed of light vs speed of sound

I ran both algorithms on MONSTERS_UNIVERSITY and found a 5ms difference in total duration. DGDemux is deleting more frames because it does not attempt to compare the audio frames to see actual duplicates. However, claiming that MLP is perfect is simply not true. Actually, it uses a statistical test involving covariance to compare the frames, which seems strange to me. There is an arbitrary threshold (95%) for covariance. Also, when there is silence at a gap, frame comparison is abandoned. And how good is the test for silence? So my point is that MLP also cannot be considered perfect or definitive. Is it better? Perhaps, perhaps not. It's not worth worrying about 5ms. And the DGDemux method is way faster.

If you look at the Issues at the MLP github you'll see that it is not all peaches and cream with MLP. And domy appears to have stopped working on it (src last modified 7 months ago).

Yeah, seems to have an issue matching video and audio length
Not perfect
Oh well, the grass is always greener type of thing