Sign in with
Sign up | Sign in
Your question

Automatic Glitch Checker-Forer

Last response: in Home Audio
Share
Anonymous
July 29, 2005 10:01:12 PM

Archived from groups: rec.audio.pro (More info?)

I'd like to do some testing to see how many tracks I can record
glitch-free for extended periods of time. What I'd like to do is
connect an oscillator up to all the inputs (lets's be conservative and
say eight, but it doesn't matter unless I run out of disk space), put
all the tracks into Record, and then go fishing for an hour or so.

I don't want to listen to eight hours of sine wave to see if there are
any crackles or mutes. I wonder if there's some way to analyze the
files with software to see if there are any gaps, snaps, crackles, or
pops. I suppose that in theory those should shop up on a spectrum
display as something other than a line at the frequency of the
oscillator, but I suspect that in practice the resolution isn't going
to be good enough to show a 10 ms glitch.



--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 2:52:31 AM

Archived from groups: rec.audio.pro (More info?)

On 29 Jul 2005 18:01:12 -0400, mrivers@d-and-d.com (Mike Rivers)
wrote:


>I'd like to do some testing to see how many tracks I can record
>glitch-free for extended periods of time. What I'd like to do is
>connect an oscillator up to all the inputs (lets's be conservative and
>say eight, but it doesn't matter unless I run out of disk space), put
>all the tracks into Record, and then go fishing for an hour or so.
>
>I don't want to listen to eight hours of sine wave to see if there are
>any crackles or mutes. I wonder if there's some way to analyze the
>files with software to see if there are any gaps, snaps, crackles, or
>pops. I suppose that in theory those should shop up on a spectrum
>display as something other than a line at the frequency of the
>oscillator, but I suspect that in practice the resolution isn't going
>to be good enough to show a 10 ms glitch.

Would recording silence affect the process you're testing for?
If not, record silence and look for spikes visually.

Sorry, I don't have a better answer.
Good fortune,

Chris Hornbeck
Anonymous
July 30, 2005 3:16:05 AM

Archived from groups: rec.audio.pro (More info?)

Mike, there was an app called "Wave Repair" that I used for
a similar task some years ago. It does interactive
correction of glitches and allows you to do
something/nothing with each and then search for the next one
until end of file.

Not sure if it is still around or not, Google probably knows.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein
Anonymous
July 30, 2005 4:31:06 AM

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1122667103k@trad...
>
> I don't want to listen to eight hours of sine wave to see if there are
> any crackles or mutes. I wonder if there's some way to analyze the
> files with software to see if there are any gaps, snaps, crackles, or
> pops. I suppose that in theory those should shop up on a spectrum
> display as something other than a line at the frequency of the
> oscillator, but I suspect that in practice the resolution isn't going
> to be good enough to show a 10 ms glitch.
>

Mike, if you're recording an analog signal there's no way a computer program
(that I know of) could look and tell to make sure it was recorded correctly
(like you could if you had a digital copy to compare to for instance). Since
even a single sample wrong can make a pop I don't know what the answer would
be. I like Chris' idea of recording silence. At the very least you could use
something like Soundforge then to look for the pops/levels for you (but
still wouldn't be a guarantee). I believe a program could be written to do
it if you recorded a sine wave (if the program knows the frequency of the
sine wave it should be able to check each sample against the next to see if
it's in the range it should be) but I don't know of one already in
existence.
Anonymous
July 30, 2005 4:31:07 AM

Archived from groups: rec.audio.pro (More info?)

"Ricky Hunt" wrote ...
> ...I like Chris' idea of recording silence. At the very least you could
> use something like Soundforge then to look for the pops/levels for you
> (but still wouldn't be a guarantee).

Alas, it would not show the kinds of "drop-out" errors where the
samples go to zero (from wherever they were supposed to be).
Recording silence completely masks this problem, and it is a
significant one, IMHO.
Anonymous
July 30, 2005 6:11:32 AM

Archived from groups: rec.audio.pro (More info?)

On Fri, 29 Jul 2005 18:05:39 -0700, "Richard Crowley"
<richard.7.crowley@intel.com> wrote:

>"Ricky Hunt" wrote ...
>> ...I like Chris' idea of recording silence. At the very least you could
>> use something like Soundforge then to look for the pops/levels for you
>> (but still wouldn't be a guarantee).
>
>Alas, it would not show the kinds of "drop-out" errors where the
>samples go to zero (from wherever they were supposed to be).
>Recording silence completely masks this problem, and it is a
>significant one, IMHO.

Then Mike's original idea of recording parallel sine waves
seems the best bet. They can be duplicated as needed and
data-file-compared.

Very interesting meta-thingy; thanks,

Chris Hornbeck
Anonymous
July 30, 2005 6:22:52 AM

Archived from groups: rec.audio.pro (More info?)

Hey, Mike, how have you been?

I would try and notch out the sinewave during playback, using a high Q
filter. Then simply monitor the peak residual noise after the filter.
Any jumps in the level will equate to glitches. 10 mS should be easy
to catch with a peak-hold meter.

Better yet, assuming this is digital and has a very stable time base,
you could null out the sine with an antiphase sine, in lieu of the
notch filter. This would provide a more symmetrical response to both
noise burst and drop-out conditions.

Let me know if you need any help designing this.

Ken Kantor
Tymphany
Anonymous
July 30, 2005 6:23:11 AM

Archived from groups: rec.audio.pro (More info?)

On Fri, 29 Jul 2005 22:52:31 GMT, Chris Hornbeck
<chrishornbeckremovethis@att.net> wrote:

>On 29 Jul 2005 18:01:12 -0400, mrivers@d-and-d.com (Mike Rivers)
>wrote:
>
>
>>I'd like to do some testing to see how many tracks I can record
>>glitch-free for extended periods of time. What I'd like to do is
>>connect an oscillator up to all the inputs (lets's be conservative and
>>say eight, but it doesn't matter unless I run out of disk space), put
>>all the tracks into Record, and then go fishing for an hour or so.
>>
>>I don't want to listen to eight hours of sine wave to see if there are
>>any crackles or mutes. I wonder if there's some way to analyze the
>>files with software to see if there are any gaps, snaps, crackles, or
>>pops. I suppose that in theory those should shop up on a spectrum
>>display as something other than a line at the frequency of the
>>oscillator, but I suspect that in practice the resolution isn't going
>>to be good enough to show a 10 ms glitch.

I can't think of anything offhand that doesn't involve programming,
or perhaps the use of Matlab (and it's, uh, programming language), but
yes, there's surely SOMETHING that can do what you want, the question
is, is it as automatic as you want it to be?

Well, wait a sec, you probably have a parametric filter... set it
on a very sharp notch for the tone frequency. Make a short (several
seconds) recording of the tone, with a wave editor zoom in and cut out
ONE sample (go ahead and cut an increasing number of samples (2, 3, 4,
5, 6, 7, 8) in different places to make sure they all get detected at
the output). Play it back and see if there's a measurable 'glitch' in
the notch filter's output at each place where (a) sample(s) was(/were)
cut.
Record the output of the filter to another computer (such as your
laptop, a regular soundcard should be enough), and do the above test.
You should see a flat line (or the sine wave at a LOW level), with
whatever 'signal' you have recorded at maybe -10dBFS, and something
that extends above the signal or noise if there was a glitch. Looking
at that with an editor, even with the zoom out covering an hour, and
the vertical gain scaled to show the noise (maybe 1/4 full display),
even one sample of glitch should show up easily. You could only play
two channels at once into the laptop, and it would take however long
to (just thought of something else, but don't want to delete above)...

After you've recorded everything, you can use a plug-in filter to
notch out the tone on each channel, and bounce each track through a
separate instance of the filter to a new track. Do this part off-line
so it operates at full speed but doesn't rely on being real-time so
won't add its own glitches. (Perhaps go fishing again). Look at all
the newly bounced tracks just as I was describing for the laptop. Any
wave editing software will display as little as a 1-sample signal
above the noise as a vertical glitch on the screen, even with several
hours condensed to one screen width (the way envelopes are displayed
in these editors, peaks don't disappear when you zoom out, definitely
a Good Thing). Not completely automatic, but not far from it.

[ "It's supposed to be automatic but actually you have to press
this button." from "Stand on Zanzibar" by John Brunner, and someone
also attributes it to Firesign Theatre. ]

Use a tone that is NOT a submultiple of the sampling rate - if the
tone is 7350 Hz and you're recording at 44,100Hz, dropping six samples
will look just like dropping zero samples, and you won't see it. Make
it an irrational fraction, and just to be sure, test as I wrote in the
second paragraph , deleting however many different sections of samples
you think would make a good test. If snipping a certain number of
samples results in no glitch, change the tone frequency and try again.

You would have to have a rather slow change in output level for
something not to get detected, but that doesn't happen with digital
systems (as far as we know...), so this should work.

I wonder if DAW developers have ever done anything like this (as it
seems they might have reason to do). If there's any info on this sort
of thing that's available to the general public, it would likely be
related to Audacity:

http://audacity.sourceforge.net

>Would recording silence affect the process you're testing for?
>If not, record silence and look for spikes visually.

That's not going to do what he wants - if there's 10 mS or 10
seconds of dropped samples, it'll still be a straight horizontal line.

>Sorry, I don't have a better answer.
>Good fortune,
>
>Chris Hornbeck

-----
http://www.mindspring.com/~benbradley
Anonymous
July 30, 2005 10:06:44 AM

Archived from groups: rec.audio.pro (More info?)

In article <fjcle1d280pnldv3tssb048be1bmo4vth5@4ax.com> chrishornbeckremovethis@att.net writes:

> Would recording silence affect the process you're testing for?
> If not, record silence and look for spikes visually.

I guess it depends on the nature of the glitch, and I'm no glitch
expert. If it actually generates noise, then that shouldn't be too
difficult to see. But if it mutes (and the "glitch" sound is a result
of chopping off part of an otherwise smooth waveform) then you
couldn't tell that from your intentionally recorded silence.


--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 12:57:02 PM

Archived from groups: rec.audio.pro (More info?)

Chris Hornbeck <chrishornbeckremovethis@att.net> wrote:

> Would recording silence affect the process you're testing for?
> If not, record silence and look for spikes visually.

Or record the sine, subtract a perfect (generated, not recorded) phase
reversed sine and look for problems.


--
lars farm // http://www.farm.se
lars is also a mail-account on the server farm.se
aim: larsfarm@mac.com
Anonymous
July 30, 2005 2:33:07 PM

Archived from groups: rec.audio.pro (More info?)

In article <94ole1pvjdhc76s5a6hefafnp192tqc4vq@4ax.com> chrishornbeckremovethis@att.net writes:

> Then Mike's original idea of recording parallel sine waves
> seems the best bet. They can be duplicated as needed and
> data-file-compared.

I suppose there might be some value to comparing one file to each of
the others to see if there are differences. I wonder if there would be
a problem with synchronization at the sample level, though. While they
would each start with Sample #1, there must be some sort of
multiplexing going on with a multi-channel interface so that the first
sample of each file might be at a different point on the waveform.
Therefore the first (and I assume subsequent) sample would represent a
slightly different voltage because it was taken at a different time,
and would therefore no two files would have the same series of
numbers.



--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 2:33:07 PM

Archived from groups: rec.audio.pro (More info?)

In article <9gmle1tu6ehh6suatntgv5kcqc7sts5cku@4ax.com> ben_nospam_bradley@frontiernet.net writes:

[fairly complex but somewhat comprehendable suggestion snipped]


> I wonder if DAW developers have ever done anything like this (as it
> seems they might have reason to do).

Heck no! They let the customers do the testing, and when they find a
limit, assume it's because of their computer (which it almost
certainly is). <g>


--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 2:33:08 PM

Archived from groups: rec.audio.pro (More info?)

In article <1h0iebl.1mh8tcrqfdknaN%see.bottom.of.page.for.lars@farm.se> see.bottom.of.page.for.lars@farm.se writes:

> Or record the sine, subtract a perfect (generated, not recorded) phase
> reversed sine and look for problems.

I had thought about something like that - using a computer-generated
sine wave as the source, sending it out an analog output, and then
back into the multiple analog inputs. But in order to assure that
there wasn't a clock synchronization issue, the source would have to
be played on the same computer as was doing the recording. While that
might be a possible test, it would take some computer resources to
play the source, and thus affect the number of tracks that could be
recorded.



--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 2:33:09 PM

Archived from groups: rec.audio.pro (More info?)

In article <1122715372.430217.92810@f14g2000cwb.googlegroups.com> kkantor@gmail.com writes:

> Hey, Mike, how have you been?

Hi, Ken - Things have been slow. That's why I'm thinking about stuff
like this. <g>

> I would try and notch out the sinewave during playback, using a high Q
> filter. Then simply monitor the peak residual noise after the filter.
> Any jumps in the level will equate to glitches. 10 mS should be easy
> to catch with a peak-hold meter.

That would necessitate playing back the track, which would be a
real-time process. And since problems with glitching are as likely
(maybe even more so) to occur in playback of a perfectly clean
recording as they are in recording, if I found a glitch, I'd have to
re-test to see if it was a recorded glitch or a played glitch.

I was dreaming about some sort of algorithm that would look for
unexpected rate of change from one sample to the next. A glitch would
probably do the best it could to violate the Nyquist criteria and
change value too fast for the sample rate.



--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 2:33:10 PM

Archived from groups: rec.audio.pro (More info?)

In article <dcf5v501it4@enews4.newsguy.com> arcane@arcanemethods.com writes:

> Mike, there was an app called "Wave Repair" that I used for
> a similar task some years ago. It does interactive
> correction of glitches and allows you to do
> something/nothing with each and then search for the next one
> until end of file.

Thanks. I found the program and I'll look it over. It seems like the
"interactive click detector" might work. I'll make a few glitches and
see what it finds.

[Later]
I think this program might do the trick. I haven't figured out the
horizontal scaling yet, but I inserted a 1-sample mute in the
middle of a short 1 kHz file, opened it with with Waver Repair,
and by golly, the opening display showed the glitch, plain as
could be. It looked like a sine wave with a glitch in it, only according
to Wave Repair's time scale, the period (time between peaks)
on the screen was about 13 seconds, not 1 millisecond. The
glitch was displayed at the correct time, however.

The important part was that I was able to see the glitch. I'll have
to experiment with longer files (this one was about 2 minutes)
with multiple glitches to see how the display looks, but it seems
to be a pretty good lead. This was a stereo file (an old test I
had lying around). I'll have to see what a mono file looks like, if
it even knows what that is. The purpose of the program seems
to be to find and fix clicks in a transfer from a phonograph
record.

[Later still]
Bummer - it doesn't work on a mono file. I suppose that a test
recording, say, 4 stereo files rather than 8 mono files, would
still give me a good sense of the robustness of the recording,
but it might not be exactly the same as the real thing.

Oh, well, that's the problem with digital - you can't always get
what you want.



--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 30, 2005 10:41:57 PM

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1122718313k@trad...
>
> I suppose there might be some value to comparing one file to each of
> the others to see if there are differences. I wonder if there would be
> a problem with synchronization at the sample level, though. While they
> would each start with Sample #1, there must be some sort of
> multiplexing going on with a multi-channel interface so that the first
> sample of each file might be at a different point on the waveform.
> Therefore the first (and I assume subsequent) sample would represent a
> slightly different voltage because it was taken at a different time,
> and would therefore no two files would have the same series of
> numbers.
>

That's the thing. It would be definitely (IMO) be possible if you wrote a
program specifically do what you're wanting. I just don't know of any tools
already in existence to do it. Also, if there were some system glitch that
caused them all to go wonky at the same bit at the same time comparing one
file to another would be useless.
Anonymous
July 31, 2005 12:58:29 AM

Archived from groups: rec.audio.pro (More info?)

On 29 Jul 2005 18:01:12 -0400, mrivers@d-and-d.com (Mike Rivers)
wrote:

>
>I'd like to do some testing to see how many tracks I can record
>glitch-free for extended periods of time. What I'd like to do is
>connect an oscillator up to all the inputs (lets's be conservative and
>say eight, but it doesn't matter unless I run out of disk space), put
>all the tracks into Record, and then go fishing for an hour or so.
>
>I don't want to listen to eight hours of sine wave to see if there are
>any crackles or mutes. I wonder if there's some way to analyze the
>files with software to see if there are any gaps, snaps, crackles, or
>pops. I suppose that in theory those should shop up on a spectrum
>display as something other than a line at the frequency of the
>oscillator, but I suspect that in practice the resolution isn't going
>to be good enough to show a 10 ms glitch.


In Sound Forge, you have a "Find" function containing a "Find Glitch"
setup. Deepending of sensitivity and slope settings, it stops the
cursor right at the glitch. A considerable time-saver!

Edi Zubovic, Crikvenica, Croatia
Anonymous
July 31, 2005 2:58:22 AM

Archived from groups: rec.audio.pro (More info?)

Mike Rivers <mrivers@d-and-d.com> wrote:

> In article <1h0iebl.1mh8tcrqfdknaN%see.bottom.of.page.for.lars@farm.se>
> see.bottom.of.page.for.lars@farm.se writes:
>
> > Or record the sine, subtract a perfect (generated, not recorded) phase
> > reversed sine and look for problems.
>
> I had thought about something like that - using a computer-generated
> sine wave as the source, sending it out an analog output, and then
> back into the multiple analog inputs. But in order to assure that
> there wasn't a clock synchronization issue, the source would have to
> be played on the same computer as was doing the recording. While that
> might be a possible test, it would take some computer resources to
> play the source, and thus affect the number of tracks that could be
> recorded.

If you record a sine wave at say 1 kHz you can predict what it should
look like at any point in time. This prediction can be done any time.
You don't have to record the reference signal. You can generate it
afterwards in the DAW. All it takes is that you manually allign the
first cykle. As long as the recorded signal = the reference the
difference equals zero (a straight line). If there is a clock issue the
generated signal will become out of phase with the recorded and the
difference is no longer zero. Should be easy to detect by simple
inspection. Other errors as drop-outs will become shorter or longer
bursts of non-zero, perhaps detectable by a "click detector" as the one
in Soundtrack pro if not by eye.



--
lars farm // http://www.farm.se
lars is also a mail-account on the server farm.se
aim: larsfarm@mac.com
Anonymous
July 31, 2005 3:07:56 AM

Archived from groups: rec.audio.pro (More info?)

Mike Rivers <mrivers@d-and-d.com> wrote:

> That would necessitate playing back the track, which would be a
> real-time process.

DAW's often have a find peak level and its positi-on... A perfect
recording should result in zero level after the treatment. Any non zero
would be a recording defect and also a peak for the DAW to find, no?


--
lars farm // http://www.farm.se
lars is also a mail-account on the server farm.se
aim: larsfarm@mac.com
Anonymous
July 31, 2005 3:37:24 AM

Archived from groups: rec.audio.pro (More info?)

Mike Rivers wrote:

> [Later still]
> Bummer - it doesn't work on a mono file.

Really? That just doesn't seem right somehow. Back when I
was using it (can't remember if I ever did mono; probably
not) the author was quite available for interraction. Not
sure any more.


Bob
--

"Things should be described as simply as possible, but no
simpler."

A. Einstein
Anonymous
July 31, 2005 3:57:52 AM

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1122667103k@trad...
>
> I'd like to do some testing to see how many tracks I can record
> glitch-free for extended periods of time. What I'd like to do is
> connect an oscillator up to all the inputs (lets's be conservative and
> say eight, but it doesn't matter unless I run out of disk space), put
> all the tracks into Record, and then go fishing for an hour or so.
>
> I don't want to listen to eight hours of sine wave to see if there are
> any crackles or mutes. I wonder if there's some way to analyze the
> files with software to see if there are any gaps, snaps, crackles, or
> pops. I suppose that in theory those should shop up on a spectrum
> display as something other than a line at the frequency of the
> oscillator, but I suspect that in practice the resolution isn't going
> to be good enough to show a 10 ms glitch.
>


You could invert the polarity of half of the sine waves, do a mixdown to
mono, and then check to see what's left. Idealy, everything will have
disappeared, and if one of the tracks has dropped out, there should be
signal spike there. However, if it so happens that an even number tracks
drop out simutaniously, this test is useless.

Ron
Anonymous
July 31, 2005 10:08:43 AM

Archived from groups: rec.audio.pro (More info?)

Lars Farm wrote:

> Mike Rivers <mrivers@d-and-d.com> wrote:
>
> > That would necessitate playing back the track, which would be a
> > real-time process.
>
> DAW's often have a find peak level and its positi-on... A perfect
> recording should result in zero level after the treatment. Any non zero
> would be a recording defect and also a peak for the DAW to find, no?
>
> --
> lars farm // http://www.farm.se
> lars is also a mail-account on the server farm.se
> aim: larsfarm@mac.com

Thus the key to a simple answer, phase shift (time delay) the
track by 180 degrees and add the two. Any non-zero is your
error...

Later...

Ron Capik
--
Anonymous
July 31, 2005 10:30:18 AM

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1122667103k@trad

> I'd like to do some testing to see how many tracks I can
> record glitch-free for extended periods of time. What I'd
> like to do is connect an oscillator up to all the inputs
> (lets's be conservative and say eight, but it doesn't
> matter unless I run out of disk space), put all the
> tracks into Record, and then go fishing for an hour or
> so.

> I don't want to listen to eight hours of sine wave to see
> if there are any crackles or mutes. I wonder if there's
> some way to analyze the files with software to see if
> there are any gaps, snaps, crackles, or pops. I suppose
> that in theory those should shop up on a spectrum display
> as something other than a line at the frequency of the
> oscillator, but I suspect that in practice the resolution
> isn't going to be good enough to show a 10 ms glitch.

When you have glitches, file sizes will generally come out
wrong or inconsistent. There's two cases - one where the
glitches are in the middle of the file, and one where they
come at the ends. Glitches at start up or in the middle can
cause tracks to become unsynched. Glitches at the end are
benign.

IME the most indicative signal for audibly detecting lost
data is a low frequency sine wave - say 100 Hz.

The most powerful automated tools I've found for finding
glitches are the the file comparison tools, such as is found
in both CDEX and EAC. Both programs will resynch so that a
little dropped data does not get blown out of perspective.
OTOH, both programs create comprehensive reports down to the
sample level.

If you record N tracks of a 100 Hz sine wave and compare
them, all N will be identical to each other. They will also
have the same length.
Anonymous
July 31, 2005 11:13:17 AM

Archived from groups: rec.audio.pro (More info?)

"Ron Capik" <r.capik@worldnet.att.net> wrote in message
news:42EC6A4A.86AECE92@worldnet.att.net...
> Thus the key to a simple answer, phase shift (time delay) the
> track by 180 degrees and add the two. Any non-zero is your
> error...

So simple, it's brilliant. :-)

My thought was just a clarification of other suggestions: Use a parametric
eq to notch out the test frequency, and then bounce to a new track. Any
glitches will now be easily visible in the waveform display.
Anonymous
July 31, 2005 2:26:26 PM

Archived from groups: rec.audio.pro (More info?)

In article <dchrj306ne@enews3.newsguy.com> arcane@arcanemethods.com writes:

> > Bummer - it [Wave Repair] doesn't work on a mono file.
>
> Really? That just doesn't seem right somehow.

Maybe earlier versions did. When trying to open a mono file, it comes
up with a dialog box saying "This is not a 44.1 or 48 kHz 16 Bit
stereo WAV file" and proceeds to display the header info. The parts
that disagree with the "should be" are number of channles, the number
of bytes/second, and the number of bytes per sample.

So, would I be perforning a reasonably equivalent recording test by
recording four stereo files rather than eight mono files? I like what
Wave Repair does (and I like not having to buy Sound Forge or
something else that I don't have) and I like this approach better than
the inverting and summing suggestions because this allows me to look
at each individual recording rather than determining that two
recordings are identical.

By the way, Wave Repair seems to think there isn't a lot of difference
between banjo playing and clicks. A lot of people here have the same
opinion, just not expressed so elegantly. ;) 



--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
July 31, 2005 5:17:42 PM

Archived from groups: rec.audio.pro (More info?)

Tom Cooper wrote:

> "Ron Capik" <r.capik@worldnet.att.net> wrote in message
> news:42EC6A4A.86AECE92@worldnet.att.net...
> > Thus the key to a simple answer, phase shift (time delay) the
> > track by 180 degrees and add the two. Any non-zero is your
> > error...
>
> So simple, it's brilliant. :-)

The proposed technique does have drawbacks. First off, all glitches will be
mirrored one half cycle away and drop outs will only show for one half cycle
at the start and end of the drop out period. Also, slow amplitude drift will
not
be seen. Slipping a few more odd half cycles will increase the drop out
sensitivity at the expense of reduced localization.

Later...

Ron Capik
--
Anonymous
August 2, 2005 7:13:29 AM

Archived from groups: rec.audio.pro (More info?)

OK, I am just getting what you are trying to do, I think...

The steady-state sinewaves can each be notched out, since they are each
fully described by a single, stable frequency. After the notch filter,
you put a fast, wide(ish) band, peak detecting voltmeter circuit,
attached to a counter, an alarm bell, etc. When anything alters the
steady state of the sinewave... a drop out, or a noise burst, or a
discontinuity, there will be spectral components associated with it
that will pass through the notch filter and register on the VM.

-k
Anonymous
August 3, 2005 12:54:18 PM

Archived from groups: rec.audio.pro (More info?)

Could the glitches you speak of be used to trigger a midi patch? If so, map
the output to a long instrument sample and record that as well. It will
likely involve a 2nd pass to record the output of the sampler. My lotech
workaround!

Rick Hollett
"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1122667103k@trad...
>
> I'd like to do some testing to see how many tracks I can record
> glitch-free for extended periods of time. What I'd like to do is
> connect an oscillator up to all the inputs (lets's be conservative and
> say eight, but it doesn't matter unless I run out of disk space), put
> all the tracks into Record, and then go fishing for an hour or so.
>
> I don't want to listen to eight hours of sine wave to see if there are
> any crackles or mutes. I wonder if there's some way to analyze the
> files with software to see if there are any gaps, snaps, crackles, or
> pops. I suppose that in theory those should shop up on a spectrum
> display as something other than a line at the frequency of the
> oscillator, but I suspect that in practice the resolution isn't going
> to be good enough to show a 10 ms glitch.
>
>
>
> --
> I'm really Mike Rivers (mrivers@d-and-d.com)
> However, until the spam goes away or Hell freezes over,
> lots of IP addresses are blocked from this system. If
> you e-mail me and it bounces, use your secret decoder ring
> and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
August 3, 2005 4:43:39 PM

Archived from groups: rec.audio.pro (More info?)

In article <8LadnWuuzd_HNG3fRVn-2A@rogers.com> rhollett@nl.rogers.com writes:

> Could the glitches you speak of be used to trigger a midi patch?

They're probably too short. It would require some intermediate
processing, which would almost certainly involve detecting the glitch.
And once it's detected, you could stop right there.


--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
Anonymous
August 6, 2005 4:18:46 AM

Archived from groups: rec.audio.pro (More info?)

Apologies for entering this thread late, but I've only just seen it. I
am the author of Wave Repair, and can offer a few comments. I'm sure
that Mike has already found a solution, but I'll just pitch in in case
it helps anyone else...

Mike Rivers wrote:
> I think this program might do the trick. I haven't figured out the
> horizontal scaling yet, but I inserted a 1-sample mute in the
> middle of a short 1 kHz file, opened it with with Waver Repair,
> and by golly, the opening display showed the glitch, plain as
> could be. It looked like a sine wave with a glitch in it, only according
> to Wave Repair's time scale, the period (time between peaks)
> on the screen was about 13 seconds, not 1 millisecond. The
> glitch was displayed at the correct time, however.

Wave Repair's method for displaying long waveforms is in fact not
conducive to spotting very short glitches visually. The fact that it
showed up on this occasion is probably down to luck. You'll find that
Adobe Audition has a better display for this purpose.

However, given that you're looking for discontinuities in sine waves,
Wave Repair's automatic click detection facility should find them very
easily. Just set it up to look for "instant rise" spikes with a fairly
large relative amplitude.

> Bummer - it doesn't work on a mono file. I suppose that a test
> recording, say, 4 stereo files rather than 8 mono files, would
> still give me a good sense of the robustness of the recording,
> but it might not be exactly the same as the real thing.

Someone else said that maybe earlier versions did. This is not the
case; Wave Repair has always only ever worked on stereo 16-bit WAV
files (44.1 or 48kHz). It's primarily intended as a restoration tool
for recordings of vinyl records, and even if you're doing a mono record
it's still better to record in stereo, do the restoration, and finally
mix down to mono.

- Clive
Anonymous
August 6, 2005 2:25:34 PM

Archived from groups: rec.audio.pro (More info?)

In article <1123312726.066147.66950@g49g2000cwa.googlegroups.com> google@delback.co.uk writes:

> Apologies for entering this thread late, but I've only just seen it. I
> am the author of Wave Repair, and can offer a few comments. I'm sure
> that Mike has already found a solution, but I'll just pitch in in case
> it helps anyone else...

Thanks for jumping in. At this point, it's mostly a matter of
background curiosity, but Wave Repair seems to be the best bet once I
make up my so-called mind that this is an experiment and not a lab
measurement, and I can live with its limitations. Thanks for the
explanation of the scaling. It's indeed very easy to see the glitch.

> Wave Repair has always only ever worked on stereo 16-bit WAV
> files (44.1 or 48kHz). It's primarily intended as a restoration tool
> for recordings of vinyl records

That's pretty clear from the description of the program. No need to
re-write it on account of me. <g> I was a bit surprised from the
responses to my query that I seem to be alone in trying to test for
glitching in a digital recording process. It would be comforting to
know (before taking a system out on the road) that it's set up well
enough so that it isn't prone to making occasional errors.


--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo
!