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.

[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. And it is not only trailing, it is also intial priming aka encoder delay.

[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.