Tests failing with wrong shapes

[jaidevd]

Hi author(s),

I'm trying to run the tests included in this package, but the assert statements on the shapes of the stems are failing. The tests expect a shape of (5, 265216, 2) but the file has a shape of (5, 267264, 2).

Is this a bug or have the files been updated without updating the tests?

Thanks!

[faroit]

Hey. Thanks for the report.

No, the test vectors weren't changed.

On my machine and on Travis the tests succeed. What version of ffmpeg are you using on what OS?

[jaidevd]

Hi @faroit
I'm using version 2.8.11 on Ubuntu 16.04. Specifically, this is the output of ffmpeg -version:

ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
libavutil      54. 31.100 / 54. 31.100
libavcodec     56. 60.100 / 56. 60.100
libavformat    56. 40.101 / 56. 40.101
libavdevice    56.  4.100 / 56.  4.100
libavfilter     5. 40.101 /  5. 40.101
libavresample   2.  1.  0 /  2.  1.  0
libswscale      3.  1.101 /  3.  1.101
libswresample   1.  2.101 /  1.  2.101
libpostproc    53.  3.100 / 53.  3.100

[faroit]

okay, I can now reproduce your issue on travis: https://travis-ci.org/faroit/stempeg/builds/326423503

Basically this means ffmpeg > 3 decode the file differently regarding the zeros padding. I don't know yet what would be the best solution. Either force users to upgrade ffmpeg extending zeros to the output from within python

[faroit]

Okay, I figures out the difference.

it is because the older version ships with a different aac decoder which pads 2048 samples of silence in the beginning whereas the newer versions do only append 1024 samples:

https://travis-ci.org/faroit/stempeg/jobs/326442731#L511

[faroit]

Okay I did not find a better solution than issue a UserWarning if the ffmpeg version < 3 and the duration in samples cannot be divided by 1024 when writing stems.

Sorry, but these codecs are a mess....