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 794280 - wavparse: failed to parse an S24_LE wav file
wavparse: failed to parse an S24_LE wav file
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.12.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-03-13 09:53 UTC by Lyon
Modified: 2018-03-20 08:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
1 channel S24_LE wav audio (1.68 MB, audio/wav)
2018-03-14 01:42 UTC, Lyon
Details
2 channels S24_LE wav audio (3.36 MB, audio/wav)
2018-03-14 01:44 UTC, Lyon
Details

Description Lyon 2018-03-13 09:53:16 UTC
Hi, 

When I was trying to playback and S24_LE wav file, wavparse return the blockAlign is invalid and failed to play.

The log info as below:   (GST_DEBUG=wavparse:6)

# gst-launch-1.0 filesrc location=audio_l44k24b2c.wav  ! wavparse ! filesink location=/tmp/tmp.pcm
Setting pipeline to PAUSED ...
0:00:00.112387035 30150     0x3679df30 DEBUG               wavparse gstwavparse.c:2801:gst_wavparse_sink_activate:<wavparse0:sink> activating pull
Pipeline is PREROLLING ...
0:00:00.114615325 30150     0x36716370 LOG                 wavparse gstwavparse.c:2164:gst_wavparse_loop:<wavparse0> process data
0:00:00.114734612 30150     0x36716370 INFO                wavparse gstwavparse.c:2168:gst_wavparse_loop:<wavparse0> GST_WAVPARSE_START
0:00:00.114950385 30150     0x36716370 INFO                wavparse gstwavparse.c:2183:gst_wavparse_loop:<wavparse0> GST_WAVPARSE_HEADER
0:00:00.115002708 30150     0x36716370 DEBUG               wavparse gstwavparse.c:1138:gst_wavparse_stream_headers:<wavparse0> creating the caps
0:00:00.115099073 30150     0x36716370 WARN                wavparse gstwavparse.c:1741:gst_wavparse_stream_headers:<wavparse0> error: Stream claims blockalign = 8, which is more than 6 - invalid data
0:00:00.115211880 30150     0x36716370 DEBUG               wavparse gstwavparse.c:2205:gst_wavparse_loop:<wavparse0> pausing task, reason error
0:00:00.115246322 30150     0x36716370 WARN                wavparse gstwavparse.c:2249:gst_wavparse_loop:<wavparse0> error: Internal data stream error.
0:00:00.115319046 30150     0x36716370 WARN                wavparse gstwavparse.c:2249:gst_wavparse_loop:<wavparse0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstWavParse:wavparse0: GStreamer encountered a general stream error.
Additional debug info:
../../../git/gst/wavparse/gstwavparse.c(1741): gst_wavparse_stream_headers (): /GstPipeline:pipeline0/GstWavParse:wavparse0:
Stream claims blockalign = 8, which is more than 6 - invalid data
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
0:00:00.116234339 30150     0x3679df30 DEBUG               wavparse gstwavparse.c:251:gst_wavparse_dispose:<wavparse0> WAV: Dispose


And I checked the wavparse:
        if (wav->blockalign > wav->channels * ((wav->depth + 7) / 8))
          goto invalid_blockalign;
however, for S24_LE format wav
suppose the depth is 24, and the width=32, and the blockAlign is 8 (for 2channels), so it is > 2*(24+7)/8, considered as invalid value.

I'm not sure whether the BlockAlign here is right or not,  or maybe my understanding is not right, the blockAlign value is incorrectly encoded.
Comment 1 Sebastian Dröge (slomo) 2018-03-13 13:59:25 UTC
Can you provide such a wav file?
Comment 2 Lyon 2018-03-14 01:42:55 UTC
Created attachment 369641 [details]
1 channel S24_LE wav audio
Comment 3 Lyon 2018-03-14 01:44:10 UTC
Created attachment 369642 [details]
2 channels S24_LE wav audio
Comment 4 Lyon 2018-03-14 01:45:19 UTC
Please see attached 1 and 2 channel wav files, Thanks
Comment 5 Sebastian Dröge (slomo) 2018-03-19 09:20:32 UTC
ffmpeg and vlc also fail to play back this file, and from what I can see it's simply invalid. This is basically having 24 bit samples in 32 bits, with the upper 32 bits being 0 (i.e. GST_AUDIO_FORMAT_S24_32LE), but AFAIK this is nothing that can be expressed with WAV.

What software created these files?
Comment 6 Lyon 2018-03-20 03:39:23 UTC
Hi slomo,
my colleague's in QA team write an encoder to encode various kinds of audio format/channel clips for test our audio hardware codec and also Gstremer audio capability. 

Some formats like S24LE, S243LE etc.

So according to your comments, currently our GStreamer framework not support S24LE audio format?
(GST_AUDIO_FORMAT_S24_32LE, though this format is defined, currently it is not supported yet, right?)


Is that the reason in gsteaveparse, when blockalign > depth bytes, it would be considered as invalid?
(wavparse gstwavparse.c:1741:gst_wavparse_stream_headers:<wavparse0> error: Stream claims blockalign = 8, which is more than 6 - inva
lid data
)

I tried ignoring this condition, but the audio will be recognized as S32LE, which the sound is not quite correct.

Thanks
Lyon
Comment 7 Sebastian Dröge (slomo) 2018-03-20 07:33:38 UTC
(In reply to Lyon from comment #6)
> Hi slomo,
> my colleague's in QA team write an encoder to encode various kinds of audio
> format/channel clips for test our audio hardware codec and also Gstremer
> audio capability. 
> 
> Some formats like S24LE, S243LE etc.
> 
> So according to your comments, currently our GStreamer framework not support
> S24LE audio format?
> (GST_AUDIO_FORMAT_S24_32LE, though this format is defined, currently it is
> not supported yet, right?)

GStreamer supports it, and also supports S24LE in WAV (3 bytes per sample), but WAV does not support S24_32LE (4 bytes per sample, upper 8 bits unused). Also no other software I tried handles this file.

> I tried ignoring this condition, but the audio will be recognized as S32LE,
> which the sound is not quite correct.

You would have to make sure that it uses S24_32LE instead of S32LE
Comment 8 Lyon 2018-03-20 08:38:18 UTC
Thanks, slomo, got your point now.
Also I find in MS wave spec:

The value of the BlockAlign property must be equal to the product of Channels and BitsPerSample divided by 8 (bits per byte).

that means wav does not support S24_32LE, S16_32LE etc.