DTS-HD to LPCM Lossless

[Chewtobacca]

Until the issues with eac3to have been satisfactorily addressed, DGDemux is probably the most reliable tool for extracting DTS-HD tracks from BDs (especially those with seamless branching).  One can decode with ffmpeg later if need be.

EDIT: See below.

[pipefan413]

Embarrassingly, I've since discovered that the point in the chain causing the problems with these files is not actually the decoding but the -21ms trim specifically, so I must presumably have just renamed one file incorrectly waaaay at the start (it was about 4am or something) and not realised until ages later. Absolute nightmare.

However, something is evidently being cut off by the trim for these particular files that is for some reason useful because it's causing inaccurate decoding afterwards. What was originally space between audio (mostly 00 or nearly 00 data) then gets filled with not quite 00 as if the audio had been chucked through a dither which doesn't exclude silence, but all that's been done to it is the trim (-21ms to remove the silence added by the encoder).

Pre-trim: accurate decode
Post-trim: inaccurate decode

Dunno why yet but determined to find out. But long story short, I screwed up during diagnosis and the eac3to decoding appears to be correct.

[Chewtobacca]

Absolute nightmare.

It's less of a nightmare than if you'd been right about the decoding, so that's some consolation. 

So after the 21ms trim, do all the bits that follow remain unchanged?  If so, perhaps it's academic.

Maybe we can release DTS-HD tracks without the adjustment applied, but include a note about the header and how to handle it.  That way, people can definitely recover the original PCM if necessary.

[pipefan413]

Absolute nightmare.

It's less of a nightmare than if you'd been right about the decoding, so that's some consolation. 

So after the 21ms trim, do all the bits that follow remain unchanged?  If so, perhaps it's academic.

Maybe we can release DTS-HD tracks without the adjustment applied, but include a note about the header and how to handle it.  That way, people can definitely recover the original PCM if necessary.

No, the file contents are changed after that too.

It seems to pertain to the gaps between audio in the actual bitstream, so what are 00 or almost 00 in the source end up filled with something else in the encoded-then-trimmed-then-decoded version.

This is odd unless something about the removed data is important to determine something about the data later in the file. But my understanding was that the wee mini "headers" in DTS just give info about the contents of the frame after them (it basically looks to me like each of these can be thought of as a frame marker, as in "this next bit is one frame"). If these files are any indication, though, it may be that these markers contain more data than that, perhaps "the following (number) frames have these attributes", so when the first 2 DTS frames (512 x 2 = 1024 samples) are hacked off the start to fix sync, there's information lost that was needed to accurately decode later frames containing actual audio. Or something to that effect.

[Chewtobacca]

^ That makes sense.

But my understanding was that the wee mini "headers" in DTS just give info about the contents of the frame after them (it basically looks to me like each of these can be thought of as a frame marker, as in "this next bit is one frame").

Until now, that had been my understanding as well. It might be worth loading a freshly encoded stream into tsMuxeR, hitting "demux", and seeing if stripping the header alone (without the eac3to trim) has any effect on how the resulting file decodes -- in other words, separating the processing of the header from the trim.

[pipefan413]

^ That makes sense.

But my understanding was that the wee mini "headers" in DTS just give info about the contents of the frame after them (it basically looks to me like each of these can be thought of as a frame marker, as in "this next bit is one frame").

Until now, that had been my understanding as well. It might be worth loading a freshly encoded stream into tsMuxeR, hitting "demux", and seeing if stripping the header alone (without the eac3to trim) has any effect on how the resulting file decodes -- in other words, separating the processing of the header from the trim.

Great minds etc. Already did yesterday and confirmed only stripping the header and navigation table from end does NOT cause the inaccurate decode. Only when the first 2 frames are hacked off does the problem emerge.

[Chewtobacca]

Interesting. Theoretically, we could strip the header with tsMuxeR and find another way to implement the trim. I know that we both have doubts about the efficacy of applying the delay upon muxing, but it might be worth trying it now that we have a clearer idea of what's going on.

[pipefan413]

Interesting.  Theoretically, we could strip the header with tsMuxeR and find another way to implement the trim.  I know that we both have doubts about the efficacy of applying the delay upon muxing, but it might be worth trying it now that we have a clearer idea of what's going on.

I've already checked that there's definitely nothing any more sophisticated going on in eac3to than literally looking for the third frame marker and deleting everything beforehand, by just directly editing the hex code myself, doing exactly that, then comparing the files. Identical.

Also, doing the delay at muxing stage does the same thing: just deletes those two frames, which in these particular files, causes the inaccuracy upon decoding. So that isn't the solution, sadly. (I did all this yesterday, I just didn't want to post until I had more definitive info.)

I think I might have to experiment with more direct hex editing to figure this out. I've done this before (I made a ROM hack for a SNES game that involved me reverse-engineering the hex code after a crapload of research into exactly how the SNES reads code and so on) but I've not researched exactly how this part of DTS works yet so it's not going to necessarily be straightforward and may prove to be effectively impossible depending on what info is actually available. Especially since it would appear that even the devs who made eac3to, MKVToolNix etc. apparently haven't come across a file where this happens, since the implementation just does it as I've described.

I'm kinda hoping that it's only files with some inherent problem that will face this issue, and indeed these particular files were not made by me (I did the DTS encoding but the files I fed to it were resyncs by someone else who is openly not that experienced with editing audio, but they're a million miles ahead of me on the video side). One of them for example was 16-bit at source but appears to have been edited at 32-bit then truncated to 24 such that most of the file remains 16-bit but some is 24-bit (the bits that were edited during resync, presumably). If *both* files had variable bit depths then I'd assume that was the issue here, since presumably the first 2 frames of silence added by the DTS encoder are 24-bit but the next few are 16-bit, so maybe something that's deleted when removing those 2 frames could have been an instruction like "change to 16-bit after this frame" or similar. But that should not be true of the other file, which is ostensibly 24-bit throughout (and indeed eac3to seems to think so). But I spent yesterday focusing on the 16-/24-bit variable one and haven't yet dug into the one that should theoretically be consistently 24-bit, so that's what I want to do next.

[Chewtobacca]

One workaround might be to remove 21ms from the beginning of a synced track, encode with the suite, demux the output with tsMuxeR to strip the header, and leave it at that.

[pipefan413]

One workaround might be to remove 21ms from the beginning of a synced track, encode with the suite, demux the output with tsMuxeR to strip the header, and leave it at that.

Aye, that's exactly what I'm probably going to do in the short term for these particular problem files however I also want to understand what's going on here.

I'm going to attempt to reverse-engineer the hex code to understand what the frame headers in the DCA codec contain and therefore what is being deleted here that's actually needed to decode the later frames properly. There's already some info online about it that'll definitely help. I'm about to have a busy few days though (and in between times I also want to work on things like the Streets of Fire LD sync and T2 French BD sync etc.) so I dunno how long it'll take me to do all this stuff. I don't want to just work around the problem and leave it though, because for me the real joy of this is learning how the stuff is actually put together!

I should probably post my breakdown of the DTS-HD header stuff as well, I want to go back to that and pick apart the navigation table as well. But that's less urgent since it has no real practical use for me any time soon (the nav tbl isn't used my free software at all anyway).