Inverted samples in WAV recording when clipping #15

Author

Owner

@hacst commented on GitHub (Nov 7, 2013):

That looks funky. It's very possible that using the float format is actually the fix as that's what we use internally. I'll have to take a proper look at the source-code to make sure.

This might actually be the source of the other issue described in #1024 .

@hacst commented on GitHub (Nov 7, 2013): That looks funky. It's very possible that using the float format is actually the fix as that's what we use internally. I'll have to take a proper look at the source-code to make sure. This might actually be the source of the other issue described in #1024 .

deekerman commented

Author

Owner

@ghost commented on GitHub (Dec 23, 2013):

@dD0T Hello! I've had these crackling issues on 1.2.4. Is this fix implemented in the latest snapshot on the official site?

@ghost commented on GitHub (Dec 23, 2013): @dD0T Hello! I've had these crackling issues on 1.2.4. Is this fix implemented in the latest snapshot on the official site?

deekerman commented

Author

Owner

@hacst commented on GitHub (Dec 24, 2013):

Unfortunately not. I applied the fix to this branch after refactoring so I wasn't able to selectively take it over into our master before cleaning it up. It is scheduled to be in 1.2.5 though. As temporary workaround you can record in AU or Vorbis format. Those use in floating point and should not clip.

@hacst commented on GitHub (Dec 24, 2013): Unfortunately not. I applied the fix to this branch after refactoring so I wasn't able to selectively take it over into our master before cleaning it up. It is scheduled to be in 1.2.5 though. As temporary workaround you can record in AU or Vorbis format. Those use in floating point and should not clip.

deekerman commented

2026-02-20 19:09:54 -05:00

Author

Owner

@ghost commented on GitHub (Dec 28, 2013):

@dD0T Oh. :/ So the issue persist with .flac as well?
I prefer to record in .wav or .flac as they arent compressed..

@ghost commented on GitHub (Dec 28, 2013): @dD0T Oh. :/ So the issue persist with .flac as well? I prefer to record in .wav or .flac as they arent compressed..

deekerman commented

Author

Owner

@hacst commented on GitHub (Dec 28, 2013):

@thernztrom FLAC takes in PCM24 data so it is affected. While AU is a pretty unusual format it is using float and is uncompressed so you can convert it to a format of your liking afterwards.

@hacst commented on GitHub (Dec 28, 2013): @thernztrom FLAC takes in PCM24 data so it is affected. While AU is a pretty unusual format it is using float and is uncompressed so you can convert it to a format of your liking afterwards.

deekerman commented

2026-02-20 19:09:55 -05:00

Author

Owner

@ghost commented on GitHub (Dec 28, 2013):

@dD0T Okay. Thanks for the fast reply! :)
Hopefully we'll have a fix for this soon. In the mean time I'll be lazy and record in .ogg.

@ghost commented on GitHub (Dec 28, 2013): @dD0T Okay. Thanks for the fast reply! :) Hopefully we'll have a fix for this soon. In the mean time I'll be lazy and record in .ogg.

deekerman commented

2026-02-20 19:09:55 -05:00

Author

Owner

@hacst commented on GitHub (Feb 13, 2014):

@thernztrom I just merged the fix as 8e22f9a211 . Snapshots are building currently (should be 1.2.5-240-gea165cd). Would be great if you could check to make sure this fixes your issues.

@hacst commented on GitHub (Feb 13, 2014): @thernztrom I just merged the fix as 8e22f9a2110907df0cf49dc1a838da3e6043bbb5 . Snapshots are building currently (should be 1.2.5-240-gea165cd). Would be great if you could check to make sure this fixes your issues.

deekerman commented

2026-02-20 19:09:55 -05:00

Author

Owner

@hacst commented on GitHub (Feb 22, 2014):

I'm closing this in the assumption that the issue is resolved. Please reopen if this isn't the case.

@hacst commented on GitHub (Feb 22, 2014): I'm closing this in the assumption that the issue is resolved. Please reopen if this isn't the case.

deekerman commented

Author

Owner

@flyser commented on GitHub (Feb 9, 2015):

I am experiencing this issue in flac or wav multi-track recordings with version 1.3.0 e469bd6273
Please reopen

@flyser commented on GitHub (Feb 9, 2015): I am experiencing this issue in flac or wav multi-track recordings with version 1.3.0 e469bd627302aef0567b2f8a63905d72ce247652 Please reopen

deekerman commented

Author

Owner

@hacst commented on GitHub (Feb 9, 2015):

@flyser Hi. Can you provide a recording with the issue? Also which platform and architecture architecture are you running on? I can't reproduce the issue with the current snapshot (was pretty easy before). If it's just clipping that would be expected behavior. This issue produced wraparound with a very audible crackle.

@hacst commented on GitHub (Feb 9, 2015): @flyser Hi. Can you provide a recording with the issue? Also which platform and architecture architecture are you running on? I can't reproduce the issue with the current snapshot (was pretty easy before). If it's just clipping that would be expected behavior. This issue produced wraparound with a very audible crackle.

deekerman commented

Author

Owner

@flyser commented on GitHub (Feb 25, 2015):

I analyzed the problem a bit further and found very weird behaviour.
Take a look at the following screenshot: http://i.imgur.com/y7uJey8.png
The first track is the flac file generated by mumble, the second track is the same flac file transcoded to .wav with ffmpeg and the third track is an ogg file generated by a different mumble instance.

I would be happy to provide a sample file, but it seems I can't cut out the example portion without creating the artifacts you see on track two.
I am wondering why audacity is able to decode it properly, but neither sox, flac-utils nor ffmpeg are ...

EDIT: system and architecture: a x86_64 Linux system

@flyser commented on GitHub (Feb 25, 2015): I analyzed the problem a bit further and found very weird behaviour. Take a look at the following screenshot: http://i.imgur.com/y7uJey8.png The first track is the flac file generated by mumble, the second track is the same flac file transcoded to .wav with ffmpeg and the third track is an ogg file generated by a different mumble instance. I would be happy to provide a sample file, but it seems I can't cut out the example portion without creating the artifacts you see on track two. I am wondering why audacity is able to decode it properly, but neither sox, flac-utils nor ffmpeg are ... EDIT: system and architecture: a x86_64 Linux system

deekerman commented

Author

Owner

@flyser commented on GitHub (Feb 25, 2015):

Here is another screenshot showing inversed clipping in mumble: http://i.imgur.com/Pg8faIW.png
The first track is the flac file generated by mumble and the second track is a recording done by sox via pulseaudio simultaniously

@flyser commented on GitHub (Feb 25, 2015): Here is another screenshot showing inversed clipping in mumble: http://i.imgur.com/Pg8faIW.png The first track is the flac file generated by mumble and the second track is a recording done by sox via pulseaudio simultaniously

deekerman commented

Author

Owner

@hacst commented on GitHub (Feb 25, 2015):

Ah dammit. I just reviewed my patch (8e22f9a211) and it looks like I was working under the invalid assumption that SF_FORMAT_* subtypes were flags and not an enumeration. That screwed up the comparison. No idea why I didn't catch that in testing.

@flyser If you can compile from our master please check if 1c00533b09 resolves the issue. Thanks a lot for reporting this.

@hacst commented on GitHub (Feb 25, 2015): Ah dammit. I just reviewed my patch (8e22f9a2110907df0cf49dc1a838da3e6043bbb5) and it looks like I was working under the invalid assumption that SF_FORMAT_\* subtypes were flags and not an enumeration. That screwed up the comparison. No idea why I didn't catch that in testing. @flyser If you can compile from our master please check if 1c00533b091b683cfa25b218da69afcb0360284c resolves the issue. Thanks a lot for reporting this.

deekerman commented

Author

Owner

@flyser commented on GitHub (Feb 25, 2015):

Thanks for the fast response, I will test this as soon as I can.
What about the inverted clipping that occured in the ogg file as well?

@flyser commented on GitHub (Feb 25, 2015): Thanks for the fast response, I will test this as soon as I can. What about the inverted clipping that occured in the ogg file as well?

deekerman commented

Author

Owner

@hacst commented on GitHub (Feb 25, 2015):

Not sure what's up with that. From my understanding vorbis only does floating point encoding and shouldn't be constrained to [-1.0, 1.0] either. Are you sure that spike is an inversion and not just a pop + clipping introduced in another way?

That being said: If it does turn out to be an inversion I'd be interested to find out where in our processing pipeline that is coming from...

@hacst commented on GitHub (Feb 25, 2015): Not sure what's up with that. From my understanding vorbis only does floating point encoding and shouldn't be constrained to [-1.0, 1.0] either. Are you sure that spike is an inversion and not just a pop + clipping introduced in another way? That being said: If it does turn out to be an inversion I'd be interested to find out where in our processing pipeline that is coming from...

deekerman commented

Author

Owner

@flyser commented on GitHub (Feb 26, 2015):

The inverted clipping you see in http://i.imgur.com/Pg8faIW.png is also present in the ogg file and not present in the sox recording, so yes I am pretty sure

@flyser commented on GitHub (Feb 26, 2015): The inverted clipping you see in http://i.imgur.com/Pg8faIW.png is also present in the ogg file and not present in the sox recording, so yes I am pretty sure

deekerman commented

Author

Owner

@flyser commented on GitHub (Mar 1, 2015):

I suspect the inverted clipping occurs before the opus encoding step, as surrounding samples seem to contain encoding artifacts. Maybe the compressor/amplifier is causing the clipping?

@flyser commented on GitHub (Mar 1, 2015): I suspect the inverted clipping occurs before the opus encoding step, as surrounding samples seem to contain encoding artifacts. Maybe the compressor/amplifier is causing the clipping?

deekerman commented

Author

Owner

@hacst commented on GitHub (Mar 6, 2015):

Sounds reasonable. The output path from decoder into the recorder should all be float. In the input we still have a PCM16 conversion due to the Speex filter stage (those should all be scale + clamp though).

Wonder if AGC would produce sth. like this if gain is too high...that would suck...(I doubt that though)

@hacst commented on GitHub (Mar 6, 2015): Sounds reasonable. The output path from decoder into the recorder should all be float. In the input we still have a PCM16 conversion due to the Speex filter stage (those _should_ all be scale + clamp though). Wonder if AGC would produce sth. like this if gain is too high...that would suck...(I doubt that though)

deekerman commented

Author

Owner

@flyser commented on GitHub (Mar 10, 2015):

Is there anything I can do to debug this issue? I am happy to test patches or provide debugging output if it helps. This bug means a lot of extra work for me and would love to see it fixed.

@flyser commented on GitHub (Mar 10, 2015): Is there anything I can do to debug this issue? I am happy to test patches or provide debugging output if it helps. This bug means a lot of extra work for me and would love to see it fixed.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 18, 2015):

👍 Didn't realise this was a Mumble issue. Have been trying to fix stuff with level for almost 1.5yrs.

I'm gonna try to build of 1c00533 on saturday. Will report if it fixed the issues.

@notthetup commented on GitHub (Mar 18, 2015): :+1: Didn't realise this was a Mumble issue. Have been trying to fix stuff with level for almost 1.5yrs. I'm gonna try to build of 1c00533 on saturday. Will report if it fixed the issues.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 19, 2015):

Wow, compiling Mumble on my OSX is complicated. Are the development snapshots off the master branch?? So would Mumble-Universal-1.3.0~~547~~g657f9e8 which was built on 15-Mar-2015 01:40 have picked up 1c00533?

@notthetup commented on GitHub (Mar 19, 2015): Wow, compiling Mumble on my OSX is complicated. Are the development snapshots off the master branch?? So would Mumble-Universal-1.3.0~547~g657f9e8 which was built on 15-Mar-2015 01:40 have picked up 1c00533?

deekerman commented

Author

Owner

@hacst commented on GitHub (Mar 19, 2015):

@notthetup Yes. Snapshots are created from the master on github. g657f9e8 means the snapshot was created from git revision 657f9e8 which contains 1c00533b09 .

@hacst commented on GitHub (Mar 19, 2015): @notthetup Yes. Snapshots are created from the master on github. g657f9e8 means the snapshot was created from git revision 657f9e8 which contains 1c00533b091b683cfa25b218da69afcb0360284c .

deekerman commented

Author

Owner

@mkrautz commented on GitHub (Mar 19, 2015):

Note that the "-Universal" builds for OS X are legacy builds. They built with Qt in Carbon mode as opposed to Cocoa. They only exist to allow people to use Mumble on OS X 10.4-10.6 machines, as well as PowerPC Macs.

@mkrautz commented on GitHub (Mar 19, 2015): Note that the "-Universal" builds for OS X are legacy builds. They built with Qt in Carbon mode as opposed to Cocoa. They only exist to allow people to use Mumble on OS X 10.4-10.6 machines, as well as PowerPC Macs.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 19, 2015):

OK. Got it. I'll try this fix and let you know in a couple of days!

@notthetup commented on GitHub (Mar 19, 2015): OK. Got it. I'll try this fix and let you know in a couple of days!

deekerman commented

Author

Owner

@flyser commented on GitHub (Mar 19, 2015):

1c00533 does not fix this completely. I am not sure how to explain this ... somehow the waveform is always clipped to the positive (i.e. the upper maximum in audacity) value even if they should be clipped to the lowest value. Does that make sense to you?

@flyser commented on GitHub (Mar 19, 2015): 1c00533 does not fix this completely. I am not sure how to explain this ... somehow the waveform is always clipped to the positive (i.e. the upper maximum in audacity) value even if they should be clipped to the lowest value. Does that make sense to you?

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 19, 2015):

@flyser I think a waveform image would explain this the best.

@notthetup commented on GitHub (Mar 19, 2015): @flyser I think a waveform image would explain this the best.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 19, 2015):

Also, it seems all builds in the snapshot repository from 1c00533 forward are Universal. What's the process of creating snapshots?

P.S. I'm failing horribly at building mumble on OSX. After working around some QT SSL version issues (which seems to be fixed in the latest commit) now there is a linker issue.

@notthetup commented on GitHub (Mar 19, 2015): Also, it seems all builds in the snapshot repository from 1c00533 forward are Universal. What's the process of creating snapshots? P.S. I'm failing horribly at building mumble on OSX. After working around some QT SSL version issues (which seems to be fixed in the latest commit) now there is a linker issue.

deekerman commented

Author

Owner

@hacst commented on GitHub (Mar 20, 2015):

@notthetup I think @mkrautz is currently working on some issue with the normal OSX builds that prevent new snapshots for them from being created.

@hacst commented on GitHub (Mar 20, 2015): @notthetup I think @mkrautz is currently working on some issue with the normal OSX builds that prevent new snapshots for them from being created.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 21, 2015):

Yup. I talked to @mkrautz on IRC. I'm stuck at the same place as him.

@notthetup commented on GitHub (Mar 21, 2015): Yup. I talked to @mkrautz on IRC. I'm stuck at the same place as him.

deekerman commented

Author

Owner

@mkrautz commented on GitHub (Mar 21, 2015):

@notthetup It's fixed now.

@mkrautz commented on GitHub (Mar 21, 2015): @notthetup It's fixed now.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 21, 2015):

👍

@notthetup commented on GitHub (Mar 21, 2015): :+1:

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 22, 2015):

So I was using a g657f9e8 build for my podcast recording yesterday, and I can confirm that the inversion issue is fixed.

Here is a screenshot of a bit where the audio clipped because it was too loud. Before this, it would have inverted.

@notthetup commented on GitHub (Mar 22, 2015): So I was using a g657f9e8 build for my podcast recording yesterday, and I can confirm that the inversion issue is fixed. Here is a screenshot of a bit where the audio clipped because it was too loud. Before this, it would have inverted. ![screenshot 2015-03-22 17 43 47](https://cloud.githubusercontent.com/assets/553140/6768815/05bbbbf2-d0bb-11e4-8573-3616e5d1af48.jpg)

deekerman commented

Author

Owner

@flyser commented on GitHub (Mar 22, 2015):

This is what happened to some really bad clipping in my recording:
The first track is the original mumble file, the second track shows how the clipping should look like.

@flyser commented on GitHub (Mar 22, 2015): This is what happened to some really bad clipping in my recording: ![corruption1](https://cloud.githubusercontent.com/assets/1144183/6769784/cbaef97c-d0a8-11e4-9481-61729a14ab1c.png) The first track is the original mumble file, the second track shows how the clipping **should** look like.

deekerman commented

Author

Owner

@flyser commented on GitHub (May 6, 2015):

Note that https://github.com/mumble-voip/mumble/pull/1651 fixes some inverted clipping that was shown in this issue. inverted clipping in FLAC (and possibly WAV) recording as shown in my last comment is still present though

@flyser commented on GitHub (May 6, 2015): Note that https://github.com/mumble-voip/mumble/pull/1651 fixes some inverted clipping that was shown in this issue. inverted clipping in FLAC (and possibly WAV) recording as shown in my last comment is still present though

deekerman commented

Author

Owner

@ghost commented on GitHub (Nov 18, 2015):

Any progress on this issue? @hacst
Havent tested the new versions since 1.2.4, but looking at this its at the same state in 1.2.10?

Some clipping exmaples from when we recorded audio in 1.2.4 (.wav):
https://youtu.be/2i35f6XBvCg?t=15s
https://youtu.be/2i35f6XBvCg?t=1m

@ghost commented on GitHub (Nov 18, 2015): Any progress on this issue? @hacst Havent tested the new versions since 1.2.4, but looking at this its at the same state in 1.2.10? Some clipping exmaples from when we recorded audio in 1.2.4 (.wav): https://youtu.be/2i35f6XBvCg?t=15s https://youtu.be/2i35f6XBvCg?t=1m

deekerman commented

Author

Owner

@flyser commented on GitHub (Nov 18, 2015):

1.2.10 should still be affected by this bug. I haven't tested the 1.3 prereleases for a while though

@flyser commented on GitHub (Nov 18, 2015): 1.2.10 should still be affected by this bug. I haven't tested the 1.3 prereleases for a while though

deekerman commented

Author

Owner

@hacst commented on GitHub (Nov 19, 2015):

@thernztrom As flyser says 1.2.10 does not have the later patches. We changed numbering schemes http://blog.mumble.info/version-numbering-change/ which makes the version numbers mentioned in this issue a bit confusing. TL;DR: Since 1.2.4 the 1.2.X branch only receives essential fixes for security and breaking issues. Pretty much all the new features as well as most bugfixes are currently only available in our 1.3 snapshots.

W.r.t to whether it is completely fixed by now: I don't know. Looking at flysers last reports it doesn't look like it. I think I had some IRL distractions and simply forgot about following up with this one again...

@flyser Steps to reproduce is simply recording something in say WAV and ensuring clipping occurs? That's on a Linux box with Pulseaudio?

@hacst commented on GitHub (Nov 19, 2015): @thernztrom As flyser says 1.2.10 does not have the later patches. We changed numbering schemes http://blog.mumble.info/version-numbering-change/ which makes the version numbers mentioned in this issue a bit confusing. TL;DR: Since 1.2.4 the 1.2.X branch only receives essential fixes for security and breaking issues. Pretty much all the new features as well as most bugfixes are currently only available in our 1.3 snapshots. W.r.t to whether it is completely fixed by now: I don't know. Looking at flysers last reports it doesn't look like it. I think I had some IRL distractions and simply forgot about following up with this one again... @flyser Steps to reproduce is simply recording something in say WAV and ensuring clipping occurs? That's on a Linux box with Pulseaudio?

deekerman commented

Author

Owner

@flyser commented on GitHub (Nov 20, 2015):

It should be reproducable in any recording that takes several minutes. It might me easier if you allow mumble to amplify your microphone a lot (I don't remember what this setting was called; the automatic amplification thingy) and when you don't talk constantly, but do a lot of pauses, so the automatic amplification has time to raise the volume while you don't talk.

But even without these preconditions, it should be easy to reproduce.

To find the clipping in the recording, I opened the file in audacity, doubled the track and applied a 20kHz high-pass filter to the second one. When you zoom near the peaks of the filtered track, the result should be similar to the screenshots I posted.
EDIT: Also apply a normalization filter to the high-pass track to make the peaks more visible.

I also use Linux and pulseaudio, but I doubt it makes any difference, since .au recording is fine.

@flyser commented on GitHub (Nov 20, 2015): It should be reproducable in any recording that takes several minutes. It might me easier if you allow mumble to amplify your microphone a lot (I don't remember what this setting was called; the automatic amplification thingy) and when you don't talk constantly, but do a lot of pauses, so the automatic amplification has time to raise the volume while you don't talk. But even without these preconditions, it should be easy to reproduce. To find the clipping in the recording, I opened the file in audacity, doubled the track and applied a 20kHz high-pass filter to the second one. When you zoom near the peaks of the filtered track, the result should be similar to the screenshots I posted. EDIT: Also apply a normalization filter to the high-pass track to make the peaks more visible. I also use Linux and pulseaudio, but I doubt it makes any difference, since .au recording is fine.

deekerman commented

Author

Owner

@flyser commented on GitHub (Dec 4, 2015):

@hacst Did you manage to reproduce it?

@flyser commented on GitHub (Dec 4, 2015): @hacst Did you manage to reproduce it?

deekerman commented

Author

Owner

@hacst commented on GitHub (Dec 5, 2015):

Unfortunately not yet. I'm having a real hard time to even get it to clip in the first place and the occurances I've had were all clean. I'll have to inject clipping audio into the input stage I guess...

@hacst commented on GitHub (Dec 5, 2015): Unfortunately not yet. I'm having a real hard time to even get it to clip in the first place and the occurances I've had were all clean. I'll have to inject clipping audio into the input stage I guess...

deekerman commented

Author

Owner

@mkrautz commented on GitHub (Dec 13, 2015):

We believe the commit 23fa9b3979 might have something to do with this.

Could you guys please test this? It is in the latest snapshot, 1.3.0~~883~~g2a31708~snapshot.

Thanks.

@mkrautz commented on GitHub (Dec 13, 2015): We believe the commit 23fa9b3979c244f1bcdbc80972a88ef7144f8f4a might have something to do with this. Could you guys please test this? It is in the latest snapshot, 1.3.0~883~g2a31708~snapshot. Thanks.

deekerman commented

Author

Owner

@flyser commented on GitHub (Dec 13, 2015):

I didn't do much recording lately, but I will try to test this in the coming weeks.

@flyser commented on GitHub (Dec 13, 2015): I didn't do much recording lately, but I will try to test this in the coming weeks.

deekerman commented

Author

Owner

@flyser commented on GitHub (Jan 9, 2016):

I just did a one hour recording with 2 participants (me using a git build of today on linux and the other one using the most recent snapshot on windows). Both tracks did not exhibit any inverted clipping when recording to floating-point .au, but did invert-clip at least 15 times during this hour when recording to integer .flac.

@flyser commented on GitHub (Jan 9, 2016): I just did a one hour recording with 2 participants (me using a git build of today on linux and the other one using the most recent snapshot on windows). Both tracks did not exhibit any inverted clipping when recording to floating-point .au, but did invert-clip at least 15 times during this hour when recording to integer .flac.

deekerman commented

Author

Owner

@ghost commented on GitHub (Feb 13, 2023):

Has this been addressed in 1.4?

@ghost commented on GitHub (Feb 13, 2023): Has this been addressed in 1.4?

deekerman commented

Author

Owner

@Krzmbrzl commented on GitHub (Feb 16, 2023):

I know the audio processing itself (the one responsible for playing things through the speakers) does clipping (seemingly) properly (explicitly).
I believe recording bypasses this processing though 🤔

@Krzmbrzl commented on GitHub (Feb 16, 2023): I know the audio processing itself (the one responsible for playing things through the speakers) does clipping (seemingly) properly (explicitly). I believe recording bypasses this processing though :thinking:

deekerman commented