madshi,
I did some more testing and I figured out why I thought the delay was 24 ms while others said it was 21ms. We're both right. We were just counting differently. I assumed that if you simply calculated the difference in length between the DTS-HD MA --> WAV output and the Source PCM output, you would find the delay, since I assumed it was just added that number of samples of digital silence to the beginning of the track.
In fact, it seems more complicated but the bottom line is that the delay information is contained in the "Codec delay" tag which can be found in the DTS-HD MA header, readable by DTS-HD Streamtools. All BD sourced DTS-HD MA tracks lack this tag, and therefore decode properly with no delay. "Raw" DTS-HD MA files created with MAS have a Codec Delay of 1024 samples. A DTS frame is 512 samples, so the delay is always 2 DTS frames, or 21.33ms (assuming 48 Khz source). eac3to need merely read the DTS-HD MA header to properly decode the track. Unfortunately the Arcsoft DTS decoder does not strip the first 2 DTS frames as instructed by the header. In contrast, DTS Streamplayer does. Thus, eac3to ought to either read the DTS-HD MA header to detect the codec delay, or, if that is not possible, simply strip the first 2 DTS frames from any raw DTS-HD MA track.
I tested this way using eac3to 3.24 - Source (TrueHD) ---> WAVS ---> DTS-HD MA ---> WAVS
I compared the Center channel mono-wavs.
Original Source: 54:09.288 (155965840 samples)
DTS-HD MA --> WAV: 54:09.312 (155966976 samples)
Difference: 1136 Samples / 48,000 Samples/sec = 23.666 ms
I checked the length/# of samples in foobar2000 and Adobe Audition, and they matched. The DTS-HD MA --> WAV track is 23.666 ms longer than the source WAV.
However, when I checked the actual audio delay in Adobe Audition, I found the delay was actually only 21.35 ms.
Attached I have posted an Adobe Audition screenshot with 4 WAVs compared side-by-side. See
Wave 1: Source (TrueHD --> WAVS)
Wave 2: DTS-HD MA --> WAVS with -20ms delay
Wave 3: DTS-HD MA --> WAVS with -21ms delay
Wave 4: DTS-HD MA --> WAVS with -22 ms delay
The closest match is Wave3 (-21ms). However, the -21ms sample still appears to be behind by 0.35ms. I calculated this in two ways. First, I calculated the delay visually and saw that the difference was approximately 10:41.777 seconds - 10:41.77665 seconds, which is 0.00035 seconds, or 3.5 ms. I also counted the number of audio samples within the selection and found 17 (18 appear highlighted, but that's because Audition doesn't allow you to precisely select, and it went a bit too far to the right).
17 samples / 48,000 samples/sec = 0.354 ms
Total Delay = 21.35 ms
Thus, it appears that raw DTS-HD MA tracks encoded with the DTS-HD Master Audio Suite (Version 2.50.20) when decoded in eac3to using the Arcsoft DTS decoder, have an additional 23.66 ms in length, but only have a positive delay of 21.35 ms. I have no idea what is going on with the additional 2.3 ms of samples.
Both jj666 and I were able to replicate the same results using a source THD from the Dexter S04 BDs.
Source ---> WAVS ---> DTS-HD MA (MAS Encoder) ---> WAVS
DTS-HD MA WAVS v. Source WAVS:
Additional 23.66 ms in Length
Positive delay of 21.35 ms (appx)
As a DTS frame is 10.666 ms, it appears we were right that the delay is exactly 2 DTS frames, or 21.33 ms.
But it turns out all this testing was unnecessary. Here's the relevant portion of the DTS-HD MA header:
...
Source Samples : 155965840
Sample Rate : 48000Hz
Samples Per Frame : 512
Codec Delay : 1024
...
In other words, the delay can be calculated simply by reading the DTS-HD MA header, and from what we've seen it should always be exactly 2 DTS frames.
1024 samples / 48,000 samples/sec = 21.33 ms delay
So, all eac3to has to do is to read the DTS-HD MA header. DTS-HD MA tracks sourced from Blu-Rays do not have a "Codec Delay" tag in the header, and thus are decoded properly. In contrast, raw DTS-HD MA files produced with MAS do have such a header, and appear to always add a delay of 1024 PCM samples/2 DTS frames. The DTS Streamplayer reads the header and outputs accordingly. Arcsoft does not head the delay info, explaining the 21.33 ms delay in eac3to.