GNOME Bugzilla – Bug 697111
[typefind/dcaparse] fix DTS frame size for 14-bits packed streams
Last modified: 2018-11-03 11:25:14 UTC
DTS frame size is scaled by 16/14 when parsing 14-bits packed streams, but the header raw value should be used instead. The patches should make DTS SYNC word detection more reliable and should also allow passthrough of DTS audio CDs to work for 14-bits packed stream. Unfortunately I don't have an SPDIF output so I can't test. I've verified the right frame size is extracted with DTS certication files, I've uploaded one here: url=http://absolut.zogzog.org/share/samples/wav/Track33%20DTS-CD%2014-Bit%201024Framsize.wav
Created attachment 240394 [details] [review] typefind: fix frame size parsing for DTS 14bits packed streams
Created attachment 240395 [details] [review] audioparsers: fix DTS frame size parsing for 14bits packed streams
What is it that these patches actually try to fix? Did you test them at all? If so, how exactly? To me, this (a) doesn't really look like it makes sense, and (b) it breaks playback both with dtsdec and avdec_dca . Also, (c) this file plays back perfectly fine without any DTS sync issues as far as I can tell from the baseparse:6 debug log. The 14-bit coding takes the original 16-bit data and recodes it, including all the header bytes. By implication, this means any header values refer to the data in the original 16-bit coding. I would be surprised if that wasn't the cases
You can check with fakesink dump=true that with the patch, all buffers start with a sync word when using dcaparse while without the patch it is not the case. Also the typefind memdump log will show that two sync words are found with the patch, whereas only one is found without the patch. I'm not sure about the decoders not working, I will check tomorrow.
From the DTS spec: "In order to diminish the noise output level resulting when the DTS bitstream is mistakenly played back as PCM format, the DTS bitstream is stored only in the least significant 14 bits of the 16-bit word available for compressed audio in an IEC sub-frame. The most significant 2 bits are not used. In this case, SYNC is stored in three words: 0x1fff, 0xe800, and 0x07f." So that means the frame size does not change when switching to 14-bits packing, since the 2 bits left are just unused, not removed.
> So that means the frame size does not change when switching to 14-bits packing, > since the 2 bits left are just unused, not removed. What do you mean by 'the frame size does not change' exactly? Have you tested with dtsdec and avdec_dca yet? Does it work for you?
Hum, it seems that there's more to this. I actually have two 14-bits files for testing: http://absolut.zogzog.org/share/samples/wav/Track33%20DTS-CD%2014-Bit%201024Framsize.wav http://absolut.zogzog.org/share/samples/wav/Track35%20DTS-CD%2014-Bit%20512Framesize.wav Track33: frame size is 3584 in the header, and the real frame size is 4096 (3584 * 16 / 14) Track35: frame size is 2048 in the header, and the real frame size is 2048 I'm trying to find out how to calculate the frame size correctly in the spec.
(In reply to comment #6) > Have you tested with dtsdec and avdec_dca yet? Does it work for you? "dcaparse ! avdec_dca" works for Track33 but not for Track35 without the patch. With the patch it is the opposite.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/83.