In message , Don Pearce
writes
On Wed, 10 Sep 2014 09:19:44 +0100, "Brian Gaff"
wrote:

Sometimes playing it backwards for detection actually works better than
forwards.
Brian

In the digital world, the idea of playing in any direction has no
meaning - you don't detect steep edges that way, you differentiate and
look at amplitude.

Isn't that the analogue way too?


--
Ian

On Wed, 10 Sep 2014 09:19:44 +0100, "Brian Gaff"
wrote:

Sometimes playing it backwards for detection actually works better than
forwards.


Quite likely to be true in most cases. Although CoolEdit Pro will
allow you to reverse the wav file to facilitate this, it's not clear
as to whether or not this would improve matters (the declicking
algorithm may be using this method in the first place - possibly even
a combination of bacwards and forwards scanning).

However, since I can't recall seeing a description of the declicking
algorithm using such a tactic, it'll certainly be worth trying out.

--
J B Good

On Wed, 10 Sep 2014 09:13:21 GMT, (Don Pearce) wrote:

On Wed, 10 Sep 2014 09:19:44 +0100, "Brian Gaff"
wrote:

Sometimes playing it backwards for detection actually works better than
forwards.
Brian

In the digital world, the idea of playing in any direction has no
meaning - you don't detect steep edges that way, you differentiate and
look at amplitude.


What he said! :-)

It rather depends on the sophistication of the 'declicking' alorithm.
Processing the wav file in reverse may help in the case of a primitive
click filter algorithm but I'd anticipate a properly sophisticated
algorithm possibly becoming confused by a reversed wav file.

However, if you can't find a description of the declicking algotithm
that describes the process in enough detail to determine this possible
'gotcha' with reversed files, it's worth testing before discounting
such a strategy. It's not as if it's a difficult test to make so worth
a shot.
--
J B Good

On 07/09/14 16:44, Jim Lesurf wrote:
In article , Don Pearce
wrote:
On Sun, 07 Sep 2014 14:33:16 GMT, (Don Pearce) wrote:

On Sun, 07 Sep 2014 15:03:37 +0100, Jim Lesurf
wrote:



Jim, I don't know if you can watch Youtube, but here's a short clip on
the manual repair process.

So far I've not bothered with YouTube TBH.

However the problem I'm interested in is any algorithm for *finding* (and
listing the positions of) clicks and ticks. The repair is the easy part,
although I'd always do that manually so I can the waveform before and
after. Sometimes a careless repair is worse that the original. :-)

FWIW I've spent many happy hours recently doing just this. Like you I
suspect I trust only my ear as the final arbiter of a click and auto
click removers not at all.

Initially I tried overwriting, actually with EZpatch rather than Repair,
but about half the time that just turned a click into a thud. So I just
redrew the damaged bits manually.

I found you get to recognise the shapes that need repair and on a couple
of really noisy records I didn't bother listening, just scrolled through
looking for the shapes - fortunately just a couple of records. I found a
feature of Audacity is that if you scroll forward at too much zoom it
keeps on scrolling for an indeterminate distance, you need to be 3 zooms
out from seeing the individual points (or sometimes 4, depending).

But it sure is a labour of love, I haven't spent quite so long in
proportion as you but then my standards may be lower.

Still I've resurrected stuff I haven't played for decades, recordings of
Menuhin, David Munrow and my ancient trad jazz (mono, some 10" - yes 33
1/3 vinyl). Brilliant.

--
Dick Georgeson
Whenever you find that you are on the side of the majority, it is time
to reform. -- Mark Twain

In article , Johny B Good
wrote:
On Wed, 10 Sep 2014 09:19:44 +0100, "Brian Gaff"
wrote:

Sometimes playing it backwards for detection actually works better
than forwards.


Quite likely to be true in most cases. Although CoolEdit Pro will allow
you to reverse the wav file to facilitate this, it's not clear as to
whether or not this would improve matters (the declicking algorithm may
be using this method in the first place - possibly even a combination of
bacwards and forwards scanning).

In essence 'looking in the rear view mirror' is what my simple method does.
It fined the peak value in each successive block of data of a few tens of
milliseconds and checks to see if the 'current' block is much smaller than
the one before it. Sign of a rapidly ending 'event'.

But as I'd expected, it works for the obvious loud clicks, but can easily
be confused unless you set the 'trigger' levels high. In effect it doesn't
do much better than using Audacity and looking for spikes that stick well
clear of the rest of the waveform. It is useful as a quick estimate of how
many loud bangs are present, though.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

In article , rmg
wrote:
On 07/09/14 16:44, Jim Lesurf wrote:


But it sure is a labour of love, I haven't spent quite so long in
proportion as you but then my standards may be lower.

Well for almost all LPs I don't bother at all. For some I just take out the
loud explosions. Only for a few special items am I willing to spend hours
doing a 'search and desroy' of as many clicks as I can cope with! Too much
leads to madness... oops, sorry, too late. 8-]

Still I've resurrected stuff I haven't played for decades, recordings of
Menuhin, David Munrow and my ancient trad jazz (mono, some 10" - yes 33
1/3 vinyl). Brilliant.

Yes. I find Mono Jazz actually often works well. Many of the smaller
'ticks' are on just one groove wall. So when I convert to mono the click to
music ratio improves by about 5 or 6 dB. Hence often just removing the loud
bangs and converting to mono helps a lot. Alas, stereo recordings at lower
levels are more exposed to any small problems. :-/

BTW I've been told that my box of The Beatles Mono LPs should reach me
tomorrow. I'm hoping that they will be in better condition than the LPs EMI
used to churn out in the 1960s! Should be for the money! Rarely buy 'new'
LPs, but in this case I weakened and made an exception.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

ISTR that when I looked into this, about a decade ago now, I found
that at least some of the algorithms are based on Kalman filters:
http://www.cs.unc.edu/~welch/kalman/index.html
http://www.cs.unc.edu/~welch/media/pdf/kalman_intro.pdf

On Wed, 10 Sep 2014 13:35:17 +0100, Johny B Good
wrote:

However, since I can't recall seeing a description of the declicking
algorithm using such a tactic, it'll certainly be worth trying out.
--
================================================== =======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

On 2014-09-10, Jim Lesurf wrote:
In article , William Unruh
wrote:
On 2014-09-07, Jim Lesurf wrote:
[snip]

I understand the argument about RIAA being quasi-integrating, etc. Its one
of the reasons behind my thinking that looking at the first or second
derviative would help.

So use sox say to impliment the inverse RIAA, then use audacity to look
for those spikes, and remove them, then use the RIAA on the result.
Note that one could just take the derivative, but that would still leave
a finite spreading due to the treble/bass boost.

Wary of that because 'mending' a differential waveform might lead to a dc
offset problem when you re-integrate the result. So I'd use a dx/dt or

You could always put in a 50 or 30 Hz cutoff in the RIAA curve. Some
advocated that anyway. But those clicks put in a DC bias in the first
place.


d2x/d2t to *find* and list click locations. But do any editing on the
actual audio file recorded using RIAA. Avoids the problems of dealing with
the real response curve being rather complicated.

But since the click has been spread out all over hells half acre by
RIAA, that "fixing" either leaves loads of artifacts or also "fixes" a
bunch of the real signal as well.

The pre RIAA is the place to fix it.


Jim

In article , William Unruh
wrote:
On 2014-09-10, Jim Lesurf wrote:
In article , William Unruh


So use sox say to impliment the inverse RIAA, then use audacity to
look for those spikes, and remove them, then use the RIAA on the
result. Note that one could just take the derivative, but that would
still leave a finite spreading due to the treble/bass boost.

Wary of that because 'mending' a differential waveform might lead to a
dc offset problem when you re-integrate the result. So I'd use a dx/dt
or

You could always put in a 50 or 30 Hz cutoff in the RIAA curve. Some
advocated that anyway. But those clicks put in a DC bias in the first
place.

Erm. The mechanics and the RIAA don't pass down to dc. So what happens is a
decaying offset. The results shapes are pretty clear. In my case I'm using
a V15 in an old arm that has more mass than ideal. So the peak and fall at
LF is at very low frequency, but not dc.


d2x/d2t to *find* and list click locations. But do any editing on the
actual audio file recorded using RIAA. Avoids the problems of dealing
with the real response curve being rather complicated.

But since the click has been spread out all over hells half acre by
RIAA, that "fixing" either leaves loads of artifacts or also "fixes" a
bunch of the real signal as well.

The pre RIAA is the place to fix it.

Again, looking at the shapes I can see the effects. Adding the 'fix' just
puts in a plausible smooth interpolation anyway.

To deal with it in the way you suggest would require an accurate 'de-riaa'
that also precisely deals with the stylus and arm responses over the full
range down to almost dc. i.e. much lower than 10Hz or so. Even measuring
that isn't trivial. And it differs in the vertical and horizontal planes
anyway. So you'd also have to convert the L and R to V and H first.

So simply applying a reverse riaa preamp curve won't in practice be much
better than a simple integrator if your concern is LF spread.

Given that the mends I've made so far are generally inaudible except for
severe events that clearly lose the waveform anyway. I'm happy enough
despite the nice theory for preferring de-riaa. Life's too short. :-)

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On 2014-09-11, Jim Lesurf wrote:
In article , William Unruh
wrote:
On 2014-09-10, Jim Lesurf wrote:
In article , William Unruh


So use sox say to impliment the inverse RIAA, then use audacity to
look for those spikes, and remove them, then use the RIAA on the
result. Note that one could just take the derivative, but that would
still leave a finite spreading due to the treble/bass boost.

Wary of that because 'mending' a differential waveform might lead to a
dc offset problem when you re-integrate the result. So I'd use a dx/dt
or

You could always put in a 50 or 30 Hz cutoff in the RIAA curve. Some
advocated that anyway. But those clicks put in a DC bias in the first
place.

Erm. The mechanics and the RIAA don't pass down to dc. So what happens is a
decaying offset. The results shapes are pretty clear. In my case I'm using
a V15 in an old arm that has more mass than ideal. So the peak and fall at
LF is at very low frequency, but not dc.

Actually, the RIAA curve does go to DC. There was a very controvertial
proposal to put another zero/pole at 50Hz to comensate for the cutter
low freq resonance but the problem is that the cutters all have
different resonances to for some it would make thing worse.
Anyway, since your speakers cannot hear 30Hz, you could put it there--
the main thing is that the unRIAa and RIAA filter be complementary.

If the spike from the record is before the RIAA then the RIAA filter
will have spread it out all over the place, and "fixing" it after the
filter will leave all that spread out residual in place.



d2x/d2t to *find* and list click locations. But do any editing on the
actual audio file recorded using RIAA. Avoids the problems of dealing
with the real response curve being rather complicated.

But since the click has been spread out all over hells half acre by
RIAA, that "fixing" either leaves loads of artifacts or also "fixes" a
bunch of the real signal as well.

The pre RIAA is the place to fix it.

Again, looking at the shapes I can see the effects. Adding the 'fix' just
puts in a plausible smooth interpolation anyway.

To deal with it in the way you suggest would require an accurate 'de-riaa'
that also precisely deals with the stylus and arm responses over the full
range down to almost dc. i.e. much lower than 10Hz or so. Even measuring
that isn't trivial. And it differs in the vertical and horizontal planes
anyway. So you'd also have to convert the L and R to V and H first.

So simply applying a reverse riaa preamp curve won't in practice be much
better than a simple integrator if your concern is LF spread.

Agreed that the curve is problematic below 50Hz. But even at 200Hz the
sound is spread out over more than 200 time pixels (400 for 96K
sampling). That's a lot.



Given that the mends I've made so far are generally inaudible except for
severe events that clearly lose the waveform anyway. I'm happy enough
despite the nice theory for preferring de-riaa. Life's too short. :-)

It is cheap enough to try it. I agree that it may not be an improvement.
Even just a differentiator would be a
help (differentiate, fix, integrate) except you really have to make sure
you have enough dynamic range. Since that is 10 octaves or 60dB emphasis
of highs over lows, which is even larger than the 48dB of the RIAA
curve ( which would fit in another 8 bits that sox stores stuff at.)



Jim