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

[Sebastian Dröge]

Post by 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.
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
play test-adpcm.wav
gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec !
audioconvert ! pulsesink
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.

[Tiago Katcipis]

Sebastian,

Opened a bug for this:

https://bugzilla.gnome.org/show_bug.cgi?id=727975

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

Post by 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.
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
play test-adpcm.wav
gst-launch-1.0 filesrc location=test-adpcm.wav ! wavparse ! adpcmdec !
audioconvert ! pulsesink
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

[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



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Problem-with-IMA-ADPCM-decoding-tp4666392p4666442.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.