24-bit TAK play as 32-bit, which causes converted files to be 32 bit as well

[d125q]

ffprobe version 2.7.2 Copyright (c) 2007-2015 the FFmpeg developers
  built with gcc 5.2.0 (GCC)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-gnutls --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-shared --enable-version3 --enable-x11grab
  libavutil      54. 27.100 / 54. 27.100
  libavcodec     56. 41.100 / 56. 41.100
  libavformat    56. 36.100 / 56. 36.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 16.101 /  5. 16.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, tak, from 'Music/Endlichkeit/(2014-08-09) Endlichkeit III–V/01. III.tak':
  Metadata:
    Track           : 1/3
    Disc            : 1/1
    Album           : Endlichkeit III–V
    Album artist    : Endlichkeit
    Album artist sort: Endlichkeit
    Artist          : Endlichkeit
    Comment         : Digital download: http://bandcamp.fallenempirerecords.com/album/endlichkeit-iii-v
    Year            : 2014-08-09
    Title           : III
    replaygain_album_gain: -6.29 dB
    replaygain_album_peak: 1.000000
    replaygain_track_gain: -6.11 dB
    replaygain_track_peak: 0.905005
  Duration: 00:06:40.36, start: 0.000000, bitrate: 1653 kb/s
    Stream #0:0: Audio: tak, 44100 Hz, 2 channels, s32p (24 bit)

DeaDBeeF treats these files as 32-bit, which it should not.

[kode54]

FFMPEG's decoder actually does read 24 bit TAK files as S32P, by shifting the sample data up by 8 bits. So technically, the only "correct" way to deal with this, in a way which is generic to an FFMPEG frontend, is to read the bits_per_coded_sample or bits_per_raw_sample member(s) of the AVCodecContext structure, and treat the contents of the S32P samples accordingly. Which is to say, down shift 32 bit samples if they are supposed to be 24 bits.

I don't really see the point to doing that, though, unless your sound processing path is really sensitive to 24 bit samples being padded to 32 bits.

E: Crap, I see the potential problem. It is reading from the info that they are 24 bit, but the decoder actually pads them to 32 bits.

[Oleksiy-Yakovenko]

Technically, it's ffmpeg's fault in doing this, and deadbeef does the right thing. Case closed.

[d125q]

@Alexey-Yakovenko the main problem is that converting these files again results in files padded to 32-bit (i.e. if I were convert the above file to WavPack, I'd get a 32-bit WavPack file). FFmpeg does not do this.

[Oleksiy-Yakovenko]

It's because ffmpeg cheats and stores the "true BPS value" in the info.

Deadbeef doesn't, and converter doesn't/can't get this info.

It could be solved by adding a special metadata field, understandable by converter, which would contain the "true bit depth", for the sole reason of working around the ffmpeg+tak issue.

But this is a completely different thing than what this bug was about.

[d125q]

I assume the issue would be present for any lossless codec (or any codec where the BPS value is meaningful) that is set to be handled by FFmpeg.

[Oleksiy-Yakovenko]

It's not present on (most) other formats to my best knowledge.