GNOME Bugzilla – Bug 727975
adpcmdec: WAV IMA ADPCM files don't get decoded correctly
Last modified: 2018-11-03 13:22:17 UTC
Created attachment 274009 [details] Audio file that can reproduce the problem The problem has been described in detail on the mailing list: http://lists.freedesktop.org/archives/gstreamer-devel/2014-April/047322.html Basically if i try to play a IMA ADPCM WAV file, the playback gets a lot of gaps on it and only the half of the duration of the file is actually played. Also, querying the duration of the audio in time gets in result half of the actual duration. I'm attaching a example file that can be used to reproduce the problem, just try to play it with adpcmdec and it is clear that it is not working properly: gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec ! audioconvert ! pulsesink The file seems to be ok and valid, and plays correctly using "play". file test-adpcm.wav test-adpcm.wav: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 8000 Hz
Initially Bitrate is calculated correctly as 4055 and then it gets changed to 8126 in the following location - riff-media.c ( gst_riff_create_audio_caps function ) case GST_RIFF_WAVE_FORMAT_DVI_ADPCM: /* Many encoding tools create a wrong bitrate information in the * header, so either we calculate the bitrate or mark it as invalid * as this would probably confuse timing */ strf->av_bps = 0; if (strf->channels != 0 && strf->rate != 0 && strf->blockalign != 0) { int spb = ((strf->blockalign - strf->channels * 4) / 2) * 2; strf->av_bps = gst_util_uint64_scale_int (strf->rate, strf->blockalign, spb); GST_DEBUG ("fixing av_bps to calculated value %d of IMA DVI ADPCM", strf->av_bps); } } In this case , the channel is 1 , rate is 8000 and blockalign is 256 spb becomes 252 av_bps becomes 8126 The timestamp is calculated based on BPS. Example gst debug log- 0:00:00.041163544 1480 0x848a230 INFO wavparse gstwavparse.c:695:gst_wavparse_calculate_duration:<wavparse0> Got duration (bps) 0:00:05.009106572 Hence the behaviour!
With gstreamer-0.10 there is no BPS correction and hence the timestamp is shown as 0:00:00.070851887 1699 0x9de8a60 INFO wavparse gstwavparse.c:1130:gst_wavparse_calculate_duration:<wavparse0> Got duration (bps) 0:00:10.037977806
This is probably related to bug #720995
Anyone knows which scenario required this BPS correction ? Also, why the correct bitrate would be 4055 ? Isn't the bitrate 32000 bps (at least with 1 channel / 8000hz) ?
Taking a good look at https://bugzilla.gnome.org/show_bug.cgi?id=720995 i can see that BPS correction has been added, but it has been done only to G726 ADPCM (and the calculations seems to be different too). Anyone knows which IMA ADPCM file that required this BPS correction ? Because right know the only solution to me is just remove this stuff, all information provided on the IMA ADPCM file seems to be correct, and trying to recalculate only generates problems.
The BPS 'correction' was added in commit 6f9006c9b9753f47733ea17f803a63ea5a1500ef ( http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=6f9006c9b9753f47733ea17f803a63ea5a1500ef ) to work around broken wav files created by Oxelon ( https://bugzilla.gnome.org/show_bug.cgi?id=636245 ). I would recommend to not break processing of correct files for the purpose of being able to handle bad files. Perhaps a revert is in order.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/138.