DGIndex demuxing broke some DTS-HD MA streams

[Boulder]

Hi,

I've been processing the Star Trek TOS season 1 Blu-rays and noticed that when I demux all tracks while indexing, three episodes got a broken DTS-HD MA stream. The episodes have a lot of seamless branching as they have a separate angle for CGI enhancements they did on the old TV show.

This is one example which occurs with two episodes, and one episode complained that "libDcaDec output changed from 8 channels, 48kHz to 6 channels, 48kHz."

Code: Select all

eac3to "tos_s01e10.dts" "m:\tos_s01e10.flac" -down16
DTS Master Audio, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 768kbps, 48kHz)
Decoding with libDcaDec DTS Decoder...
Reducing depth from 24 to 16 bits...
Encoding FLAC with libFlac...
Creating file "m:\tos_s01e10.flac"...
libDcaDec reported the error "Invalid bitstream format".
Aborted at file position 686555136.

When I run eac3to directly on the playlist which contains the episode, no issues converting the audio track to FLAC on the fly.

If you'd like to investigate this further, just let me know how I can assist.

[Rocky]

Ordered disk set from Amazon link Boulder sent in PM.

[Rocky]

Disc set arrived from Amazon today. Further data from Boulder in PM:

Episode 10 - disc 3, playlist 00001.mpls, angle 1
eac3to "tos_s01e10.dts" "m:\tos_s01e10.wav" -float32 -normalize causes error:
libDcaDec reported the error "Invalid bitstream format".
Aborted at file position 686555136.

Episode 14 - disc 4, playlist 00001.mpls, angle 1
eac3to "tos_s01e14.dts" "m:\tos_s01e14.wav" -float32 -normalize causes error:
libDcaDec output changed from 8 channels, 48kHz to 6 channels, 48kHz.
Aborted at file position 340525056.

Episode 22 - disc 6, playlist 00001.mpls, angle 1
eac3to "tos_s01e22.dts" "m:\tos_s01e22.wav" -float32 -normalize causes error:
libDcaDec reported the error "Invalid bitstream format".
Aborted at file position 1376780288.

Using eac3to directly on the disc structure (choosing the correct item from the list eac3to gives) to decode the DTS-HD MA track has no issues with these ones. I obtained the demuxed files by just loading the playlist in DGIndexNV64 and saving the project, so I didn't set any cropping or specific tracks to demux.

[Rocky]

I have duplicated this with Episode 10. DGDemux is working correctly but DGIndexNV is not. Investigating the reason for the discrepancy...

[Rocky]

That was an interesting problem. M2TS files have a 4-byte timestamp before the 0x47 sync byte. But that timestamp can contain 0x47 bytes, which can mess up transport sync. So I have code to avoid the false lock. That code just accepts the false sync and looks at the resulting PID. If that is not in the list of known PIDs from the PAT, then that sync is abandoned and the next 0x47 byte is tried. Here's the rub. The stream has transport filler packets with PID 0x1fff. But they are not listed in the PAT so I falsely discard a good sync and the associated packet, which happened to be one of the audio packets. Boom!

DGDemux does not have this issue because it reads 192-byte packets continuously; false sync cannot arise and the check is not required. Remember that DGIndexNV must handle all the transport types, as well as truncated streams and corrupted streams, etc., so it needs the check.

Simple fix is to accept 0x1fff as a known PID. Fix is tested and works fine.

[Boulder]

Good to hear that you found the cause It's always a bit risky with these old releases to buy them (as they may have released another one and reauthored).

In addition to the fix, you also get to enjoy the overacting of William Shatner :belly-laugh:

[Rocky]

Gotta test the other two disks and then I'll slipstream it.

Never was exposed to Star Trek before. Let's see if I can get into it.

EDIT: All three disks working fine with the fix.

[Rocky]

Fixed in slipstream 229.