LISTSERV mailing list manager LISTSERV 16.0

Help for ARSCLIST Archives


ARSCLIST Archives

ARSCLIST Archives


ARSCLIST@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ARSCLIST Home

ARSCLIST Home

ARSCLIST  April 2012

ARSCLIST April 2012

Subject:

Re: Recording_78rpm_records/analog vs digital eq

From:

George Brock-Nannestad <[log in to unmask]>

Reply-To:

Association for Recorded Sound Discussion List <[log in to unmask]>

Date:

Sat, 14 Apr 2012 00:01:36 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (177 lines)

From: Patent Tactics, George Brock-Nannestad



Hello,

I am just latching on to Don's mail - I absolutely agree, but I am not in 
agreement with a lot of what was written while I was away for a few days.

First of all, I have to admit that it is unlikely that any pre-amp should 
tolerate a spark at the input - Tom Fine's complaint. In such a case, a 
circuit consisting of properly biased germanium diodes or transistors would 
reduce the max input to + or - 200 mV. The effect of feedback loop saturation 
is a very real one, and those amps with the best stationary signal 
performance are frequently the worst to display this on very fast input. 
Headroom and short feedback loops are what we need.

I would have liked the discussion on analog vs. digital to have been a bit 
more informed, but on the other hand one cannot request any hardware and 
software user to have studied and understood a book like John Watkinson's 
'The Art of Digital Audio' in order to permit them to write on the ARSCLIST. 
For this reason we must be thankful for the many who have taken time to 
elucidate a point; in this patchwork manner the general knowledge will 
increase.

I am going to make a few notes that some will find boring, and I hope some 
will find faulty, because that will provoke them to express themselves as 
clearly as possible to correct me. The general problem is that sometimes 
something that is as clear as water to some is very murky to others, and the 
discussion does not take place in the same context - we all carry our own 
around with us.

Now, most of what we are dealing with is bandwidth. Bandwidth and time 
resolution are linked in the world of resistors, capacitors, and inductors, 
but not so where our hearing is concerned. For solid proof of this go to 
Milind Kunchur's webpage - they have been mentioned before on this list.

The so-called Nyquist criterion states that if you want to be able to 
reconstruct a signal from a sampled representation of it, you have to decide 
the highest frequency you want represented and then you have to sample at a 
rate that is at least twice the highest frequency. When you then reconstruct 
your signal by providing voltages at the sample rate according to the table 
of values that represents the audio signal, you will have your full bandwidth 
and dynamic range back, provided the resolution or bit-depth has been 
sufficient. It has been claimed that this stepwise presented waveform makes 
the signal unlistenable, but that is not the case, because you invariably 
smooth it by filtering, so nothing above your defined highest frequency gets 
out in the analog domain again. You will note that you are in full control: 
define the maximum frequency and define the resolution. If they are not 
sufficient to your purpose, go higher.

In order to have a sampled representation of our analog sound signal (which 
is itself an electrical representation of a pressure variation around 
atmospheric pressure) we have to measure it at regular intervals defined by 
the sample rate and hold the value for as long it takes to obtain the tabular 
value - the value that goes into the digital word stream.

Now, we have a problem with pure sampling of a waveform: if it has a 
frequency that is more than half of the sampling rate, that too will be 
sampled, but in this case under-sampled, which means that the result appears 
to be at a completely different and inharmonic and jarring frequency, an 
alias. Once we have adopted a sampling frequency we must simply ensure that 
no signal above half the sampling rate is available for sampling.

This is done by filtering, so-called anti-alias filtering. With 44.1 kHz 
sampling rate, no signal above 22.05 kHz is permissible. On the other hand, 
we do want our 20 kHz bandwidth - this is what a young, pre-earbud ear can 
mostly hear. So, our filter has to go from full transmission at 20kHz to zero 
transmission at 22.05 kHz *). No problem, our telephone engineers have done 
this kind of exercise for 90 years. However, such sharp cut-off filters come 
with some frightful time delay distortion (phase to some), very audible down 
to 2 kHz. That was the situation for about 10 years in CD audio, until 
someone came up with the idea to correct the time response in the digital 
domain by means of a digital filter. The currency to pay for this is total 
delay time, but for something recorded a year ago, some microseconds do not 
matter.

In other words, many of our problems come from the filter. If we increase the 
sampling rate we can make use of our more frequent samples in two ways: we 
can do a gentler filtering that does not have the delay effect at low 
frequencies, or we can increase our highest frequency. If we do the latter, 
we shall be able to increase the time resolution of our digital 
representation. With 20 kHz the maximum slope of the waveform is only one 
quarter of that of an 80 kHz bandwidth - reachable by a 192 kHz sampling 
frequency and a gentler anti-aliasing filter.

Dependent on where you are on the scale of knowing electronics at graduate 
level, you will miss a discussion of one-bit sampling and also of dithering. 
I am not out to write a book. John Watkinson did. There is one thing that I 
would love to see in the market: an interactive program where you could take 
a number of input waveforms and vary the parameters bit depth, bandwidth, 
sampling rate, anti-alias filter type and parameters, all to experiment on, 
to see what things look like when you are in control. On the mock-ups based 
on this principle I have seen, one of the most impressive is "oops, where has 
it gone", when a frequency or a delay between two signals suddenly disappear. 
Or when two frequency response peaks close by suddenly merge into one. 
Understanding WHY they have gone seems to me to be very important.

A couple of other items came up while we were at 78rpm reproduction:

 - the reason why we need an elevated bandwidth for recordings on rough 
surfaces is because that is where the noise signal is. If we are to deal 
properly with the noise it has to be represented correctly. And 80 kHz is a 
marked improvement and will also permit us to look into low-level artefacts 
at supersonic frequencies. I would refer you to my paper "What are the 
Sources of the Noises We Remove",  Proceedings of AES 20th Int. Conf. 
'Archiving, Restoration, and New Methods of Recording', Eds. Z. Vajda, H. 
Pichler, Budapest 5-7 October 2001, pp. 175-182. Unless someone else makes 
the claim, I may well have been the first to state that in restoration work 
using preservation copying, the bandwidth is not determined by the intended 
signal but by the noise. This was at the IASA Conference in Bogensee near 
Berlin in 1994.

 - one might consider that the pickup would be encountering a formidable 
vertical wall when it met a square wave. However, the recording is usually a 
velocity recording, that is the square waveshape is differentiated (1st 
derivative), which means it turns into a triangular wave. The problem is that 
with a high bandwidth, the corners of this triangular wave (where the square 
shifts from constant positive to constant negative and vice versa) are very 
sharp, and even that may be difficult to trace. George Alexandrovich made a 
7" test record with a "square wave" - there are virtually no wiggles at the 
corners of the triangles. It is for testing pickups, but I have not dared to 
use it on anything but the ELP.

 - for the same reason a tick, modelled by a steep rise followed by steep 
fall becomes two ticks, one positive and one negative.

 - even if you remove these two peaks and interpolate or draw a waveform 
connecting the ends, the low frequency excitation of the whole 
cartridge-tonearm system (stylus, cantilever, bearing, cartridge mass, 
tonearm mass and resonances) still remains as a low-level thud - a tail. 
CEDAR started back in 1988 with a program developed by Peter Rayner while 
still at the British Library to remove not only the ticks, but also the tail.

Well, for those of you who have not yet dropped off - 

best wishes,


George




*) Actually it is not zero, but determined by the noise floor in the desired 
digital representation or bit depth. Every bit added gives 6dB more headroom.



------------------------------------------


> On 11/04/2012, Tom Fine wrote:
> 
> 
> > As for the idea that 192kHz is somehow inferior to 96k, that sounds
> > like audiophoolery or outdated ideas based on older hardware. I would
> > say it's unecessary overkill to sample at that high a rate, for the
> > reasons you stated, but the playback results shouldn't sound inferior
> > to 96k unless something is being done wrong by the equipment or the
> > user.
> > 
> The main advantage of high sampling rates is that it is easier for
> software to distinguish clicks (impulses) from music.
> 
> The waveform of a muted trumpet (as played by Buck Clayton, for
> instance) is very similar to a rapid sequence of clicks, so software
> operating at 44.1 KHz cannot automatically tell the difference.
> 
> But the trumpet signal will fade out at the high frequency limit of the
> recording equipment, while clicks will have higher frequency components.
> 
> Regards
> -- 
> Don Cox
> [log in to unmask]

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager