[RESOLVED] Issue with W64 demux

Support forum for DGDecNV
User avatar
tormento
Moose Approved
Posts: 321
Joined: Mon Sep 20, 2010 2:18 pm

[RESOLVED] Issue with W64 demux

Post by tormento » Mon Jun 29, 2020 2:24 pm

Sometimes, I could say 50%, I get a w64 of double the time lenght of the original PCM stream, with lower pitch.

I usually demux by mpls, not m2ts.

Anybody got same issue?

User avatar
Rocky
Moose Approved
Posts: 730
Joined: Fri Sep 06, 2019 12:57 pm

Re: Issue with W64 demux

Post by Rocky » Mon Jun 29, 2020 5:11 pm

Just in time! I was about to release DGDemux and DGIndexNV. Thank you so much. Investigating...

User avatar
Rocky
Moose Approved
Posts: 730
Joined: Fri Sep 06, 2019 12:57 pm

Re: Issue with W64 demux

Post by Rocky » Mon Jun 29, 2020 8:45 pm

Ha ha, the PCM track is pretty funny to listen to. Maybe we should leave it that way?

I think it is related to being mono (1/0). Let's see. Sherman, are you making assumptions again?

User avatar
Curly
Moose Approved
Posts: 41
Joined: Sun Mar 15, 2020 11:05 am

Re: Issue with W64 demux

Post by Curly » Mon Jun 29, 2020 8:50 pm

Tomorrow is another day. Never forget that.

User avatar
Natasha
Posts: 45
Joined: Wed Nov 20, 2019 12:11 pm

Re: Issue with W64 demux

Post by Natasha » Mon Jun 29, 2020 8:58 pm

ASS-U-ME

The logical validity of an argument is a function of its internal consistency, not the truth value of its premises.

Wake up!

User avatar
Mr. Peabody
Posts: 13
Joined: Tue Dec 24, 2019 10:20 am

Re: Issue with W64 demux

Post by Mr. Peabody » Mon Jun 29, 2020 9:00 pm

Natasha wrote:
Mon Jun 29, 2020 8:58 pm
The logical validity of an argument is a function of its internal consistency, not the truth value of its premises.
That's insane, or at the least, postmodern.

User avatar
tormento
Moose Approved
Posts: 321
Joined: Mon Sep 20, 2010 2:18 pm

Re: Issue with W64 demux

Post by tormento » Tue Jun 30, 2020 3:04 am

Rocky wrote:
Mon Jun 29, 2020 8:45 pm
Ha ha, your disk's PCM track is pretty funny to listen to. Maybe we should leave it that way?
Helium gives funnier voices :mrgreen:

User avatar
Rocky
Moose Approved
Posts: 730
Joined: Fri Sep 06, 2019 12:57 pm

Re: Issue with W64 demux

Post by Rocky » Tue Jun 30, 2020 10:20 am

Used to do that as a kid at my dad's work picnic when they were filling the balloons.

Here's what's going on with this issue. Two things:

1. EAC3TO uses WAVEFORMATEXTENSIBLE and I use WAVEFORMATPCM. This appears inconsequential. MS guidance is to use extensible format when the sample size is > 16 bits, but my players don't care if it is pcm format. The real problem seems to be that the stream is mono (see next item).

2. The transport stream data has interleaved two channels per sample frame with the second channel always having zeros. EAC3TO removes these when demuxing. What I don't understand is why those extra bytes are there, given that the stream is mono and mono PCM packing is supposed to have only one sample per sample frame. It'll be a pain to remove them but I suppose we have to do it. This explains why the demuxed file is twice as long and plays at half speed. I want to fully understand this before making needed changes.

User avatar
Rocky
Moose Approved
Posts: 730
Joined: Fri Sep 06, 2019 12:57 pm

Re: Issue with W64 demux

Post by Rocky » Tue Jun 30, 2020 10:59 am

OK, all clear now. The bluray spec says there must be >= 2 channels and that for mono, the second channel is discarded. So that's what I'll do when mono is specified. Haven't decided yet if I should worry about the WAVEFORMATPCM.

User avatar
Rocky
Moose Approved
Posts: 730
Joined: Fri Sep 06, 2019 12:57 pm

Re: Issue with W64 demux

Post by Rocky » Tue Jun 30, 2020 11:44 am

I have it working and will make a slipstream after lunch.

Not Sherman's fault!

Post Reply