Problem with IMA ADPCM decoding

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with IMA ADPCM decoding

Tiago Katcipis
Hi,

I'm having some funny issues while trying to decode IMA ADPCM files. I'm working with mono/8000hz IMA ADPCM WAV files and when i try to play then with gst-launch i can hear a lot of audio gaps on the audio, and the total playback time is at half of the original audio file.

If i play the audio with "play", it plays correctly.

Debugging a little further, it seems that someone on the pipeline (my bet is on adpcmdec) is generating holes on the stream that causes the audio to be all messed up. If i use a audioparse to correct the holes, the audio plays correctly.

To generate a audio file on the IMA ADPCM format that causes the problem:

gst-launch-1.0 audiotestsrc num-buffers=10 samplesperbuffer=8000 ! audio/x-raw,rate=8000,format=S16LE ! wavenc ! filesink location=test.wav

sox test.wav -e ima-adpcm test-adpcm.wav

Perfect playback (~10 seconds of audio):

play test-adpcm.wav

Messed up playback (~5 seconds of audio):

gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec ! audioconvert ! pulsesink

Perfect playback (~10 seconds of audio):

gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec ! audioparse channels=1 rate=8000 raw-format=4 ! audioconvert ! pulsesink

It seems that half of the audio is lost on this gap problem, but the audio is there since with audioparse everything goes just fine.

audioparse did not completely resolved my problem, because i need to query the duration of the audio in time, and doing this with this pipeline returns half the real duration of the audio, even with audioparse (makes sense with the rest of the problems i found).

I will continue to investigate the problem, just wanted to now if this is a know problem or if I'm doing something wrong. If it is really a problem i can open a bug.

The tests have been executed on a Ubuntu 12.04 with Gstreamer 1.2.1.

Best Regards,
Tiago Katcipis

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with IMA ADPCM decoding

Sebastian Dröge-3
On Mi, 2014-04-09 at 14:25 -0300, Tiago Katcipis wrote:

> Hi,
>
> I'm having some funny issues while trying to decode IMA ADPCM files. I'm
> working with mono/8000hz IMA ADPCM WAV files and when i try to play then
> with gst-launch i can hear a lot of audio gaps on the audio, and the total
> playback time is at half of the original audio file.
>
> If i play the audio with "play", it plays correctly.
>
> Debugging a little further, it seems that someone on the pipeline (my bet
> is on adpcmdec) is generating holes on the stream that causes the audio to
> be all messed up. If i use a audioparse to correct the holes, the audio
> plays correctly.
>
> To generate a audio file on the IMA ADPCM format that causes the problem:
>
> gst-launch-1.0 audiotestsrc num-buffers=10 samplesperbuffer=8000 !
> audio/x-raw,rate=8000,format=S16LE ! wavenc ! filesink location=test.wav
>
> sox test.wav -e ima-adpcm test-adpcm.wav
>
> Perfect playback (~10 seconds of audio):
>
> play test-adpcm.wav
>
> Messed up playback (~5 seconds of audio):
>
> gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec !
> audioconvert ! pulsesink
>
> Perfect playback (~10 seconds of audio):
>
> gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec !
> audioparse channels=1 rate=8000 raw-format=4 ! audioconvert ! pulsesink
>
> It seems that half of the audio is lost on this gap problem, but the audio
> is there since with audioparse everything goes just fine.
>
> audioparse did not completely resolved my problem, because i need to query
> the duration of the audio in time, and doing this with this pipeline
> returns half the real duration of the audio, even with audioparse (makes
> sense with the rest of the problems i found).
>
> I will continue to investigate the problem, just wanted to now if this is a
> know problem or if I'm doing something wrong. If it is really a problem i
> can open a bug.
Please create a bug report for this and to make testing easier also
attach one working and one broken file to it. This is supposed to work
the way you do it, there's either a bug on our side or the files
generated by sox are not 100% correct.

--
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with IMA ADPCM decoding

Tiago Katcipis
In reply to this post by Tiago Katcipis
Sebastian,

Opened a bug for this:


On this week i will take a closer look at it.




On Wed, Apr 9, 2014 at 2:25 PM, Tiago Katcipis <[hidden email]> wrote:
Hi,

I'm having some funny issues while trying to decode IMA ADPCM files. I'm working with mono/8000hz IMA ADPCM WAV files and when i try to play then with gst-launch i can hear a lot of audio gaps on the audio, and the total playback time is at half of the original audio file.

If i play the audio with "play", it plays correctly.

Debugging a little further, it seems that someone on the pipeline (my bet is on adpcmdec) is generating holes on the stream that causes the audio to be all messed up. If i use a audioparse to correct the holes, the audio plays correctly.

To generate a audio file on the IMA ADPCM format that causes the problem:

gst-launch-1.0 audiotestsrc num-buffers=10 samplesperbuffer=8000 ! audio/x-raw,rate=8000,format=S16LE ! wavenc ! filesink location=test.wav

sox test.wav -e ima-adpcm test-adpcm.wav

Perfect playback (~10 seconds of audio):

play test-adpcm.wav

Messed up playback (~5 seconds of audio):

gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec ! audioconvert ! pulsesink

Perfect playback (~10 seconds of audio):

gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec ! audioparse channels=1 rate=8000 raw-format=4 ! audioconvert ! pulsesink

It seems that half of the audio is lost on this gap problem, but the audio is there since with audioparse everything goes just fine.

audioparse did not completely resolved my problem, because i need to query the duration of the audio in time, and doing this with this pipeline returns half the real duration of the audio, even with audioparse (makes sense with the rest of the problems i found).

I will continue to investigate the problem, just wanted to now if this is a know problem or if I'm doing something wrong. If it is really a problem i can open a bug.

The tests have been executed on a Ubuntu 12.04 with Gstreamer 1.2.1.

Best Regards,
Tiago Katcipis


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with IMA ADPCM decoding

harishjennykn
Hello !

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


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


Hence the behaviour!


~HJ