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

[waxcylinder]

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 ...

And thanks to Procne - good catch

Peter

[Gale Andrews]

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?

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

[Gale Andrews]

Ok many thanks Koz - I'll fix that tomorrow

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

[waxcylinder]

Ok many thanks Koz - I'll fix that tomorrow

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.

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

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

[Procne]

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 .

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.

[steve]

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

ADC: Analogue to Digital Converter. ("Analog" if you're on the other side of the pond). http://en.wikipedia.org/wiki/Analog-to- ... _converter

why the track becomes choppy when recorded at its "natural" 48000 frequency?

The "sample rate" is the number of times the waveform is "measured" per second to create a digital representation of the waveform (http://en.wikipedia.org/wiki/Digital_audio).
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).

[Gale Andrews]

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)

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

[Procne]

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.

[Gale Andrews]

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?

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.

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.

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

[Procne]

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?