gsm in aiff: fix duration

[ami_stuff]

qt reports correct 30.02s

C:\>ffmpeg -i 2ch_48khz.aiff
ffmpeg version N-46755-ge70144c Copyright (c) 2000-2012 the FFmpeg developers
  built on Nov 15 2012 02:38:20 with gcc 4.5.0 (GCC) 20100414 (Fedora MinGW 4.5.
0-1.fc14)
  configuration: --prefix=/var/www/users/research/ffmpeg/snapshots/build --arch=
x86 --target-os=mingw32 --cross-prefix=i686-pc-mingw32- --cc='ccache i686-pc-min
gw32-gcc' --enable-w32threads --enable-memalign-hack --enable-runtime-cpudetect
--enable-cross-compile --enable-static --disable-shared --extra-libs='-lws2_32 -
lwinmm -lpthread' --extra-cflags='--static -I/var/www/users/research/ffmpeg/snap
shots/build/include' --extra-ldflags='-static -L/var/www/users/research/ffmpeg/s
napshots/build/lib' --enable-bzlib --enable-zlib --enable-gpl --enable-version3
--enable-nonfree --enable-libx264 --enable-libspeex --enable-libtheora --enable-
libvorbis --enable-libfaac --enable-libxvid --enable-libopencore-amrnb --enable-
libopencore-amrwb --enable-libmp3lame --enable-libvpx --disable-decoder=libvpx
  libavutil      52.  6.100 / 52.  6.100
  libavcodec     54. 71.100 / 54. 71.100
  libavformat    54. 36.100 / 54. 36.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 23.100 /  3. 23.100
  libswscale      2.  1.102 /  2.  1.102
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
[aiff @ 0x1edc280] max_analyze_duration 5000000 reached at 5000000
Input #0, aiff, from '2ch_48khz.aiff':
  Duration: 01:20:02.35, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Audio: gsm (GSM  / 0x204D5347), 48000 Hz, mono, s16, 79 kb/s
At least one output file must be specified

[Carl Eugen Hoyos]

I wonder if FFmpeg isn't correct: 1440705 is the number of samples written in the aiff header.

[Elon Musk]

Is this file truncated? If not, does same happens when using other codecs?
Remuxing with ffmpeg gives correct duration.

[ami_stuff]

Replying to richardpl:

Is this file truncated?

no

If not, does same happens when using other codecs?

no, but it still can be a bug of converter, the question is why qt reports correct duration?

[Elon Musk]

It may ignore that value and seek to the end of file...

You could try to see what duration is reported for ffmpeg remuxed file:

ffmpeg -i input.aiff -c copy out.aiff

[ami_stuff]

Replying to richardpl:

It may ignore that value and seek to the end of file...

You could try to see what duration is reported for ffmpeg remuxed file:

ffmpeg -i input.aiff -c copy out.aiff

QT reports the same correct duration.

[Elon Musk]

FFmpeg uses what's written in header, one could use stream bitrate to override duration but this is far fetched.