Media player to DAC
 

On Thu, 08 Apr 2010 15:47:12 +0100, Rob
wrote:

Then you compare the two using a software ABX DBT comparator.


Do you happen to know of a Mac variant?

Not likely to be one - Mac users believe in magic anyway so wouldn't
need one :-)

Media player to DAC
 

"Rob" wrote in message


Rule number one is that when you do comparisons like
this, you take the high sample rate file and downsample
it yourself, which is easy to do with free software that
can downloaded from the web.

Why's that - are Naim not to be trusted?

Nothing specific about Naim, just that major producers sometimes produce
different technical renderings or masterings of the same basic music work in
different formats. They may sound very similar, but never exactly alike
because they were slightly or significantly different (it varies by work and
format) prior to being recorded in the various audio formats. It is common
to re-master musical works for distribution in a new format.

Then you compare the two using a software ABX DBT
comparator.

Do you happen to know of a Mac variant?

I suspect that the Java ABX comparator will run on a Mac using the Sun Mac
Run Time Environment (JRE) for the Mac. It will if Macs are comparable to
PCs. ;-)

http://www.java.com/en/download/manual.jsp is the general source of Sun JRE
for all hardware platforms but that page suggests that Macs with OS/X come
loaded with this software pre-loaded. Just make sure you have the
latest-greatest version.

The JAVA ABX comparator can be downloaded from:

http://www.hydrogenaudio.org/forums/...e=post&id=5692

Just do a "save as" on the above Link and you should be offered a download
of

abchr_java_0.53a_bin.zip

Inside abchr_java_0.53a_bin.zip file are two files, one of which is
abchr.jar .

Extract and open the abchr.jar file, and after a few seconds you should see
the opening menu for the ABC/hr - ABX comparator. Select ABX and plug in
the names of the two audio files you want to compare. Post any questions
here.

Media player to DAC
 

"Laurence Payne" wrote in message

On Thu, 08 Apr 2010 15:47:12 +0100, Rob
wrote:

Then you compare the two using a software ABX DBT
comparator.


Do you happen to know of a Mac variant?

Not likely to be one - Mac users believe in magic anyway
so wouldn't need one :-)

The JAVA ABX comparator can be downloaded from:

http://www.hydrogenaudio.org/forums/...e=post&id=5692

Just do a "save as" on the above Link and you should be offered a download
of

abchr_java_0.53a_bin.zip


http://www.java.com/en/download/manual.jsp is the general source of Sun JRE
for all hardware platforms but that page suggests that Macs with OS/X come
loaded with this software pre-loaded. Just make sure you have the
latest-greatest version.

Inside abchr_java_0.53a_bin.zip file are two files, one of which is
abchr.jar .

Extract and open the abchr.jar file, and after a few seconds you should see
the opening menu for the ABC/hr - ABX comparator. Select ABX and plug in
the names of the two audio files you want to compare. Post any questions
here.

Media player to DAC
 

On 08/04/2010 17:42, Laurence Payne wrote:
On Thu, 08 Apr 2010 15:47:12 +0100,
wrote:

Then you compare the two using a software ABX DBT comparator.


Do you happen to know of a Mac variant?

Not likely to be one - Mac users believe in magic anyway so wouldn't
need one :-)

Oh yes :-)

Media player to DAC
 

On 08/04/2010 18:42, Arny Krueger wrote:
wrote in message


Rule number one is that when you do comparisons like
this, you take the high sample rate file and downsample
it yourself, which is easy to do with free software that
can downloaded from the web.

Why's that - are Naim not to be trusted?

Nothing specific about Naim, just that major producers sometimes produce
different technical renderings or masterings of the same basic music work in
different formats. They may sound very similar, but never exactly alike
because they were slightly or significantly different (it varies by work and
format) prior to being recorded in the various audio formats. It is common
to re-master musical works for distribution in a new format.


I would have thought it was recorded in one, 'hig def' format, and then
downsampled.

Just wondered if there were any examples of distributors meddling with
the two versions.

What gets me is that they're charging more for something that's actually
taken more work to produce.

Similarly, I recently discovered that the early 'core solo' processors
were actually dual core, with one core disabled.

Makes me seethe. Nationalise the lot :-)


Then you compare the two using a software ABX DBT
comparator.

Do you happen to know of a Mac variant?

I suspect that the Java ABX comparator will run on a Mac using the Sun Mac
Run Time Environment (JRE) for the Mac. It will if Macs are comparable to
PCs. ;-)

http://www.java.com/en/download/manual.jsp is the general source of Sun JRE
for all hardware platforms but that page suggests that Macs with OS/X come
loaded with this software pre-loaded. Just make sure you have the
latest-greatest version.

The JAVA ABX comparator can be downloaded from:

http://www.hydrogenaudio.org/forums/...e=post&id=5692

Just do a "save as" on the above Link and you should be offered a download
of

abchr_java_0.53a_bin.zip

Inside abchr_java_0.53a_bin.zip file are two files, one of which is
abchr.jar .

Extract and open the abchr.jar file, and after a few seconds you should see
the opening menu for the ABC/hr - ABX comparator. Select ABX and plug in
the names of the two audio files you want to compare. Post any questions
here.


Great - thanks for that, I'll give it a go.

Rob

Media player to DAC
 

On 08/04/2010 16:29, Jim Lesurf wrote:
In , Rob
wrote:
On 08/04/2010 12:45, Arny Krueger wrote:


Rule number one is that when you do comparisons like this, you take
the high sample rate file and downsample it yourself, which is easy to
do with free software that can downloaded from the web.


Why's that - are Naim not to be trusted?

Erm... I've not checked, but I presume they are making the files available
for people to listen to rather than use as examples for assessing the
effect of *only* changing the sample rate and/or bit-depth.

Not sure what "trust" has to do with that *unless* Naim have stated that
the *only change* was to downsample one version. Even then I'd personally
want to know the details of the process to be able to understand what
effect that may or may not have.


See below, and I was just wondering if there's any convention here with
the offer of two sample rates, where any difference is contestable
(unlike mp3s, where most people acknowledge a difference).

However I would "trust" then to do their best to make good sounding
versions if their purpose is to produce material people want to listen to.
Without other evidence, though, I don't know what they'd think the best way
to do that. So don't know what they would do to make versions at different
sample rates, etc.

When doing such things on a scientific/academic basis you want to know all
the details as they may affect the results for reasons that differ from the
assumptions that otherwise might be made.

The context in such terms is that I think others have already found that
some dual format commercial releases show things like differences in level
compression, made because those producing the versions assumed something
different was 'better' for the different (assumed) target audiences for the
two versions.

There are also various choices that could be made when using one version to
create the other, that then vary the output. e.g. I understand that at one
time Tony Faulkner preferred a simplistic form of downsampling that doesn't
actually meet the sampling theorem. He preferred the results, presumably
because he thought it made a 'change' that he liked. Or because it
minimised in-band filtering at the expense of aliasing.


That's really why I ask - I think. If there's more than one way to
downsample properly, I'm stuffed.

Media player to DAC
 

"Rob" wrote in message

On 08/04/2010 18:42, Arny Krueger wrote:
wrote in message


Rule number one is that when you do comparisons like
this, you take the high sample rate file and downsample
it yourself, which is easy to do with free software
that can downloaded from the web.

Why's that - are Naim not to be trusted?

Nothing specific about Naim, just that major producers
sometimes produce different technical renderings or
masterings of the same basic music work in different
formats. They may sound very similar, but never exactly
alike because they were slightly or significantly
different (it varies by work and format) prior to being
recorded in the various audio formats. It is common to
re-master musical works for distribution in a new
format.

I would have thought it was recorded in one, 'hig def'
format, and then downsampled.

While we cannot determine the exact pedigre of every recording as listeners,
there is abundant technical proof that while the procedure you suggest makes
a lot of sense, it is simply not always the case.

Just wondered if there were any examples of distributors
meddling with the two versions.

The meddling is usually done by the producers.

What gets me is that they're charging more for something
that's actually taken more work to produce.

Not necessarily.

Similarly, I recently discovered that the early 'core
solo' processors were actually dual core, with one core
disabled.

That wouldn't surprise me. Low clock rate processors are often high clock
rate processors with the lower clock speed simply enforced. Take a laser and
zap a link on the chip, or simpler yet take a bonding wire and jumper two
pads on the chip.

Then you compare the two using a software ABX DBT
comparator.

Do you happen to know of a Mac variant?

I suspect that the Java ABX comparator will run on a Mac
using the Sun Mac Run Time Environment (JRE) for the
Mac. It will if Macs are comparable to PCs. ;-)

http://www.java.com/en/download/manual.jsp is the
general source of Sun JRE for all hardware platforms but
that page suggests that Macs with OS/X come loaded with
this software pre-loaded. Just make sure you have the
latest-greatest version. The JAVA ABX comparator can be downloaded from:

http://www.hydrogenaudio.org/forums/...e=post&id=5692

Just do a "save as" on the above Link and you should be
offered a download of

abchr_java_0.53a_bin.zip

Inside abchr_java_0.53a_bin.zip file are two files, one
of which is abchr.jar .

Extract and open the abchr.jar file, and after a few
seconds you should see the opening menu for the ABC/hr -
ABX comparator. Select ABX and plug in the names of the
two audio files you want to compare. Post any questions
here.

Great - thanks for that, I'll give it a go.

I will be interested in hearing how it goes for you.

Media player to DAC
 

"Jim Lesurf" wrote in message
...
In article ,
Michael
Chare wrote:
"Jim Lesurf" wrote in message
...


Hence in such cases a difference can easily be measured, and may be
audible, but actually tell you nothing about the difference in sample
rate or resolution being a 'cause' for said differences.

I just asked my daughter if she could hear any difference, and then
to explain the difference that she heard.


Her description of the difference made me think that she was hearing a
difference in the bit rate.

OK. The difficulty with that is that it is essentially basing your
conclusion on a series of assumptions. Could easily have been some other
factor.


Are the Naim files you refer to available freely? If so I'd be
interested in examining them sometime.


Yes, freely available from http://www.naimlabel.com/

Let us know your thoughts!

Well, don't hold you breath waiting as it may well be ages before my
'round
tuit' arrives! :-)

And as Arny has asked, can you say which particular files you (and your
daughter) compared? Might be best if I tried those if I can.


I used the pair of Jazz flac files and the pair of Classical flac files on
this page:

http://www.naimlabel.com/musicstore-test-files.aspx

The names are shown on the web page as:

Simple Psalm - Since Forever (Fred Simon)
Beethoven - Symphony No.1 in C (Iona Brown and the NCO)

However the tag data for the Fred Simon Jazz track shows it as:
Simple Psalm - Since Forever (Fred Simon)


--
Michael Chare

Media player to DAC
 

"Arny Krueger" wrote in message
...


That wouldn't surprise me. Low clock rate processors are often high clock
rate processors with the lower clock speed simply enforced. Take a laser
and zap a link on the chip, or simpler yet take a bonding wire and jumper
two pads on the chip.


Reminds me of scam of sticking labels on Intel 386 low clock rate processors
to say that they were high rate processors and with the words 'Warranty
invalid if this label is removed'.


--
Michael Chare

Media player to DAC
 

On 08/04/2010 21:37, Arny Krueger wrote:
wrote in message


http://www.java.com/en/download/manual.jsp is the
general source of Sun JRE for all hardware platforms but
that page suggests that Macs with OS/X come loaded with
this software pre-loaded. Just make sure you have the
latest-greatest version. The JAVA ABX comparator can be downloaded from:

http://www.hydrogenaudio.org/forums/...e=post&id=5692

Just do a "save as" on the above Link and you should be
offered a download of

abchr_java_0.53a_bin.zip

Inside abchr_java_0.53a_bin.zip file are two files, one
of which is abchr.jar .

Extract and open the abchr.jar file, and after a few
seconds you should see the opening menu for the ABC/hr -
ABX comparator. Select ABX and plug in the names of the
two audio files you want to compare. Post any questions
here.

Great - thanks for that, I'll give it a go.

I will be interested in hearing how it goes for you.



The Java app looks fine, encoded the wav CD file, but wouldn't encode
the HD or mp3 files. I'm not sure why it has to encode anything, and I
tried it with the 'standardise' (gain and offset correction) on and off.

Anyways, I'll have another go later.

Media player to DAC
 

In article , Rob
wrote:


That's really why I ask - I think. If there's more than one way to
downsample properly, I'm stuffed.

In principle 'downsampling' should be done 'properly' and will then lead to
a uniquely defined results - even if done in various algorithmic ways.

But in practice any downsampling or resampling can produce its own
(needless in theory) alterations that vary with the method used.

And in practice the vendors/creators may well add on other 'alterations'
they regard as an 'improvement' for each specific version. They may well
not admit this, or say how they did it. All part of the magic of
'mastering', etc. From the same people who brought us CDs that are clipped
and level-compressed to death because they "know" people "like" that. sic

But I have no idea what Naim have done. Might be able to tell once an
analysis has been carried out. I'd expect them to have avoided the insane
clipping, etc. But for all I know, they do other things because they judge
it gives 'better' results.

Slainte,

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

Media player to DAC
 

In article , Michael Chare
wrote:
"Jim Lesurf" wrote in message
...


And as Arny has asked, can you say which particular files you (and
your daughter) compared? Might be best if I tried those if I can.


I used the pair of Jazz flac files and the pair of Classical flac files
on this page:

http://www.naimlabel.com/musicstore-test-files.aspx

The names are shown on the web page as:

Simple Psalm - Since Forever (Fred Simon) Beethoven - Symphony No.1 in C
(Iona Brown and the NCO)

However the tag data for the Fred Simon Jazz track shows it as: Simple
Psalm - Since Forever (Fred Simon)

Thanks. I'll put this on my list of things to do. Hope to do it soon as I
am quite interested to see how their files compare.

Slainte,

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

Media player to DAC
 

"Arny Krueger" wrote in message
...
That wouldn't surprise me. Low clock rate processors are often high clock
rate processors with the lower clock speed simply enforced. Take a laser
and zap a link on the chip, or simpler yet take a bonding wire and jumper
two pads on the chip.

Or even simpler, get an HB pencil and draw a line to link the pads. I got
nearly a 50% increase in processor clock speed on one of my early Duron
CPUs.

Media player to DAC
 

On Fri, 9 Apr 2010 09:25:40 +0100, "David"
wrote:

That wouldn't surprise me. Low clock rate processors are often high clock
rate processors with the lower clock speed simply enforced. Take a laser
and zap a link on the chip, or simpler yet take a bonding wire and jumper
two pads on the chip.

Or even simpler, get an HB pencil and draw a line to link the pads. I got
nearly a 50% increase in processor clock speed on one of my early Duron
CPUs.

It's worth a try, and is sometimes well-documented as reliable. But
sometimes CPUs are jumpered at one speed because they failed testing
at a higher one.

Media player to DAC
 

"Laurence Payne" wrote in message
...
Or even simpler, get an HB pencil and draw a line to link the pads. I got
nearly a 50% increase in processor clock speed on one of my early Duron
CPUs.

It's worth a try, and is sometimes well-documented as reliable. But
sometimes CPUs are jumpered at one speed because they failed testing
at a higher one.

Indeed but I did my research and bought from a particular batch at a very
slightly higher price from an overclockers site. It lasted a good couple of
years before it was replaced, after which I took it upto and well beyond
it's limits.

Media player to DAC
 

"Rob" wrote in message


There are also various choices that could be made when
using one version to create the other, that then vary
the output. e.g. I understand that at one time Tony
Faulkner preferred a simplistic form of downsampling
that doesn't actually meet the sampling theorem. He
preferred the results, presumably because he thought it
made a 'change' that he liked. Or because it minimised
in-band filtering at the expense of aliasing.

That's really why I ask - I think. If there's more than
one way to downsample properly, I'm stuffed.

Not only are there many different downsamplers, with vastly different levels
of accuracy, but there is a time-honored process of simply starting out with
differently mastered recordings.

Media player to DAC
 

"Rob" wrote in message



The Java app looks fine, encoded the wav CD file, but
wouldn't encode the HD or mp3 files. I'm not sure why it
has to encode anything, and I tried it with the
'standardise' (gain and offset correction) on and off.

I haven't tested the Java app on a machine that can play HD files natively.

I've only tested it with 44/16 .wav files on a machine that can only play
44/16 .wav files.

You can convert MP3 files to .wav files a number of different ways that are
accurate. One is to load them into Audacity, and export them as .wav files.
MP3 files can also be accurately saved as .wav files using WinAmp. By
accurate, I mean that the resulting .wav files are represntative of what the
MP3 sounds like when played with a MP3 player.

Dirty little secret - all MP3 files are converted to .wav files during
playback, on-the-fly.

Media player to DAC
 

"Rob" wrote in message

On 08/04/2010 18:42, Arny Krueger wrote:
wrote in message


Rule number one is that when you do comparisons like
this, you take the high sample rate file and downsample
it yourself, which is easy to do with free software
that can downloaded from the web.

Why's that - are Naim not to be trusted?

Nothing specific about Naim, just that major producers
sometimes produce different technical renderings or
masterings of the same basic music work in different
formats. They may sound very similar, but never exactly
alike because they were slightly or significantly
different (it varies by work and format) prior to being
recorded in the various audio formats. It is common to
re-master musical works for distribution in a new
format.

I would have thought it was recorded in one, 'hig def'
format, and then downsampled.

Just wondered if there were any examples of distributors
meddling with the two versions.

I did a spectral comparison of the two "test-1" files. There were major,
multiple-dB, multi-octave-wide differences below 80 Hz and above 7 KHz..

Media player to DAC
 

Jim Lesurf wrote:
In article , Rob
wrote:


That's really why I ask - I think. If there's more than one way to
downsample properly, I'm stuffed.

In principle 'downsampling' should be done 'properly' and will then lead to
a uniquely defined results - even if done in various algorithmic ways.


That's not so.

Downsampling always involves a reduction in Nyquist frequency. It's
necessary therefore to filter the input to make sure frequencies above
this are sufficiently reduced. That filter can never be perfect, and
there will be various tradeoffs, involving extra loss of top-end,
in-band ripple and 'wrap-around' garbage from insufficient rejection of
higher-than-Nyquist signal. It's all down to what the person doing it
thought would be best (by some arbitrary criterion), and there is no
unique or 'right' answer.

--
Mike Scott (unet2 at [deletethis] scottsonline.org.uk)
Harlow Essex England

Media player to DAC
 

"Mike Scott"
wrote in message
Jim Lesurf wrote:
In article , Rob
wrote:


That's really why I ask - I think. If there's more than
one way to downsample properly, I'm stuffed.

In principle 'downsampling' should be done 'properly'
and will then lead to a uniquely defined results - even
if done in various algorithmic ways.

That's not so.

If you are defining "uniquely defined" as being some precise bit pattern,
then I am forced to agree.

Downsampling always involves a reduction in Nyquist
frequency. It's necessary therefore to filter the input
to make sure frequencies above this are sufficiently
reduced. That filter can never be perfect, and there will
be various tradeoffs, involving extra loss of top-end,
in-band ripple and 'wrap-around' garbage from
insufficient rejection of higher-than-Nyquist signal.

That would be one of those things that is true - theoretically, but from an
audibility standpoint, is not true.

The big difference is how sophisticated we have become in terms of designing
and implementing digital filters.

It's all down to what the person doing it thought would
be best (by some arbitrary criterion), and there is no
unique or 'right' answer.

If computational resources are highly estensible, it is possible to product
digital filters with very nearly ideal phase and amplitude characteristics.

The realm of perceptual studies have also improved - we now know that the
ideal phase characteristic for the required brick wall filter is neither
linear phase nor minimum phase. However, we base that knowlege on
experiments done at Nyquist frequencies well below 20 KHz, because sonically
innocious downsampling to 22 Khz has been routinely availble at a reasonble
cost for nearly a decade.

Media player to DAC
 

In article , Mike Scott
wrote:
Jim Lesurf wrote:
In article , Rob
wrote:


That's really why I ask - I think. If there's more than one way to
downsample properly, I'm stuffed.

In principle 'downsampling' should be done 'properly' and will then
lead to a uniquely defined results - even if done in various
algorithmic ways.


That's not so.

Downsampling always involves a reduction in Nyquist frequency. It's
necessary therefore to filter the input to make sure frequencies above
this are sufficiently reduced.

Correct.

That filter can never be perfect, and there will be various tradeoffs,
involving extra loss of top-end, in-band ripple and 'wrap-around'
garbage from insufficient rejection of higher-than-Nyquist signal.

Also correct in practice. But you missed my "in principle" in what I wrote
above. (Which you have snipped away.) And presumbly then failed to
understand why I then went on to discuss how "in practice" will be
different - for reasons like the one you mention.

To remind you, what I wrote that you quoted above was immediately followed
by my saying:

But in practice any downsampling or resampling can produce its own
(needless in theory) alterations that vary with the method used.

Perhaps you failed to read that before leaping in. Pity, as understanding
it would have meant you'd have had no reason to write what you did. :-)

It's all down to what the person doing it thought would be best (by some
arbitrary criterion), and there is no unique or 'right' answer.

It is formally incorrect to say there is no "unique or right answer". The
formally correct and uniquely correct "answer" is to have all the in band
components preserved whilst losing all the out of band ones. This follows
from the sampling theorem, etc. That then represents the uniquely "correct"
answer in terms of information theory.

However, as my previous posting on this did point out (but you snipped and
ignored), in practice you tend to have to accept some level of
imperfection. Albeit very small if the resampling is well done.

Slainte,

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

Media player to DAC
 

In article , Arny
Krueger
wrote:
"Mike Scott" wrote in
message
Jim Lesurf wrote:
In article , Rob
wrote:


That's really why I ask - I think. If there's more than one way to
downsample properly, I'm stuffed.

In principle 'downsampling' should be done 'properly' and will then
lead to a uniquely defined results - even if done in various
algorithmic ways.

That's not so.

If you are defining "uniquely defined" as being some precise bit
pattern, then I am forced to agree.

The problem arises when the poster snips away a following comment and
ignores the distinction I made quite clearly. But which apparently escaped
his grasp. :-)


If computational resources are highly estensible, it is possible to
product digital filters with very nearly ideal phase and amplitude
characteristics.

Indeed. That is a matter of how much care, effort, and computation time,
the people involved are willing to apply to the process.

Slainte,

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

Media player to DAC
 

On 09/04/2010 12:10, Arny Krueger wrote:
wrote in message



The Java app looks fine, encoded the wav CD file, but
wouldn't encode the HD or mp3 files. I'm not sure why it
has to encode anything, and I tried it with the
'standardise' (gain and offset correction) on and off.

I haven't tested the Java app on a machine that can play HD files natively.

I've only tested it with 44/16 .wav files on a machine that can only play
44/16 .wav files.


I'd guess and say it doesn't work with anything other than 44/16 wav.

You can convert MP3 files to .wav files a number of different ways that are
accurate. One is to load them into Audacity, and export them as .wav files.
MP3 files can also be accurately saved as .wav files using WinAmp. By
accurate, I mean that the resulting .wav files are represntative of what the
MP3 sounds like when played with a MP3 player.

Dirty little secret - all MP3 files are converted to .wav files during
playback, on-the-fly.


Does no harm. I'll try it some time with Windows - but from what you say
there's more to these Naim tracks than differences in sample rate. So
not much point A/B testing then.

Media player to DAC
 

In article , Michael
Chare scribeth thus
"tony sayer" wrote in message
...
In article , Michael
Chare scribeth thus
"tony sayer" wrote in message
...


Better than CD eh?, so just where do you obtain this from?...
--

There are a number of websites which offer downloads.



Are they really any better?..
--

Depends whether your ears (and hifi) are good enough to tell the difference,

I rather think they'd suffice;)..

and whether you brain appreciates the difference it.

I rather think that may well to .. but perhaps the problem is I listen
to far far too much live stuff these days;)..



--
Tony S