96/24 data in dts extension field lost after demux

[omega6666]

I have a question about demuxed dts streams and the preservation of the data in the extension field. The data in this extension field is normally used for 6.1 discrete or 96/24. I've recently obtained some demuxed dts tracks, of which some are recognised by DTS Parser (http://www.softpedia.com/progDownload/DTS-Parser-Download-80430.html) as being 96/24, but some are recognised as 48/24.

Since they're demuxed by different people, I couldn't know if the demux was done in a way that ignored the extension data, and only copied the core data (thus downgrading the source), or that the extension data was copied along properly during the demux. I know all the originals were 96/24 dts streams! The reason I'm not sure if the 48/24 ones have actually really lost the extension data, is because with PgcEdit you can simply change the domain stream attributes. In other words; it just a flag that says if it's 96/24 or 48/24, so it could well be that the extension data is still there, but the dts is flagged as being 48/24, right?

So my question is; how can I really check if there is still data in the dts extension field? I read this somewhere;

"In the DTS Stream look for the sync bytes 1D95F262 for the 96 khz extension. It will be present in every frame there is 96 khz data in. The data is basically the 'missing' frequencies above 48khz. Which are mixed back into the pcm data as needed.

Also FYI the sync bytes for the extension channels - 6 and above - are 5a5a5a5a.
If both are present then the 96 extension is always first, then the xtra channels."

With what program can I look for these sync bytes, or are they simply the representation of the 96/24 flag?

[ACrowley]

With what program can I look for these sync bytes, or are they simply the representation of the 96/24 flag?

tebasunas LeeAudBi

[omega6666]

Thx for the advice, but I can't find a (working) link for that program anywhere...

I did a test recently, by flagging a 48/24 dts track as a 96/24 one. My receiver showed me it was a 48/24 one nonetheless. I guess this means my dts track is actually missing the extension data. :( The strange thing is that I've also got a complete backup of the original dvd, and even that one was 48/24.
Is it possible that there are DVD backup programs that remove extension data in the process? I find it more logical that that would happen with demux software somehow.

[Coolpplse]

Thx for the advice, but I can't find a (working) link for that program anywhere...

I did a test recently, by flagging a 48/24 dts track as a 96/24 one. My receiver showed me it was a 48/24 one nonetheless. I guess this means my dts track is actually missing the extension data. :( The strange thing is that I've also got a complete backup of the original dvd, and even that one was 48/24.
Is it possible that there are DVD backup programs that remove extension data in the process? I find it more logical that that would happen with demux software somehow.
I dont think that could possibly happen with DTS, simply cause of how DTS was originally stuck with 1.5mbps, so even the very first dvd players that could recognize DTS would not drop the extension data in any form if it could not be decoded.

[omega6666]

I've learned that changing the domain stream attributes of the problem dts files to 24 bits and 96 khz with PgcEdit won't really change the Channel Extension flag, according to tebasuna51's LeeAudiBi. Check this (http://forum.doom9.org/showthread.php?p=1061945#post1061945) thread...
Does anyone know how to change that flag properly?

[tebasuna51]

From document ETSI TS 102 114 (http://webapp.etsi.org/action/PU/20020827/ts_102114v010101p.pdf) pages 14-15:

"Extension Audio Descriptor Flag ACC EXT_AUDIO_ID 3 bits
This flag has meaning only if the EXT_AUDIO = 1 and then it indicates the type of data that has been placed in the extension stream(s):

0 Channel Extension (XCh)
2 Frequency Extension (X96k)
3 XCh and X96k

Extended Coding Flag ACC EXT_AUDIO 1 bit
It indicates if extended audio coding data are present after the core audio data. Extended audio data will include the data for the extended bands of the 5 normal primary channels as well as all bands of additional audio channels. To simplify the process of implementing a 5.1 ch/48 kHz decoder, the extended coding data arrays are placed at the end of the core audio array."

Page 18:

"Channel Extension Sync Word V XChSYNC 32 bits
The synchronization word XChSYNC = 0x5a5a5a5a for the channel extension audio comes after all other extension streams i.e. in case of multiple extension streams the XCh stream is always the last."

Page 21:

"96 kHz Extension Sync Word SYNC96 V 32 bits
The synchronization word SYNC96 = 0x1D95F262 for the 96 kHz extension data comes after the core audio data. Note that if a channel extension is present the X96k extension data is placed before the XCh extension data in the encoded bit stream."

With your sample 96_24:

Primary Frame Byte Size .....: 2012 ( 2013 bytes/frame)
Extension Audio Descr. Flag .: 2 (Frequency Extension X96k)
Extended Coding Flag ........: 1 (Yes)

Using HxD (http://www.mh-nexus.de/) (or any other hexadecimal editor like WinHex etc.) I found the sync bytes 1D95F262, for the X96k, at 1768 offset in first frame, 3781 in second frame and so on.

With your sample 48_24:

Extension Audio Descr. Flag .: 0 (Channel Extension XCh)
Extended Coding Flag ........: 0 (None)

Using HxD I don't found the sync bytes 1D95F262 for X96k Extension (or 5a5a5a5a for XCh)

I think the flags are coherent with the present frame info.

[omega6666]

Thanks for diving into this. So you think that the copy process only copied the core data of the original? :(

With your sample 48_24:

Extension Audio Descr. Flag .: 0 (Channel Extension XCh)
Extended Coding Flag ........: 0 (None)

Using HxD I don't found the sync bytes 1D95F262 for X96k Extension (or 5a5a5a5a for XCh)

I think the flags are coherent with the present frame info.
So those sync bytes aren't just a representation of the flag? In other words; if you could somehow change the ext. coding flag to 1, and the extension audio descr. flag to 2, there still won't be found any 1D95F262 sync bytes?

When I check the 96_24 sample for extension data with HxD, I noticed this repetition;
1D 95 F2 62....
then a bunch of 00 00 00 00's...
then a small data block....
then a bunch of FF FF FF FF's...
then another small data block....
then a bunch of 00 00 00 00's...
then a large data block...

Are those small data blocks the extension data (or maybe only the first one?), and is the large data block the core data? In the 48_24 sample the 1st small data block is almost non existent. Does this mean that dts files with extension data are a bit larger than dts files without it?

Thanks for the help. I'm surprised to see how few people there are that really know about DTS encoding, and there's not much to be found about it on the internet. So also thanks for your PDF document...

[tebasuna51]

So you think that the copy process only copied the core data of the original?
Maybe a copy process involving the W. Vista restrictions about quality? Really I don't know.
So those sync bytes aren't just a representation of the flag? In other words; if you could somehow change the ext. coding flag to 1, and the extension audio descr. flag to 2, there still won't be found any 1D95F262 sync bytes?
The flag only say to the decoder for search the extended info, if the info don't exist ...

Are those small data blocks the extension data (or maybe only the first one?), and is the large data block the core data? In the 48_24 sample the 1st small data block is almost non existent.
In the 96_24 sample the frame is 2013 bytes long, the first 1768 are the core data and the rest (245 bytes) is the X96k extended data (XCh don't exist).
In the 48_24 all the frame is core data.

Does this mean that dts files with extension data are a bit larger than dts files without it?

The file lenght is always the audio duration x bitrate.

[omega6666]

So; just to get this straight, if there would be a 1 second dts file that plays 1536 kb per second, it would be a file that is 1536 kb long.
If this file would have no extended data (no extra channel and no 96 khz samplerate), the coredata would be 1536 kb long, and 0 kb extended. But if it would be a 96/24 dts file, the coredata would be only about 1349 kb and about 187 kb of extended data (which makes a total of 1536). And if your (older) receiver cannot use this extended data for 96 khz, the soundquality of the produced 48 khz would be lower than the same sized 48/24 dts file, which didn't have extended data at all, since that one will use all of its 1536 kb for the 48 khz.

Is this right?

I always thought that the 1536 kbps 48/24 would have the same amount of core data as the 96/24, but with the 48/24 one, the extended data would be just a bunch of zero's in a row (so the file length would be the same, even though these bits aren't used).

[tebasuna51]

I'm not a dts expert or defender, I think ac3 is more efficient than dts (and aac much more).

Really I don't understand how can use the same bitrate for 48/96, but let bytes without use ...