After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 727975 - adpcmdec: WAV IMA ADPCM files don't get decoded correctly
adpcmdec: WAV IMA ADPCM files don't get decoded correctly
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.2.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-10 16:22 UTC by tiagokatcipis
Modified: 2018-11-03 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Audio file that can reproduce the problem (39.81 KB, audio/x-wav)
2014-04-10 16:22 UTC, tiagokatcipis
Details

Description tiagokatcipis 2014-04-10 16:22:11 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
Comment 1 Harish Jenny K N 2014-04-15 05:58:21 UTC
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!
Comment 2 Harish Jenny K N 2014-04-15 05:59:35 UTC
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
Comment 3 Sebastian Dröge (slomo) 2014-04-19 17:16:07 UTC
This is probably related to bug #720995
Comment 4 tiagokatcipis 2014-04-22 20:21:18 UTC
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) ?
Comment 5 tiagokatcipis 2014-04-25 15:31:03 UTC
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.
Comment 6 Serge van den Boom 2015-04-05 13:29:56 UTC
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.
Comment 7 GStreamer system administrator 2018-11-03 13:22:17 UTC
-- 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.