[RESOLVED] Issue with W64 demux
[RESOLVED] Issue with W64 demux
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?
I usually demux by mpls, not m2ts.
Anybody got same issue?
Re: Issue with W64 demux
Just in time! I was about to release DGDemux and DGIndexNV. Thank you so much. Investigating...
Re: Issue with W64 demux
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?
I think it is related to being mono (1/0). Let's see. Sherman, are you making assumptions again?
Re: Issue with W64 demux
Tomorrow is another day. Never forget that.
Curly Howard
Director of EAC3TO Development
Director of EAC3TO Development
Re: Issue with W64 demux
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!
The logical validity of an argument is a function of its internal consistency, not the truth value of its premises.
Wake up!
- Mr. Peabody
- Posts: 46
- Joined: Tue Dec 24, 2019 9:20 am
Re: Issue with W64 demux
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.
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.
Re: Issue with W64 demux
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.
Re: Issue with W64 demux
I have it working and will make a slipstream after lunch.
Not Sherman's fault!
Not Sherman's fault!
Re: Issue with W64 demux
Here is a test version with all the fixes so far:
MVC support
THD gaps fix
mono LPCM fix
http://rationalqm.us/dgdemux/binaries/DGDemux_test.rar
Feedback will be appreciated as always. DGIndexNV will get the same fix. Hope to slipstream both tomorrow if no issues are found.
MVC support
THD gaps fix
mono LPCM fix
http://rationalqm.us/dgdemux/binaries/DGDemux_test.rar
Feedback will be appreciated as always. DGIndexNV will get the same fix. Hope to slipstream both tomorrow if no issues are found.
Re: Issue with W64 demux
Regarding WAVEFORMATPCM versus WAVEFORMATEXTENSIBLE, does anyone know of an application that cannot play/utilize 24-bit WAVEFORMATPCM? I always prefer simpler code, and why make unnecessary work for no demonstrable gain? Pragmatism!
Re: Issue with W64 demux
I already gave my reasons. Is it working for you?
Re: Issue with W64 demux
Thank you.
AVI is obsolete too. That doesn't mean VirtualDub no longer works.
BTW, La Notte. Great flick! Thank you for drawing it to my attention.
AVI is obsolete too. That doesn't mean VirtualDub no longer works.
BTW, La Notte. Great flick! Thank you for drawing it to my attention.
Re: Issue with W64 demux
La Notte received the Golden Bear at the Berlin International Film Festival (first time for Italian film), as well as the David di Donatello Award for Best Director in 1961. La Notte is considered the central film of a trilogy beginning with L'Avventura (1960) and ending with L'Eclisse (1962). It is one of Stanley Kubrick's 10 favorite films and receives 4 votes from critics and 6 votes from directors in the Sight & Sound greatest films poll. — Wikipedia
Stanley Kubrick's 10 favorite films: http://www.openculture.com/2013/07/stan ... films.html
Re: Issue with W64 demux
Great stuff. Thanks!
Re: Issue with W64 demux
I did extensive research and I found that it doesn't work on some Android builds and some hardware players or A/V receivers of obscure, perhaps audiophile, brands.
As they refer to generic PCM 24 bit, I suppose they won't play any, either WAVEFORMATPCM or EXTENSIBLE.
Abstract: who cares of those :belly-laugh:
Re: Issue with W64 demux
The original spec for WAVEFORMATPCM obviously contains a field for bit depth and it did not constrain that value. People were making 20-bit WAVs with that format well before extensible came along. It is actually WAVEFORMATEX (predecessor of WAVEFORMATEXTENSIBLE) that does not support > 16 bits. WAVEFORMATPCM still does and is supported even though the structure has been superseded by WAVEFORMATEX and WAVEFORMATEXTENSIBLE.