DGDemux development

[Rocky]

I'll probably have to buy it because I can't duplicate that. I'll compare the code closely to see how a discrepancy like that could happen.

However, I was thinking of getting rid of the DELAY anyway as it should always be 0. Have you ever seen a non-zero value when demuxing slow or with EAC3TO? DGDecNV has to do it because you can set your range such that the project doesn't begin at the start of the first M2TS.

Great to hear DTS and tags are working!

[Guest]

I don't remember seeing any non zero delays in BDs
If it helps these are DTS HD-MA tracks

[Rocky]

OK, thank you. I'll check all my disks and if there are no non-zero delays in slow mode then bye-bye DELAY! Sherman is back in 1935 but I think I can handle it.

[Guest]

One more thing

This time I kept all the audio for comparison
In the slow demux the ac3 are all -8ms delay and the dts is 0 ms
In the fast demux they are listed as -8 ms
Is it possible the fast demux is somehow using the delay for the ac3 files and applying it to the dts files?

[Guest]

I realize that you are considering removing delay reporting but I decided to run some quick tests to try and narrow this down.
My regular demux >> Video + Primary eng audio (DTS HD-MA in this case) + eng subtitles
Delays match between slow and fast

Primary eng audio
Delays match

Demux both DTS HD-MA tracks
Delays match

Demux both DTS HD-MA tracks + any ac3 track
Delays don't match
It is as if the ac3 delay is being copied over

It might just be one of those once in a blue moon things

[Rocky]

OK, thank you. I'll check it out.

[Guest]

Tried 3 more movies with similar dts and ac3 track mixtures
If only dts is demuxed then the delays match
If only ac3 is demuxed then the delays match
If dts and ac3 are both demuxed slow seems to have the correct delays, but in fast demux the dts tracks are assigned the delay values of the ac3 tracks

[Rocky]

Yes, thank you. I'll release a fix tomorrow. Your theory is correct.

[Sherman]

Just popping in to say it's looking possible to get Albert to join the forum. He wants some assurances about not allowing stupid people in here. I said, other than Natasha, should be no problem. And he wants immediate Moose or Britney Approval.

Great job Rocky on the fast mode. Going back down. Wish me luck...

[Bullwinkle]

Stop it, Sherman! You'll make me project from my second stomach. Honorary stomping award coming your way. Bring Albert back with you and you could be Moose Lodge material. Of course he can have whatever approval he wants.

[Rocky]

@gonca

Please re-download the test version. The wrong delay values for DTS should be fixed.

[Sherman]

We're back! Albert is going to make a decision and let me know.

Yeah Bullwinkle, that FixTHDGaps() function is ridiculously slow. Too many small reads and writes. Have to do my own read and write buffering. OS buffering is just not enough because system calls are slow all by themselves. Thanks for pointing it out.

EDIT: I have now fully read/write buffered it and it now fixes a 5GB file in 4 seconds, versus almost a minute with the old version. It's speedy now, like DGSplit. I'll test it and then commit it for integration into the release.

[Rocky]

Way to go Sherm!

It's speedy now, like DGSplit.

Thanks! My ticket out of the Box of Shame.

[Sherman]

I updated the fast mode test build with the FixTHDGaps() speedup (applies to both slow and fast modes), so please re-download and test. If no adverse feedback is received, maybe Rocky will update build 44.

[Guest]

Delays are all good now.
Good job

I'll try to find some movies with seamless branching to test Gaps Processing

[Rocky]

Thank you, gonca!

[Guest]

Just tested two movies
All is good
Must say, after using the fast demux option, using regular demux is like watching a soccer game, or watching paint dry or grass grow

[Rocky]

Great thanks.

Yeah, speedy! Especially if you are on all SSDs.

Probably gonna make fast the default and you hit SHIFT for slow.

[Guest]

If fast is working, why would you need slow?

[Mr. Peabody]

It's a fair question.

[Britney]

Would you kill your own child for being ugly?

[Rocky]

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

[Rocky]

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.

[Guest]

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

[Rocky]

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