I now try parsing everything in the channel set sub-header. But I get into a
bit of trouble.
This is the debug output I get from my hacked avconv:
[dca @ 0x20f3120] DTS-XLL: decoding XLL extension
[dca @ 0x20f3120] xll_nch_sets = 1
[dca @ 0x20f3120] xll_segments = 4
[dca @ 0x20f3120] xll_smpl_in_seg = 256
[dca @ 0x20f3120] xll_bits4seg_size = 11
[dca @ 0x20f3120] xll_banddata_crcen = 0
[dca @ 0x20f3120] xll_scalable_lsb = 1
[dca @ 0x20f3120] xll_bits4ch_mask = 5
[dca @ 0x20f3120] xll_fixed_lsb_width = 0
[dca @ 0x20f3120] xll channel set 0
[dca @ 0x20f3120] hdr_pos = 16464
[dca @ 0x20f3120] hdr_size = 47
[dca @ 0x20f3120] channels = 5
[dca @ 0x20f3120] residual_encode = 0
[dca @ 0x20f3120] bit_resolution = 24
[dca @ 0x20f3120] bit_width = 24
[dca @ 0x20f3120] sampling_frequency = 96000
[dca @ 0x20f3120] fs_interpolate = 0
[dca @ 0x20f3120] replacement_set = 0
[dca @ 0x20f3120] downmix_coeff_code_embedded = 1
[dca @ 0x20f3120] downmix_embedded = 1
[dca @ 0x20f3120] primary_ch_set = 1
[dca @ 0x20f3120] downmix_type = 1
[dca @ 0x20f3120] hier_chset = 1
[dca @ 0x20f3120] skipping 12 downmix coefficents, 108 bits at pos 44
[dca @ 0x20f3120] skipping speaker info, 125 bits at pos 153
[dca @ 0x20f3120] adapt order start at bit 279
[dca @ 0x20f3120] xll adapt order: max = 8
[dca @ 0x20f3120] ch 0: adapt 0, fixed 2
[dca @ 0x20f3120] ch 1: adapt 8, fixed 0
[dca @ 0x20f3120] refl coeff 0: 64
[dca @ 0x20f3120] refl coeff 1: 0
[dca @ 0x20f3120] refl coeff 2: 0
[dca @ 0x20f3120] refl coeff 3: 0
[dca @ 0x20f3120] refl coeff 4: 0
[dca @ 0x20f3120] refl coeff 5: 0
[dca @ 0x20f3120] refl coeff 6: -3
[dca @ 0x20f3120] refl coeff 7: 87
[dca @ 0x20f3120] ch 2: adapt 0, fixed 0
[dca @ 0x20f3120] ch 3: adapt 0, fixed 1
[dca @ 0x20f3120] ch 4: adapt 0, fixed 1
[dca @ 0x20f3120] xll scalable lsbs
[dca @ 0x20f3120] ch 0: lsbs 15, adj 12
[dca @ 0x20f3120] ch 1: lsbs 9, adj 14
[dca @ 0x20f3120] ch 2: lsbs 14, adj 8
[dca @ 0x20f3120] ch 3: lsbs 5, adj 2
[dca @ 0x20f3120] ch 4: lsbs 3, adj 12
[dca @ 0x20f3120] chset header too large, 422 bits, should be <= 376 bits
So the parsing extracts bits beyond the end of the chset header, 47
bytes.
Relevant values from preceding headers are one2one_map_chtospkr (true,
from the asset header), xll_bits4_chmask (5), xll_scalable_lsb (1), and
xll_bits4seg_size (11).
My test case is "Master Audio 5.0 96khz.dts", where the first channel
set header occurs at byte offset 2058, and is 47 bytes long.
Hex:
0000000 0b 90 17 be 87 3e 0f 66 01 c1 80 70 60 1d 98 07
0000016 07 f9 6a 00 89 5c 01 01 f0 01 f1 51 d0 50 50 50
0000032 d2 50 b0 10 00 10 b0 00 00 00 00 00 00 f5 d4
0000047
Binary, manually parsed:
0 00001011 10010000 00010111 10111110 10000111 00111110 00001111 01100110
`---------'`--'`----'`---' `---'`---'`'`'||| `-'|`---------------------
size 46+1 | resid. | bitw | | |||| | | 12 dm coeffs à 9 bits
ch=4+1 bitres =23+1 | | |||| | | 108 bits
= 23+1 freqind | |||| | |
= 13 | |||| | |
96000Hz | |||| | |
interpolate |||| | |
repl. set||| | |
primary|| | |
dm-coeff code embedded| | |
dm-coeff embedded | |
dm-type |
= 1, stereo|
hier chset
8 00000001 11000001 10000000 01110000 01100000 00011101 10011000 00000111
-----------------------------------------------------------------------
16 00000111 11111001 01101010 00000000 10001001 01011100 00000001 00000001
-------------------------' |`------------------------------------------
ch mask enable speaker info, 5*25 = 125 bits
24 11110000 00000001 11110001 01010001 11010000 01010000 01010000 01010000
-----------------------------------------------------------------------
32 11010010 01010000 10110000 00010000 00000000 00010000 10110000 00000000
-----------------------'|`---'`--'`---'`--'`---'`'`'`-'`'`-------'`----
ch decor enable 0 8 0 0 0 2 0 1 1 refl coeff,
`-- adapt order --' fix. ord.
40 00000000 00000000 00000000 00000000 00000000 11110101 11010100
--'`-------'`-------'`-------'`-------'`-------'`-------'`--------???
8 * 8 bits -3 +87 LSBFsize, 11
bits.
So when I get to the LSBFSize field, I read beyond the end of the
header.
I guess I either read too many bits for some preceeding field, where the
poorly specified downmix coeffients are the main suspect. Or I get the
xll_scalable_lsb flag wrong; if this flag really should be false, then
no further data is expected after the reflection coefficients, and the
final 5 bits (10100) are to be interpreted as reserved or padding.
Does Kostya or anyone else spot where the parsing goes wrong?
madshi: I've also tried running eac3to -logdts on this file, under wine.
This gives me the following log:
eac3to v3.27
command line: Z:\media\sf_shared\eac3to\eac3to.exe foo.dts foo.flac -logdts
------------------------------------------------------------------------------
+ DTS-Core
- frameSize 2012
- DTS-ES -
- channelNo 5
- lfe 0
- channelDescr 5.0
- samplingRate 48000
- bitDepth 24
- bitrate 1509000
- samplesPerFrame 512
- copyHistory 1
+ DTS-HD
- fullSize 2080
- headerSize 32
- refClockCode 1/48000
- frameDurationCode 1
- activeMasks [1], [[1]]
+ Asset [0]
- fullSize 2048
- headerSize 14
- corePackets Core
- extSubStrPackets XLL
- bitResolution 24
- maxSampleRate 96000
- totalNumChannels 5
- activeSpeakers C L R Ls Rs ($7)
DTS Master Audio, 5.0 channels, 24 bits, 96kHz
(core: DTS, 5.0 channels, 24 bits, 1509kbps, 48kHz)
The ArcSoft and Sonic decoders don't seem to work, will use libav instead.
The libav DTS decoder doesn't decode the full DTS-HD information. <WARNING>
Extracting DTS core...
Decoding with libav/ffmpeg...
Reducing depth from 64 to 24 bits...
Encoding FLAC with libFlac...
Creating file "foo.flac"...
The last DTS frame is incomplete and thus gets skipped. <WARNING>
The original audio track has a constant bit depth of 64 bits.
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 1 second.
Done.
Is it possible to get it to log chset sub-headers in more detail?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
