I'm not sure, it's just something in a paper I once read. Azimuth is usually set with a mirror under the stylus to see that it is at 90 degrees to the plane of the LP. To refine that, you look at crosstalk and make it even between the channels. You need a test disc to do this with a signal only on the left and one only on the right.
Yes and no... With pulseaudio I need to use a few loopback modules. The thing about pulseaudio is that you cannot tell pulseaudio what to do when it comes to latency. You can politely ask but in the end it's pulseaudio that decides. The loopback modules all do adaptive resampling. As I use different LADSPA plugin instances per channel and therefore different loopback instances per channel I *might* *sometimes* get sample accurate sync between left and right but I'm afraid I won't be that lucky. If there is drift between left and right then my crosstalk cancelling spiel will not work.
I made some cables today and tried my luck with pulseaudio. I got no signal from the left speaker and some signal from the right. Somehow the right channel was picking up a howling kind of feedback as I increased volume. There was some kind of echo and tonality was way off. Very weird. While checking the cabling I bumped the line cable that goes to my active speakers and made them erupt in a huge 50Hz burst at full volume. I might need to figure out some other way to test this that does not wake up babies and will not blow up my eardrums
Probably ALSA is the way to go. Pulseaudio's loopback is made to try and keep two things in sync that are inherently going to drift. That's not a problem I have in this case - as both of my inputs are clocked from the same 24MHz HDA clock they will always be in sync. I'd rather not have adaptive resampling and other black magic going on in the background so I'll need to look into using ALSA. Not today though. For the rest of the day I'll just re-evaluate the results I achieved this far (read: spin records).
Very cool! I was recently using my USB soundcard to do the same thing, however it has 1meg input impedance so frequency response was not very flat. I did some fixing in software. It never occurred to me to try the line input of the laptop.
You're lucky that your laptop actually still has a line input. My Thinkpad only comes with the 4 pin headphone jack so the input is mono only. I think the Conexant codec that's in there could be quite useful otherwise...
Very interesting. I was reading lowbeats.de today, they had a reviews of the entire Goldring 2000 series and of the entire AT-VM95 series. In their articles they always stress how meticulously they set up their carts before reviews yet the crosstalk graphs they include are often wildly different for left and right.
Machine translation of VM95 series review with graphs
Then there are these Fozgometer devices some people use. It's just a box with a VU meter that shows you the amount of crosstalk when playing a test record. It's used to set azimuth AFAIK. I wonder how these people would feel if shown how the same thing can be done for free in Audacity, with a lot more precision at that.
The Foz XTR supposedly does what my Denon PCC 1000 does except that it has a VU meter so it can be used like the Fozgometer.
So I guess there are two camps here, one that defines correct azimuth as crosstalk being identical on both channels and and another one that has some other criteria.
Personally, I'll stick with my plug&play carts for the time being. T4P - the lazy man's choice.
As you can see sometimes things are a little out. This one enough that mechanical correction may be needed!
The XTR intrigues me as not clear how they implemented the fact that crosstalk can be in or out of phase depending on the cartridge. Should only be a few opamps if I get thinking time.
I'll be honest and I've yet to have great success with either pulse or Alsa. I'm approaching linux audio from the wrong direction I think. My hope is to be able to use an old laptop for experiments driving the Calf equaliser Calf Studio Gear - GNU/Linux Audio Plug-Ins using a midi controller. This way I can mess around with adjustments twiddling knobs rather than losing concentration starting at a screen. It allows M-S processing so should be a powerful experimentation tool. It won't however do the X-talk correction.
The XTR intrigues me as not clear how they implemented the fact that crosstalk can be in or out of phase depending on the cartridge. Should only be a few opamps if I get thinking time.
I'll be honest and I've yet to have great success with either pulse or Alsa. I'm approaching linux audio from the wrong direction I think. My hope is to be able to use an old laptop for experiments driving the Calf equaliser Calf Studio Gear - GNU/Linux Audio Plug-Ins using a midi controller. This way I can mess around with adjustments twiddling knobs rather than losing concentration starting at a screen. It allows M-S processing so should be a powerful experimentation tool. It won't however do the X-talk correction.
Attachments
On the XTR there are two knobs, each labeled as neg. On one side and pos. On the other. The PCC 1000 corrects either positive or negative crosstalk, too. For the Denon I have schematics but they go way over my head. If you're interested then I'll post them. It's a discrete design from the 70s.
To generate the correction signal I'd do the following: use a potentiometer to set the ratio of a mixing stage where one input is the in phase signal and the other one is the out of phase signal, both attenuated by 20dB. When the mixer's ratio is 1:1 then both correction signals cancel each other out. Turning the knob left would add more negative signal, turning right would add more positive signal. I'd guesstimate that -20dB is a good upper limit for the correction signals, any cartridge that needs more should just be replaced.
Thanks very much for this, I will study it.
I can tell you from actually doing it that azimuth does affect crosstalk symmetry. Twist it one way and crosstalk shifts, twist it the other way and it shifts the opposite direction. I've done it recently with a Stanton 681 conical and AT VM95E elliptical. Same results.Azimuth is a pain in the butt to adjust on my old Grado maple tonearm - I have to use shims under the cart - but it works. Does symmetrical crosstalk mean perfect azimuth? Well that is something I don't know for certain.
I had never heard of them before and had to do some research. Very interesting.
But as I discovered, just because they are ceramics does not mean that they are loud. The Philips 390 is 6,5mV, the Micro Acoustics are all about 3,5mV. But both MA and Philips track at very moderate weights.
There are other, less sophisticated ceramics that generate 0,4V but these seem to like insane tracking weights. I'm not going to drop a needle that tracks at 6g anywhere near my test discs.
In the mean time I tried to get an idea about what the system dynamic range might be and how much of a problem (if any) noise actually is.
I grabbed the HiFi News test disc and compared the 315Hz +18dB track with the system noise floor (record player on auto-mute) and "preamp" on. I find the HiFi News test disc pretty annoying for just about everything you can do with it but it happes to be the only one with a track that is supposedly recorded at +18dB - all the others I have go up to +15dB. The HFN has many flaws but it seems to be the one that 'goes to eleven'.
As all the graphs were done with simple peak hold, both graphs show absolute worst case behaviour. Of course K2 looks insanely high but I don't think this aspect has any practical relevance. What I do find interesting is the 80dB difference between the +18dB peak and the noise floor at that same frequency. More than I expected, for sure.
A few days ago, while in the train, it occured to me that I could also separate the correction signal into one signal for above 200Hz and one signal for below 200Hz. I picked that frequency as a starting point because once you go lower, crosstalk rises quickly. The idea was to have a cancelling signal especially for the low notes, maybe a little louder or of opposing phase.
It was a nice idea while it lasted. Turns out that, below 200Hz, you are not actually measuring crosstalk from the pickup element. You're mostly just measuring the test disc. What worked on the CBS disc below 200Hz had the opposite effect on the B+K. Might as well leave it alone then.
I also tried out an asound.conf I wrote to get the virtual balanced input working. Alas, as I expected, LibreELEC is missing some libraries I need and adding the asound.conf throws it into a boot loop.
To conclude, I now know of many more ways to make stuff not work. That might come in handy one day.
It was a nice idea while it lasted. Turns out that, below 200Hz, you are not actually measuring crosstalk from the pickup element. You're mostly just measuring the test disc. What worked on the CBS disc below 200Hz had the opposite effect on the B+K. Might as well leave it alone then.
I also tried out an asound.conf I wrote to get the virtual balanced input working. Alas, as I expected, LibreELEC is missing some libraries I need and adding the asound.conf throws it into a boot loop.
To conclude, I now know of many more ways to make stuff not work. That might come in handy one day.
IMO appropriate .asoundrc for your case should not be complicated - just the route plugin config. We can take a look at it when you have time.
You were probably measuring the crosstalk of the cutting head. Something that is hard to calibrate out at the precision you are working with. PCs make things possible that were unimaginable for the home enthusiast even 25 years ago
I think you're spot on - I had not thought of it like that. The old CBS disc has about 10dB more crosstalk than the newer B+K. That explains why I'll never find one correction signal that will work with both. I'm probably better off just summing to mono below 100Hz and discarding anything that is not on both channels.
Thank you, that would be much appreciated! Before I continue with this I need to do some yak shaving though: I need to upgrade my laptop to a bigger SSD, then I can use the current laptop SSD to set up a dual boot system on my living room PC. This way I can experiment to my heart's content while my wife can rely on Netflix/TV working as always.
After looking at that "poor man's SNR graph" again I'd really like to lower the noise floor between 0 and 200Hz. Virtual balanced is the only thing I can imagine that could achieve that.
I also want to look into ffmpeg's vinyl related features: It has specialized vinyl declick filters, all kinds of deemphasis filters, a filter that removes vinyl noise, a de-esser... Quite a few things I would have expected to find a LADSPA or LV2 filter for but didn't. Maybe I can get ffmpeg to work as a quasi realtime filter engine...
That makes sense. I've got an analog Elliptical filter board waiting for time to build (confusingly its not an elliptic filter in the EE sense, but Neumann called it that on the lathes and the name stuck. But it does the mono blend nicely.
Another thing I would love to do. It's a shame that clickrepair stopped doing the Real time version of their declicker, but apparantly if you buy the current non real time version and then get the RT from the wayback machine it runs on that license. Not checked that though.
I have not used the ffmpeg filter in real time yet but I did a quick test of the declick filter at default settings with a recording I already had. It was surprising how much CPU power it needed. On my old Thinkpad it maxed out two out of four threads while it ran at below 0.3x real time speed.
The file I had was in 32 bit floating point PCM at 96KHz so I converted it down to 16 bit linear PCM. Still running at slightly below 0.3x realtime.
Downsampling to 48KHz did the trick, it was now running at above 5x realtime.
If I start using this in a realtime setup then I think I will feed ffmpeg with PCM at 96K and have it downsample to 48K in its processing pipeline. That should still be better than capturing at 48K because for this sampling rate Realtek specifies the upper frequency limit of their ADC at 19.2KHz. With 96K it is 38.4KHz bandwidth so downsampling back to 48K should result in the kind of bandwidth any sane chip would produce in the first place
Now the good news is that I think the ffmpeg declick filter is really, really good (no tweaks, default settings). This is all you need for a quick test with a file from local storage:
Code:
ffmpeg -i input.wav -af adeclick output.wavMy test was with a recording of an old LP that had clicks and pops every few seconds with bursts of multiple clicks per second. I listened to a whole side declicked with ffmpeg and all clicks were completely gone except for two (in a 20 minute recording). Very impressive.
So far I did not hear any artifacts on the first and second listen. Maybe I'll detect a signature when I figure out what to listen for. But for the moment I must say that I'm really amazed at how well this masks errors.
Because I was listening to the cleaned up recording with my IEMs I did however hear a lot of noise from the realtek gain stage that I would not have picked up on when listening with my speakers. I live near a busy street where there are cars, trams and trains passing by all the time. The thick walls and triple glazed windows keep noise down to an acceptable level but it was still enough so that I never clearly heard the ethernet noise or the hiss that is faintly audible in quiet passages. The SNR graphs I made did indicate that there would be noise, and there it is. I really need to get the virtual balanced input going to see whether this makes a noticeable difference but a few things still need to be sorted out before I can try again.
Last edited:
@ariendj That declick is a find ! Seems it is a recent addition to ffmpeg as the Ubuntu 18.04 build doesn't include it.
I added the ppa for ffmpeg 4.2.2 and did a quick test.
Initial thoughts are that it is useful and seems to have a good removal without affecting sq at upper frequency's too noticeably.
However there is something odd in the lower frequency's that I will have to investigate.
I'll do a comparison with Brian Davies Click-Repair and see if it's real or imagined
@Pano the aforementioned Click-Repair does real-time declicking.
It's shareware but has a trial. To date it has been my preferred declicker and well worth the cost.
Resurrect your old recordings | Audio Restoration | Brian Davies
Seems it is a recent addition to ffmpeg as the Ubuntu 18.04 build doesn't include it.I added the ppa for ffmpeg 4.2.2 and did a quick test.
Initial thoughts are that it is useful and seems to have a good removal without affecting sq at upper frequency's too noticeably.
However there is something odd in the lower frequency's that I will have to investigate.
I'll do a comparison with Brian Davies Click-Repair and see if it's real or imagined
@Pano the aforementioned Click-Repair does real-time declicking.
It's shareware but has a trial. To date it has been my preferred declicker and well worth the cost.
Resurrect your old recordings | Audio Restoration | Brian Davies