ffmpeg ignores padding when decoding DTS-HD MA stream in DTSHD container

[Rollinnn]

Summary of the bug:
I took wav file 24 bit 96 kHz, encoded it to DTS-HD MA in DTSHD container using DTS-HD Master Audio Suite encoder.
Then i re-encoded my *.dtshd file to flac using ffmpeg.
Then i did binary comparison (i used foobar2000 with plugin foo_bitcompare, but probably there exist other tools for this) of resulting flac against source wav and found that resulted flac is offsetted by 2048 samples.
If i use dcadec (​https://github.com/foo86/dcadec/releases) to decode *.dtshd file to wav, then resulted wav is bit-identical with source wav. If i use dcadec with option -S (Don't strip padding samples for streams within DTS-HD container), then resulted wav is also offsetted by 2048 samples. So it seems that ffmpeg just ignores padding for DTS-HD MA stream in DTSHD container.
Attached zip archive contains source wav file and dtshd file.

How to reproduce:

ffmpeg -i C:\0000000000000\DTSENC.dtshd C:\0000000000000\DTSENC.flac
ffmpeg version N-91330-ga990184007 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7.3.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  libavutil      56. 18.102 / 56. 18.102
  libavcodec     58. 20.103 / 58. 20.103
  libavformat    58. 17.100 / 58. 17.100
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 25.100 /  7. 25.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, dtshd, from 'C:\0000000000000\DTSENC.dtshd':
  Metadata:
    fileinfo        :
                    :
  Duration: 00:00:00.77, bitrate: 3909 kb/s
    Stream #0:0: Audio: dts (DTS-HD MA), 96000 Hz, stereo, s32p (24 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (dts (dca) -> flac (native))
Press [q] to stop, [?] for help
Output #0, flac, to 'C:\0000000000000\DTSENC.flac':
  Metadata:
    fileinfo        :
                    :
    encoder         : Lavf58.17.100
    Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit), 128 kb/s
    Metadata:
      encoder         : Lavc58.20.103 flac
size=     307kB time=00:00:00.76 bitrate=3276.5kbits/s speed=27.4x
video:0kB audio:299kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.711299%

[Balling]

Yes, ffmpeg -i DTSENC.dtshd -c:a pcm_s24le dawsa.wav

appears to be shifted (i.e. it has some zeros in the start and some zero samples in the end). Other than that it is LOSSLESS, though. Just some initial padding and some remainder padding should be removed.

I suppose it is a common problem that lossy decoders have a priming and remainder, and DTS HD MA is based on lossy decode and then on top of it lossless delta.

[Balling]

Adding gapless tag, fix it already.

This code? ​https://github.com/FFmpeg/FFmpeg/blob/870bfe16a12bf09dca3a4ae27ef6f81a2de80c40/libavcodec/dca_exss.c#L39

[Elon Musk]

See patches about trailing_samples, ffmpeg ignores it.

[Balling]

See patches about trailing_samples, ffmpeg ignores it.

How hard is it to copy ​​https://github.com/foo86/dcadec/releases code??? I mean foo86 could not to it when porting to ffmpeg, SO this is hilarious.

[Balling]

OMG, apparently dcadec.exe has this option:

-S Don't strip padding samples for streams within DTS-HD container.

And it produces the same file that ffmpeg produces. Hilarious.