GNOME Bugzilla – Bug 707757
Wav file plays with audible crackling/noise at end of file in case of tag
Last modified: 2013-10-24 07:13:40 UTC
When a wav file contains an ID tag with meta information about the track, it plays with audible noise at the end of the file. Apparently the tag is also being "played" as music. This should not happen. The tag information should not be played. References: http://www.psaudio.com/vanilla/discussion/3135/white-noise-at-end-of-wav-files/p1 http://yabb.jriver.com/interact/index.php?topic=74972.0 How to reproduce: take any song as wav file, add a tag to it in your favorite ID tag application (KID3 will do), and play the file. This was found on a system with: Debian Linux Wheezy with gstreamer 1.0.8 from backports.
The typefinder detects files with id3v1 as wav, not as application/x-id3, that's the problem here. id3v2 is detected properly.
Hi Sebastian, you are correct. It seems that id3v2 is not giving the noise at the end of the file. I was not sure if it was just the id3v1 or also the tag that is called "LIST" (which I am not sure what it is exactly) is giving this noise. Is there anything that can be done to prevent this noise? From what I understand from the issue, is that this meta information is being stored outside of the part of the file that contains the actual sound, so it should actually never be an issue in that sense that this is audible, right? best regards, Hendrik-Jan
This is a bug both in wavparse and the typefinders. The file should be detected as containing an ID3 tag, and when reading the raw audio data the ID3 tag should be skipped anyway. The LIST tags are tags inside the WAVE file, that's nothing that should interfere with anything. It's the standard way of putting that into WAVE files.
Hi Sebastian, I did some more tests. I used KID3 to play with the tag a bit, and see the result. Unfortunately all versions of the ID3v2 tag cause a lot of white noise. (versions being: V2.3.0 ID3LIB and V2.4.0 TagLIB) So this looks not just to be an issue with the ID3v1 tags. Do you need some sample from me, or can you generate one yourself with the instructions I put in the first report. best, Hendrik-Jan
If you could provide one, that would speed things up :)
as the file is too large to attach, I will put a link here: wav file with noise at the end: http://hjh.syssap.nl/wavfile.wav
This file has no ID3 tag in the beginning or end, and also not LIST tag. It's just containing the WAVE header in the beginning and afterwards raw audio samples until the end.
The file contains both LIST and 'id3 ' tag. The later is not currently handled by gstreamer (i'll check if it's a correct way to wrap id3 tag into wav files). However I can't hear any white noise using gstreamer 1.0.10 and HEAD using the playbin element. Is there a particular way to reproduce the issue ?
Hi Matthieu, I hear it when playing through gmrender-resurrect: https://github.com/hzeller/gmrender-resurrect This is when playing on any audio system connected to this as "sound out". Also: I am using gmstreamer version 1.0.8 (debian package). Is there any way the difference betweet 1.0.8 and 1.1.0 could explain this? thanks, Hendrik-Jan
Hi Matthieu, I just did some additional testing: it seems that this issue exists in build 1.0.8, but not in 0.1.0 (which is standard in debian wheezy). So it seems that the issue is isolated to 1.0.8, can that be? best regards, Hendrik-Jan
Ah indeed it has LIST and id3v2 tags. Missed them because they're at the very end. In theory wavparse should already skip them both and does here, so no white noise should be heard. Can you reproduce white noise with gst-launch-1.0 playbin uri=file:///path/to/wavfile.wav ? Also nonetheless the typefinder has to be fixed, Tim said that WAV files with ID3 tags are unfortunately relatively common. Should be easy to fix by just adjusting some typefinder ranks/certainties.
The command is (in one line): > gst-launch-1.0 playbin uri=file:///path/to/wavfile.wav
Thank you Sebastian, I did some additional testing, and it seems that in 1.10 indeed the issue is smaller. There is still a hissing sound at the end of the file, but no longer the loud noise that 1.0.8 had. Will this issue be taken as a bug to be fixed in a next version? thank you. Hendrik-Jan
Can you confirm that you reproduced the error using gst-launch-1.0 playbin [...] ?
Hi Matthieu, with version 1.0.8 I can. With version 1.0.10 it sounds more like a muffed hissing, so a lot less disturbing, and only audible when you listen well.
Some more testing revealed the following: The crackling issue is not there anymore on 1.0.10, on AMD64 on an intel soundcard. However, it is still there on 1.0.10 on i386 on an asus audigy TOS out to DAC, to amplifier. I am not sure if this could be due to the difference between i386 and amd64 or something else...
Can it be that for the Debian amd64 and i386 packages the trigger for reading teh wav file databit is set differently? http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-wavparse.html
The person who added this feature was: vincent.penquerch@collabora.co.uk
This feature/bug was introduced with: Bug 665911
Additional testing: It seems that the patch delivered by Bug 665911 was not the issue. Stripping it out of the source code made no difference. Also, I found that this seems to be confined to this specific config: emulating the issue on an atom laptop, on its own soundcard did not produce white noise. however, the setup of atom with asus audigy and Meitner dac over TOS does produce white noise. I am not sure anymore where to look for the issue. As far as I understand how gstreamer works, the only culprit can be the wavparse plugin. Anyone please?
One more to show this is a real issue: I converted the wav file as put in this thread to an mp3 through gstreamer: gst-launch-1.0 filesrc location=/storage/wavfile.wav ! wavparse ! audioconvert ! lamemp3enc ! filesink location=wavfile_mp3.mp3 The result is an mp3 file which is not 3:43 as is the wav file, but something that is over 17 mins long... Please find the mp3 file here: http://hjh.syssap.nl/wavfile_mp3.mp3
You'll have to add xingmux after lamemp3enc to make sure that the file duration can be detected properly. I get no noise in your MP3, and also when checking the output of > gst-launch-1.0 filesrc location=test.wav ! decodebin ! filesink location=test.raw I see no noise at the end with e.g. audacity. Instead the last part of the file is completely silent. Do you get the noise with your MP3? Do you get the noise with other files too? Currently I would be guessing that this is a problem somewhere in your sound setup. Nonetheless there's still the bug that the typefinder does not detect the ID3 tag here.
Also id3demux does not detect the ID3 tags, which is because ID3v2 tags at the end of file are not valid and the ID3v1 tag (which would be at the end of file) is in front of the ID3v2 tag (and as such not at the very end of the file). So I'd say the way how the ID3 tags are inside this file is invalid, and also there seem to be no noise produced at all because of them. Thus probably not a bug at all
Some more: I have been doing a lot of testing and found out some more, which is unfortunately not helping. Found the same as you: when rebuilding the issue on another system, I could indeed not reproduce it. So in some way the Asus sound card and/or the tos link seem to be involved as well. On this system with the issue, I can also reproduce by using vlc as playback device, but not with aplay as playback device. So I am somewhat stuck on this one. It seems to be the waveparse indeed, but only on specific setup. n anyone help me find a way to show or reproduce the issue please? Thanks, Hendrik-Jan
VLC does not use wavparse though, the only thing GStreamer and VLC have in common is that they both use ALSA for audio output (or PulseAudio, depending on your setup). So that's where I would look for the problem.
Hi Sebastian, normally I would agree with you here. However, as mentioned with aplay (which is commandline playback directly over alsa), this noise does not appear. Also: with audacious there is no noise either. So it still looks like it's coming from gstreamer (and a similar issue at vlc). Bestregards, Hendrik-Jan
So, we now know that it's unrelated to wavparse as that does not output the tags and also the output is not broken for anybody else. So this leaves ALSA/PulseAudio and the sink elements for them. Which audio system are you using, pulseaudio or alsa directly? Can you reproduce it with > gst-launch-1.0 filesrc location=whatever.wav ! wavparse ! audioconvert ! alsasink > gst-launch-1.0 filesrc location=whatever.wav ! wavparse ! audioconvert ! pulsesink > gst-launch-1.0 filesrc location=whatever.wav ! wavparse ! audioconvert ! alsasink device=hw:0,0 ?
Hi Sebastian, I'm using: gst-launch-1.0 filesrc location=whatever.wav ! wavparse ! audioconvert ! alsasink I will now test the other 2 options.
gst-launch-1.0 filesrc location=whatever.wav ! wavparse ! audioconvert ! alsasink device=hw:0,1 noise at the end; same as the alsasink without device. gst-launch-1.0 filesrc location=whatever.wav ! wavparse ! audioconvert ! pulsesink no noise at the end.
If you don't run the pulseaudio daemon, does it work better with alsa? Are you using the alsa pulseaudio plugin, which lets alsa access route through pulseaudio instead of directly going to the driver? Try without it
Actually I installed the pulseaudio plugin specifically for this test. Normally this is not installed on this system. However strange this is, once I use pulseaudio as sink (which connects back to Alsa in the end anyways again), I do not have this crackling issue.
Maybe your ALSA driver produces these crackling sound when the device is closed? And pulseaudio will keep the device open. But then aplay --device=hw:0,1 should reproduce it. Does it?
After a lot of testing, in which aplay --device=hw:0,1 did NOT produce the crackling sound, we re-assessed where the problem could come from. The setup we use is: jRiver as remote, gstreamer as part of gmrender-resurrect, and minidlna or twonky as library/media server. jRiver lives on a Windows client pc, all the rest on the Linux server. We found that when we played/selected the exact same .wav files not through jRiver but any other dlna remote (upnp, bubble upnp, etc...), we did NOT hear this sound! So apparently there is something with jRiver that triggers this (should not even be possible, right?). So I guess the message is: doubt everything in case of dlna, nothing is what it seems. Sorry to have bugged you on this.