I have noticed something peculiar about the Rx7 azimuth corrector. I recently transferred a late-1950s mono LP to digital. As always, I made a "stereo" transfer, fed it through the Rx7 azimuth corrector, and then summed the two channels to mono. My initial "stereo" transfer looks really good on the phase scope in Sound Forge. But, after sending the file (one LP side) through the Rx7 azimuth corrector, my Sound Forge phase scope showed that the first 30 seconds or so of the first band had been turned into fake stereo - what was an excellent Lissajous now had a fair amount of stereo spread in it before the azimuth corrector finally locked in. After that, the rest of that side was fine.
I tried this on a stereo dub of a full-track mono tape and had no such problem. I have a file of a stereo transfer I made of a mono tape, several years ago, where I deliberately misaligned the head, to see if the azimuth corrector was working. The Rx7 azimuth corrector had no problem with it - it brought the two channel in right from the start, creating a perfect Lissajous. Warning: don't use the azimuth corrector as an excuse to be sloppy with head alignment - I simply did this as an experiment.
So, I suspect that the LP groove noise is what's causing the problem. I put the stereo file through a high-pass filter, to get rid of infrasonic groove noise, which always do when transferring an LP, but that doesn't fix the problem. Infrasonic noise is not what's fouling up the azimuth corrector.
The "fix" is to clone the first band of the record, so it appears twice in the file. Once the azimuth corrector hits the repeat of that band, it's locked in and the entire side is fine.
Incidentally, the Adobe Audition phase corrector has no such problem. And, I know it works, because, it corrected my deliberately misaligned tape head just as well as the Rx7 azimuth corrector.
IMHO - the lack of a phase scope in iZotope Rx is one of the program's biggest oversights. I suspect that a lot of people who are using Rx alone, without another program's phase scope to verify the results, may be having the same problem as me, without knowing it. I use Rx7 in conjunction with Sound Forge. With the Rx Connect VST plug-in, I can send all or part of a file over to Rx7, process it, and then send it back to Sound Forge, so the results are immediately verifiable with the SF phase scope.
Has anyone else experienced this? I mention this because running Rx7 azimuth on the cassette may or may not fix all of it. You need to check the results on a scope to see what you've done.
Audio Engineer Emeritus
The Crane School of Music
SUNY at Potsdam, NY 13676
From: Association for Recorded Sound Discussion List <[log in to unmask]> On Behalf Of Richard L. Hess
Sent: Wednesday, October 21, 2020 11:29 AM
To: [log in to unmask]
Subject: [EXTERNAL] Re: [ARSCLIST] Delayed Channels on Cassette Tapes
This message did not originate from SUNY Potsdam or one of its trusted senders. Do not open attachments, click on links, or provide your credentials if the source is suspicious.
John has provided a good answer, but I wonder where the delay came from.
If the azimuth is way off, summing the channels can cause mush while an individual channel will be passable, but not great. Delaying one channel is actually how the "azimuth correction" tools work. They only adjust azimuth based on delay. The slope of the notches is too steep to reliably recover much by using EQ without adding noise.
Also, if it were recorded on an 8-track cassette machine like a TASCAM 238, that has staggered heads, but I don't know how those would align with a stereo head. You can see the drawing here:
Also, if these are stereo recordings, if the mics were not coincident, then there will be delays between the channels which can result in mush when summed, but that will be different for each discrete sound source in the recording.
On 2020-10-21 10:21 a.m., Chris Brady wrote:
> John - great - thank you. I'll try all of this. I don't think that its
> print through because the issue is consistent. Chris B.
> On 21/10/2020, John Gledhill <[log in to unmask]> wrote:
>> Forgot to add - insert the measure delay into the start of the
>> preceding channel
>> I doubt it is a micro second -
>> If the delay is constant here is what you can do Split the stereo
>> track to mono use "analyze ->splot spectrum-and use the
>> autocorrelation get rid of the grid if the delay is constant you
>> should see a sharp peak export the date and you can zero in on the
>> delay with the largest peak - artificially 0.1 second in the sample I
>> If the delay is not constant the peak will be smeared so pic the
>> midpoint or throw one channel away or save it separately if it is
>> smeared over too wide a time distribution
>> On 10/21/2020 8:34 AM, Chris Brady wrote:
>>> We are digitising some cassette tapes using Audacity.. A batch of
>>> them are stereo, however they have exaggerated separation of the
>>> channels (perhaps they need normalisation?), and one channel is a
>>> microsecond behind the other. We don't actually need stereo, amd
>>> have tried to merge the channels into mono. But this sounds dreadful
>>> - the speech part sounds OK, but the music is very 'echo-ie).
>>> Another batch have delays from one channel to the other measuring in
>>> seconds. How can we time-shift one channel to match the other one?
>>> Thanks - Chris B.
>> John Gledhill
>> BIT WORKS Inc.
>> 905 881 2733
>> [log in to unmask]
Richard L. Hess email: [log in to unmask]
Aurora, Ontario, Canada 647 479 2800
Track Format - Speed - Equalization - Azimuth - Noise Reduction Quality tape transfers -- even from hard-to-play tapes.