Previous tracks bleed into the new one (Samson G-Track)

Audacity Help Forum GNU/Linux
1

Hello, new here, by the moment I use Audacity 1.3.9 and 1.3.11-beta, but as this problem seems to be non-software related, and the mic I use, Samson G-Track, is explicitly the one you use in your tutorials, I thought I’d try to get a response here before going through the long process of updating to version 2, which might might not help for my current problem. I came here from the Linux Musician forum, who hinted that maybe you could help (here is the complete thread: http://www.linuxmusicians.com/viewtopic.php?f=27&t=11246). So far I’ve spent 20+ hours trying to solve this problem.

Here is the problem: I make my music recording it layer-after-layer, one at a time. But now, whenever I record voice with the G-Track, the previous tracks bleed into the new one. Idk if the problem is new, or it is only that I hadn’t noticed it before. The bleeding is sometimes very obvious during the silences in the voice, other times is not that obvious, but you notice it when you normalize the track, and it adds up along the recording process.

I’ve found another thread in this forum that mentions the same problem, https://forum.audacityteam.org/t/first-track-gets-recorded-onto-second-track/5285/1 It says that some sound cards have a “what you hear” option that maybe picks up the sound and causes the problem, and that it can be disabled in an option in bios. But my bios menu does not have the slightest mention to the sound card. I wonder if you have some suggestion because until I find it I’m stuck, I don’t want to get more gear only to discover that the problem was within the computer…

(More data about my equipment: laptop Compaq Presario CQ50, the inbuilt sound card is HDA Intel G45, the distro Puppy Studio 3.3.)

2

I don’t understand in the three tutorials for specialist hardware linked to from http://manual.audacityteam.org/o/man/tutorial_recording_multi_track_overdubs.html why the suggestion is made to set playback and recording devices to the onboard sound card. :confused: I would say that is a copy-paste error and perhaps that is part of the problem?

If you set the Audacity playback and recording devices to a USB mic that has a built in headphones jack and ensure the mic doesn’t send the computer playback back to Audacity I don’t see why you would get bleed through of the tracks you’re singing over.


Gale

3

I don’t understand in the three tutorials for specialist hardware linked to from > Audacity Manual > … rdubs.html why the suggestion is made to set playback and recording devices to the onboard sound card. > :confused: > I would say that is a copy-paste error and perhaps that is part of the problem?

Yes, I noticed that and was going to report the Audacity team. The parameters mentioned there make no sense (here is the relevant fragment of my Linux Musicians thread:)

As far as my understanding goes, there is a mistake in the tutorial. It says

in the Devices tab:

  • Under Playback set Device to the on-board sound card
  • Under Recording set Device to the on-board sound card and set Channels to 1 (Mono)



    When I did that, Audacity listened to and played through the inbuilt computer mic. Instead, the instructions should say “set device to the mic (USB Codec)”, I understand. I had to do that in order to continue with the tutorial. I’d like to report this to the Audacity team, but I wanted to comment it here first in case I am missing something.

If you set the Audacity playback and recording devices to a USB mic that has a built in headphones jack and ensure the mic doesn’t send the computer playback back to Audacity I don’t see why you would get bleed through of the tracks you’re singing over.

Exactly. In all innocence, I tried doing a few more tests, acting as a newcomer, and found something that might be relevant:
as I also mention in the LM thread, when I tried to follow the Audacity+G-Track tutorial, once I corrected the error mentioned above, I stumbled upon a new problem: the recorded track sounded like chopped by a helicopter. This time, what I’ve tried is recording it to 32000Hz instead of 44100, and it solved the chopping.

Then, here is the peculiar thing, I went back to 44100, tried recording again, and the track was recorded well!!! (although with the bleeding).

What could be the cause of this erratic behavior? Could frequency affect this kind of bleeding? For example, maybe the G-Track works better limited to 32000, but then the card leaks a bit of its stuff via the extra bytes?

4

@Koz: I think that Procne (and Gale) are right here. Surley in the three tutorials in the Wiki it should say: “set device to the mic (USB Codec)” as Procne points out.

If you can confirm that this is what you intended for those tutorials then I will update the Wiki pages accordingly.

Thanks,
Peter.

5

Just to cover the bases, you are using good quality, sealed headphones, right?

http://kozco.com/tech/audacity/wynonna2.jpg

Headphones are required for an overdubbing session.

It’s not unheard of for a particularly deaf rock musician to make the headphones so loud they leak through his mouth – I’m not making that up.

Koz

6

@waxy.
You should drop me a PM note when something like this happens. I don’t read all the postings. Koz

7

Koz, I was going to, tomorrow if you hadn’t seen it by then.

But you didn’t answer my previous Question : :slight_smile: Is the poster right about the input device should be the USB - I’m pretty sure that’s right?

Peter Waxy

8

Almost certainly, but I want to go back and read the original text before I jump up and down. I tried only jumping up once and it didn’t end well.

Koz

9

The original text appears to be correct.

http://kozco.com/tech/audacity/overdubbing/overdubbing-SamsonGTrack.html

I’ll go check the Audacity posting.
Koz

10

The Audacity posting is not correct. Follow the original text.

Koz

11

Ok many thanks Koz - I’ll fix that tomorrow - as Gale said it was probably a cut&paste fault - by the transcriber, oops that was me … :astonished: :unamused: :blush:

And thanks to Procne - good catch :nerd: :sunglasses:

Peter

12

I can’t see that the sample rate choice affects bleedthrough but since the mic’s web page and its Manual mention that the ADC works at 48000 Hz I would definitely set the Audacity default sample rate to that (Quality Preferences). It may prevent choppy recording or playback.

From skimming your Linux forum topic, am I correct that the computer mic port has the same bleed problem and Ardour has the same problem as Audacity?

I would tend to take the advice on the Forum and try another distro of Linux that is a known quantity here in audio matters - for example a lightweight derivative of Ubuntu like Lubuntu http://www.lubuntu.net/ . As you realise we only support Audacity 2.x here, so with Lubuntu you might get a more recent version of Audacity or indeed you could compile Audacity 2.0.3 or latest 2.0.4 alpha yourself using simple steps.


Gale

13

I still can’t see why we would set the playback device to the computer sound card so as per Koz’s GTrack page on kozco I changed the playback device on all three Wiki pages to the USB device.


Gale

14

I now agree (after discussing this offline with Koz) - and thanks Gale you’ve thereby save me a chore I’d scheduled for myself for tomorrow :slight_smile:

Koz explains:
The one magic feature of all three devices is the ability to mix your live voice with the computer’s rhythm track so you can hear the mixed musical performance and that can only happen if the rhythm track is available. Making the USB device the playback device makes it available.

Certain older PCs would overdub with no echoes right in the soundcard, but the people who post on the forum are on Win7 or higher (some XP) or Macs and they’re stuck with the echoes. The USB technique works on any computer.

Peter

15

Just to cover the bases, you are using good quality, sealed headphones, right?

Yes I am (well they are not “good quality”, they are homemade from earbuds+construction headphones, but they do seal). I guess that’s the first idea one gets when this kind of bleeding happens :slight_smile:.

Also, to discard such possibility, I tried setting the sound output via the G-Track and not using headphones while recording the track (so no sound was thrown into the atmosphere, no possibility of headphones being accidentally recorded), and yet the bleeding happened.

From skimming your Linux forum topic, am I correct that the computer mic port has the same bleed problem and Ardour has the same problem as Audacity?

Yes, that’s correct. I recorded using a monodirectional mic trough the ‘Mic’ 3.5 input and run exactly into the same bleeding problem. And the problem happens exactly the same with Ardour.

I would tend to take the advice on the Forum and try another distro of Linux that is a known quantity here in audio matters

Yes, I’ll do that at some point soon, once I’ve exhausted the easier options. However, by the moment I’ve found something that seems promising:

I can’t see that the sample rate choice affects bleedthrough but since the mic’s web page and its Manual mention that the ADC works at 48000 Hz I would definitely set the Audacity default sample rate to that (Quality Preferences). It may prevent choppy recording or playback.

(I assume ADC means Audio Device for Capture or something similar, did not find the acronym, please tell me if I’m wrong.)


After reading your suggestion, I tried setting the project’s rate to 48,000 Hz (I hadn’t ever used 48000Hz before, maybe I just went with the default in Audacity and never gave it much though, I’m one of those distracted persons whose eyes slip through the page whenever they find numbers.)

Recording at 48000Hz, the resulting track was chopped!

So then I tried crossing two variables: recording frequency rate (48000, 44100, 32000), and setting sound output to: A) USB Codec (G-track), or B) Internal Alsa Analog. Here are the results:

A) Output through G-Track:

48000 Hz – Chopped track
44100 Hz – Chopped track
32000 Hz – Recorded fine but with the bleeding on background

B) Output through Alsa:

48000 Hz – Track OK! (no chopping and no bleeding)
44100 Hz – Track OK! (no chopping and no bleeding)
32000 Hz – Track OK! (no chopping and no bleeding)

Seems promising, I’ll repeat the testing a couple of times and get back here with the results in case I’ve forgotten something. Anybody has an idea of why this could (or couldn’t work?) And why the track becomes choppy when recorded at its “natural” 48000 frequency? I’d like to understand it all to make sure I’m getting to the root cause. Anyway, I’ll let you know how the experiment goes. Thank you guys for your support and your feedback.

16

ADC: Analogue to Digital Converter. (“Analog” if you’re on the other side of the pond). Analog-to-digital converter - Wikipedia

The “sample rate” is the number of times the waveform is “measured” per second to create a digital representation of the waveform (Digital audio - Wikipedia).
CD audio always uses 44100 samples per second for each channel (left channel and right channel).
The more “measurements” per second, the harder it is for the hardware to keep up, and if you try to take too many measurements per second some of them will be missed and the sound will become “choppy”.

The absolute highest frequency that can be represented digitally is half of the sample rate (in practice, a little less than half). So to record the full audio spectrum (up to about 20,000 Hz) the sample rate needs to be at least 40,000 Hz (The audio CD specification says 44100 Hz, which allows for the practical consideration that the sample rate actually needs to be a little more than twice the highest audio frequency).

17

Generally it’s best to record at the same rate as the device to prevent un-necessary resampling (assuming as Steve says that the computer can keep up with the rate).

Is your sound card able to unmute the microphone playback so you could hear yourself without delay if you used the 3.5mm mic input?



Gale

18

Generally it’s best to record at the same rate as the device to prevent un-necessary resampling (assuming as Steve says that the computer can keep up with the rate).

OK, but then, why when I record at 48K (the Gtrack’s rate) and then listen through its output, I get a choppy track, but when I record at that same rate but send the output via internal Alsa the track is alright? Maybe -just a guess- the computer is ‘busier’ having to send the output to the Gtrack and thus the sound does not get well captured?

Is your sound card able to unmute the microphone playback so you could hear yourself without delay if you used the 3.5mm mic input?

Let me know if this is what you meant: In Alsamixer, there is a bar called ‘Internal mic’. I’ve unmuted it and set it to volume 100. Then, in Audacity, I’ve gone to edit → preferences → recording, and enabled ‘software playthrough’. The result is that, when I start recording, I can hear through the headphones what is being recorded, in real time. However, after a couple of seconds, the sound turns off and from then on the bar of the track being recorded shows only silence, a flat line.

In Alsamixer there is another bar called ‘External mic’, I guess that’s the one related to the mic 3.5 input; I haven’t tested an external mic because I don’t have one at hand, but I think the results would be the same.

I’m not sure what’s the purpose of this test, in which way could this be related to the bleeding? Cautionarily, since I detected this problem, I have all the Alsa parameters I can think of at 0 and muted (btw, when I mute ‘Master’ nothing happens, sound continues the same unless I drop the volume to 0, is that normal?).

I’ve repeated my AB tests and the results are consistent with yesterday’s: output sent through G-Track= track recorded with bleeding and chopping, output sent through internal Alsa, track recorded fine. So I guess the problem gets solved like that, if not with the bonus of understanding what is going on…

I’d like to do a few days of recording to test this under real conditions, and at some point in the future when I have more time I want to test a different distro with Audacity 2, and also a different computer, but I won’t be able to get to that in a couple of months. Anyways, I’ll label this thread as “solved” already, and hopefully forever.

Thank you all for your patience and your help, and Steve, thank you also for the links you provided; “Analog to Digital Converter”, of course, so obvious! That’s the thing with acronyms, they are so evident once you know the answer… if only there were not 100,000 of them… Anyways, the Wikipedia links have been full of “aha” moments for me, so thank you for including them.

19

If you could capture without choppiness using G-Track as output, all I am saying is that in principle you might record with fewer artifacts at 48000 Hz than at other rates because lossy resampling from 48000 Hz would not be needed.

If you have an old slow machine with limited RAM and USB 1.1 ports I suppose you might have this choppiness issue at “higher” rates. What are your machine specifications?

The sample rate in Audacity does not explain the bleedthrough (to me). I would say your USB audio system is broken if you cannot listen to the computer playback in GTrack without recording the playback, and cannot record with GTrack unless you resample to 32000 Hz.

You will hear yourself late if you use software playthrough.

I was suggesting that if you look on the playback side of ALSAmixer and you have a meter for the external mic then you may want to unmute it. Then if you recorded with an external mic and turned software playthrough off, you could hear yourself on time (without latency).

If you usually record overdubs without monitoring what you are recording, and are happy with recording at 32000 Hz using GTrack then yes this is all irrelevant.



Gale

20

If you have an old slow machine with limited RAM and USB 1.1 ports I suppose you might have this choppiness issue at “higher” rates. What are your machine specifications?


  • Processor: Genuine Intel @ 2.00 GHz
    Memory: 964 Mb
    USB:
    Speed: 12,00Mbit/s
    Version: 1,00
    Revision: 2,00

This is very interesting. Could these specs be causing a bottleneck? I got the computer (a laptop) in 2009, I did not realize the USB version was old.

I was suggesting that if you look on the playback side of ALSAmixer and you have a meter for the external mic then you may want to unmute it. Then if you recorded with an external mic and turned software playthrough off, you could hear yourself on time (without latency).

Great, thank you so much for the explanation. I got me a 3.5 mm mic and made the test. I unmarked Playthrough in Audacity, there is indeed an “external mic” bar in Alsa so I set it to 100, both in Playback and Capture just to be sure. Result: no sound comes through the headphones while recording the track. Also, I tried recording with the G-Track mic, sending its output through Alsa Analog, but again, no sound while recording.

So I guess my soundcard cannot do that. But then… what’s the use of that ‘external mic’ bar?

Yeah, recording at 32,000 is lame, and also, it produces the bleedthrough problem that brought me here in the first place. So what would be my options so I can listen to myself while singing? The USB version is going to be 1 no matter what I do, so should I get me a firewire device? I have no idea about Firewire, do you have any suggestion of models that work well with Linux?